-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(elbv2): race condition for Lambda backends #7598
Conversation
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.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
I hit this issue and had no idea what the heck was happening. Subsequent synthesis and deployment worked fine, which really confused me. I think this is a reasonable breaking change to make, especially given what's being fixed. |
Agree with your point. Not concerned about breaking a function changes its return type from |
No but unfortunately it's changing from |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
return this.addToIdentityPolicy(statement).statementAdded; | ||
} | ||
|
||
public addToIdentityPolicy(statement: PolicyStatement): AddToIdentityPolicyResult { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should these be called addToPrincipalPolicy
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe. Right now it's:
- Principal: anything you can grant permissions to, that goes into a policy (user, role, but also service principal or account principal)
- Identity: an IAM identity you create (user, role, group).
Policies only go on Identities, for example "adding to a service principal's policy" doesn't make any sense.
However, I will grant that this distinction might not be obvious, and it might confuse more than it helps.
Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am okay with that distinction although I also think it's not 100% required in this case and addToPrincipalPolicy
would have been a bit clearer
/** | ||
* Dependable which allows depending on the policy change being applied | ||
* | ||
* @default - Required if `statementAdded` is true. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is always required if statementAdded
is true
then why do we need statementAdded
? We can rename this field to addedBy
or owner
and require that it is set when a statement was added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
owner
doesn't really cover the load of what I'm trying to do here, which is strictly offer a way to add a dependency and nothing else.
As for statementAdded
, yeah maybe it's superfluous. On the other hand it does make for more readable consumer code to say:
if (result.statementAdded) { /* do thing */ }
Rather than:
if (result.policyDependable !== undefined) { /* do a thing */ }
Open to a better name for the dependable though...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Damn I don't.... Can we make this "@experimental"?
This seems like something we should include in our v2.0 work. Add it to the list in aws/aws-cdk-rfcs#79 |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
DISCUSSION TOPIC:
What I'd actually like to do is break the return signature of
role.addToPolicy(): boolean
to a struct, otherwise it's going to be very hard to reliably implement this. Fairly sure this won't cause issues because few people will be checking the return value ofaddToPolicy()
, but of course we technically speaking aren't allowed to do this.Commit Message
fix(elbv2): race condition for Lambda backends
Lambda Targets can get registered into a TargetGroup before the
lambda:Invoke
permissions are added. Since the TargetGroup doesa 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 madeIDependable
).Relates to the root cause of #7236.
End Commit Message
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license