-
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
S3 Bucket grant* stopped working in 1.20.0 #5740
Comments
@jeshan is |
Sorry, I didn't realise that that was relevant. It is indeed created with fromRoleArn: Role.fromRoleArn(
this,
'deployment-account-role',
`arn:aws:iam::123456789012:role/deployment-role`,
); and I'm creating the bucket with something like: this.publicBucket = new Bucket(this, 'bucket', {
publicReadAccess: true,
bucketName: 'my-public-bucket',
}); |
I believe the change that's causing this issue for you, landed in this PR #5568 |
OK. I'm trying with a newly created role just now (with 1.20) and I'm getting the same incorrect behaviour: let myRole = new Role(this, 'dep-role', {
assumedBy: new ServicePrincipal('...'),
managedPolicies: [
ManagedPolicy.fromAwsManagedPolicyName(
'...',
),
],
}); |
For a new role, that's been the expected behaviour. |
I don't understand. Why would it be different for new v/s imported ones? How else would you reference a role in a bucket policy? |
Normally you wouldn't add the permissions to the bucket but to the role. Since this is an imported role we assume the permissions have already been added to the role and we don't add them to the bucket. On the other hand, this is an imported role from another account (seems like?), in which case the permissions need to be added to BOTH the resource and the role. For the moment, you can work around this by using Sorry for the problems this has caused. |
Trust policies should be added to resources when trying to grant permissions to a principal in a different account. Typically this is a Service Principal, but it could also be an imported Role from a different account (and the same should not be done for a Role in the same account). Our previous API (`addToPolicy` returning `true|false`) was designed for in-account Roles and cross-account ServicePrincipals, but was not rich enough to make the distinction that Roles could be cross-account. Add a function to `IPrincipal` to ask it whether it is in the same or a different account from a given scope, and have `Grant` respect that. Also in this commit: a bugfix for `ImmutableRole` to make it work correctly with `Grant` Also in this commit: `parseArn()` used to behave the same for `parseArn(TOKEN)` and `parseArn("arn:{TOKEN}:svc:1234:...")`. Make it (opportunistically) do the right thing in the latter case, parsing out the concrete components and the TOKEN components separately. This makes it possible to parse out the concrete account number from an ARN that contains tokenized parts we don't care about. Fixes #5740.
Trust policies should be added to resources when trying to grant permissions to a principal in a different account. Typically this is a Service Principal, but it could also be an imported Role from a different account (and the same should not be done for a Role in the same account). Our previous API (`addToPolicy` returning `true|false`) was designed for in-account Roles and cross-account ServicePrincipals, but was not rich enough to make the distinction that Roles could be cross-account. Add a function to `IPrincipal` to ask it whether it is in the same or a different account from a given scope, and have `Grant` respect that. Also in this commit: a bugfix for `ImmutableRole` to make it work correctly with `Grant` Also in this commit: `parseArn()` used to behave the same for `parseArn(TOKEN)` and `parseArn("arn:{TOKEN}:svc:1234:...")`. Make it (opportunistically) do the right thing in the latter case, parsing out the concrete components and the TOKEN components separately. This makes it possible to parse out the concrete account number from an ARN that contains tokenized parts we don't care about. Fixes #5740.
Add the `account` and `region` properties to the `IResource` interface and `Resource` class. By default, these are equal to the account and region of the Stack the resource belongs to; however, they can be set to different values in resources that are imported. Use those new properties in two places: * In CodePipeline, to determine whether a given action is cross-account (with support for specifying the account and region in S3's `BucketAttributes`, as a first use case). * IAM's `addToPrincipalOrResource()`, to correctly know when to modify the receiver's resource policy. This is aided by adding an optional `principalAccount` property to `IPrincipal`, as a way to compare to the account present in the passed `IResource` instance. Fixes #2807 Fixes #5740 Fixes #7012 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
I've upgraded cdk (and aligned their modules as well) from 1.16.3(?) to 1.20.0 and I noticed that bucket policies that I created with the following stopped working
Reproduction Steps
What I saw with
cdk diff
1.20.0:If I renamed the bucket, I'd get:
So, it suggests that it's broken for new and existing buckets as well.
It's not just the diff that was wrong; when I did
cdk deploy
, the bucket policy was actually gone.Downgrading cdk (and the node modules) to 1.19.0:
I saw iam policies are back to what I had before:
Environment
I didn't spot any breaking change notice in the release notes at:
https://github.com/aws/aws-cdk/releases/tag/v1.20.0
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: