iam: need a well-supported way to depend on added permissions #7236
Comments
blimmer
added
bug
|
Hi, The scope the resource dependency is restricted to its state at creation. Since you're creating the IAM Role and adding the policies later, the dependency is fulfilled when the Role is created, without the later added policies. The I'd also cast the Fix those and your code will work. |
SomayaB
added
@aws-cdk/aws-iam
Try this instead: deliveryStream.addDependency(deliveryStreamRole);It's not ideal, but it will fix your issue. |
rix0rrr
changed the title
rix0rrr
added
feature-request
Hi @rix0rrr, I can confirm this doesn't work: // @ts-ignore
deliveryStream.addDependsOn(deliveryStreamRole);Maybe because those dependencies are ultimately scoped to the underlying // stack.ts
// ...
// Resource dependencies
for (const dependency of this.node.dependencies) {
for (const target of findCfnResources([ dependency.target ])) {
for (const source of findCfnResources([ dependency.source ])) {
source.addDependsOn(target);
}
}
}Also, isn't the dependency issue already pretty reasonably covered by the construct? /**
* A list of named policies to inline into this role. These policies will be
* created with the role, whereas those added by ``addToPolicy`` are added
* using a separate CloudFormation resource (allowing a way around circular
* dependencies that could otherwise be introduced).
*
* @default - No policy is inlined in the Role resource.
*/
readonly inlinePolicies?: { [name: string]: PolicyDocument };🤔 |
|
@rix0rrr and @andrestone - thanks for the continued diagnosis. I also confirmed that this didn't fix the problem: // @ts-ignore
deliveryStream.addDependsOn(deliveryStreamRole);Because constructs like the Kinesis stream |
|
I actually meant deliveryStream.node.addDependency(...)Forgot the |
Lambda Targets can get registered into a TargetGroup before the `lambda:Invoke` permissions are added. Since the TargetGroup does a permission test, deployment will fail. Fixes #4663. Adding a long-overdue mechanism to the IAM library to depend on Grants that just got created, to ensure permissions are created before the resources that depend on them (in effect: `Grant`s are made `IDependable`). Relates to the root cause of #7236.
|
i have quite a similar issue. Take this code: esDomain.node.addDependency(..) AND esDomain.addDependsOn(..) dont work. Always get
If i run this code without the ESDomain creation (only the CfnServiceLinkedRole creation) and run it again this time WITH esDomain creation, it works. So why do all those depend* methods dont work? Funny enough... according to logs, the ServiceRole was created before the Domain creation started but nevertheless the error appeared.
synthesized file for stack looks good too. "ElasticSearchDomain" has the property: |
Lambda Targets can get registered into a TargetGroup before the `lambda:Invoke` permissions are added. Since the TargetGroup does a permission test, deployment will fail. Fixes #4663. Adding a long-overdue mechanism to the IAM library to depend on Grants that just got created, to ensure permissions are created before the resources that depend on them (in effect: `Grant`s are made `IDependable`). Relates to the root cause of #7236.
Lambda Targets can get registered into a TargetGroup before the `lambda:Invoke` permissions are added. Since the TargetGroup does a permission test, deployment will fail. Fixes aws#4663. Adding a long-overdue mechanism to the IAM library to depend on Grants that just got created, to ensure permissions are created before the resources that depend on them (in effect: `Grant`s are made `IDependable`). Relates to the root cause of aws#7236.
|
This has been added, |
I'm manually creating an IAM role for my Kinesis Data Stream -> Kinesis Data Firehose infrastructure. However, when I use either
role.addToPolicyorstream.grantRead(myRole), it doesn't wait for generated policies to be attached to the created role.Reproduction Steps
Error Log
Environment
Other
If I look at the console during the creation of this stack, I can see that the Role is created, but it has no policies attached. The way I've worked around this is by creating the role separately during a
cdk deploy, then create the stream. Then, everything works.This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: