-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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(ecr): grants for cross-account principals result in failed deployments #16376
fix(ecr): grants for cross-account principals result in failed deployments #16376
Conversation
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'm not sure I agree with this approach. We're actually now doing something different than what the user asked for, and they could equally well just do what we're doing, but explicitly. So we can add a warning for it, and/or add it to the docs. Or tell the user to do authz based on tags.
Either that, or we potentially add the stack dependency automatically.
But trusting the whole account "just because" it happens to work out, although it does something different than what the user requested... I don't think that's a good idea.
|
||
// condition #3 | ||
const principalStack = Stack.of(principal); | ||
if (this.stack.dependencies.includes(principalStack)) { |
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 don't think this is safe or even likely to be true. Might as well leave this out.
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.
Actually, we already do this for KMS Keys, so I think it's not the worst idea.
924c117
to
ebfd5f2
Compare
@rix0rrr I want to resurrect this old PR, if you don't mind 🙂.
I'm not sure there's something else we can do. If we don't change the logic inside the ECR Repository, then, regardless of what the customer tries to do "manually" themselves, we already add the Role from the Service Stack (which doesn't exist yet) to the resource policy of the ECR repo that lives in the pipeline Stack. Which means, regardless of what else the customer wants to do there (trust the entire account, use tags for permissions, etc.), the problem is already there, and the repository will fail to deploy - so, no amount of tinkering (short of something really low-level, like escape hatches) can fix that. |
This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week. |
@rix0rrr you want to reply here, before the PR gets closed? 🙂 #16376 (comment) |
Psssst: If you resolve the conflicts, it resets the timer. |
74f3ed8
to
c8251d4
Compare
c8251d4
to
e3bf9e6
Compare
Thanks, I really hope so, because solving these conflicts was super irritating 😃. |
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'm still scared of opening up to an entire account.
Can we do something like the following:
class Role {
public crossAccountSafeGrantable(): IGrantable {
if (!this.roleTag) {
this.roleTag = `${Stack.of(this).stackName}${this.node.addr}`;
Tags.of(this).add(this.roleTag, 'aws-cdk:id', this.roleTag);
}
return new AccountRootPrincipal(Stack.of(this.account), {
conditions: {
StringEquals: { 'aws:PrincipalTag/aws-cdk:id', this.roleTag },
},
});
}
}
And use that as the IGrantable
instead?
* if we cannot put a reference to the principal itself there, | ||
* and 'undefined' in case we can. | ||
*/ | ||
private principalCannotBeSafelyAddedToResourcePolicy(grantee: iam.IGrantable): string | undefined { |
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.
Can't this return the correct IGrantable
instead?
private correctGrantable(grantee: IGrantable): IGrantable {
if (isRoleInDifferentStack(grantee)) {
return grantee.crossAccountSafeGrantable();
}
return grantee;
}
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.
Unfortunately, the code you suggested:
return new AccountRootPrincipal(Stack.of(this.account), {
conditions: {
StringEquals: { 'aws:PrincipalTag/aws-cdk:id', this.roleTag },
},
});
doesn't work (conditions are attached to Policy Statements, not to Principals).
However, added the tag to the Role in a different way, let me know if that works!
// 1. The principal is from a different account. | ||
// 2. The principal is a new resource (meaning, not imported). | ||
// 3. The Stack this repo belongs to doesn't depend on the Stack the principal belongs to. |
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.
Do these combine with AND or OR?
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.
And. Clarified in the comments.
|
||
// condition #3 | ||
const principalStack = Stack.of(principal); | ||
if (this.stack.dependencies.includes(principalStack)) { |
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.
You can't really know this. Dependencies probably get resolve really late, especially implicit ones.
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 still think it's better to make this check than not (even if it doesn't work 100% of the time, it might work some of the time).
Yep. The validation error is because of missing integration tests:
But, this is a cross-account scenario, and CDK integration tests are meant to run in a single account. The functionality has unit tests that confirm the cross-account scenario works as expected. |
@rix0rrr incorporated your comments, would appreciate another review! |
✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.
This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state. |
1 similar comment
This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state. |
Is the build for
I haven't touched the CLI in this PR, but I also had to update the third-party license attribution for two other packages to make them build, so I suspect something is up with |
This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state. |
1 similar comment
This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state. |
OK, looks like @rix0rrr this is ready for another round of reviews! |
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.
Thanks!
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
(Sorry for the late reply 😓 ) |
It's all good brother ❤️. I needed a few months to address your comments, so I don't blame you at all for taking a few days to review this one! |
(BTW, I had to merge from |
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 main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
…ments (aws#16376) When performing grants in ECR's Repository class for principals from other accounts, we put the ARN of the principal inside the Resource Policy of the Repository. However, ECR validates that all principals included in its Policy exist at the time of deploying the Repository, so if this cross-account principal was not created before the Repository, its deployment would fail. Detect that situation in the Repository class, and trust the entiure account of the principal if this situation happens. This was spotted by a customer when using the `TagParameterContainerImage` class. Fixes aws#15070 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…ments (aws#16376) When performing grants in ECR's Repository class for principals from other accounts, we put the ARN of the principal inside the Resource Policy of the Repository. However, ECR validates that all principals included in its Policy exist at the time of deploying the Repository, so if this cross-account principal was not created before the Repository, its deployment would fail. Detect that situation in the Repository class, and trust the entiure account of the principal if this situation happens. This was spotted by a customer when using the `TagParameterContainerImage` class. Fixes aws#15070 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…ments (aws#16376) When performing grants in ECR's Repository class for principals from other accounts, we put the ARN of the principal inside the Resource Policy of the Repository. However, ECR validates that all principals included in its Policy exist at the time of deploying the Repository, so if this cross-account principal was not created before the Repository, its deployment would fail. Detect that situation in the Repository class, and trust the entiure account of the principal if this situation happens. This was spotted by a customer when using the `TagParameterContainerImage` class. Fixes aws#15070 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
When performing grants in ECR's Repository class for principals from other accounts,
we put the ARN of the principal inside the Resource Policy of the Repository.
However, ECR validates that all principals included in its Policy exist at the time of deploying the Repository,
so if this cross-account principal was not created before the Repository,
its deployment would fail.
Detect that situation in the Repository class,
and trust the entiure account of the principal if this situation happens.
This was spotted by a customer when using the
TagParameterContainerImage
class.Fixes #15070
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license