-
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(dynamodb): grant also gives access to indexes #1564
Conversation
If a table has an index, the `grant()` methods will give permissions to the index as well. Updates the security diff engine to support `AWS::NoValue`. Fixes #1540.
@@ -429,7 +429,7 @@ export class Table extends Construct { | |||
return; | |||
} | |||
principal.addToPolicy(new iam.PolicyStatement() | |||
.addResource(this.tableArn) | |||
.addResources(this.tableArn, new cdk.Token(() => this.hasIndex ? `${this.tableArn}/index/*` : new cdk.Aws().noValue).toString()) |
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.
Why not just always add the index?
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.
Because this won't throw up IAM diffs to everyone who's already deployed an indexless table.
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.
ha! not a bad reason. thanks.
also, wondering perhaps addResource
can just ignore undefined
, so you don't need to specify noValue
. A bit more "cdk-native", no?
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.
Agreed, although according to the typing addResource()
takes a string
and not a string | undefined
. It would be annoying if a stringified Token would change its type halfway through processing...
(Nothing preventing you from doing that today, but I'm not sure our code would be robust against it).
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.
Got it. No worries.
Is this the desired behavior? What if I want to give access to the table but not the index? |
That's a question in line with "what if I only want to give It's a valid question, but I would say those cases are rare and we're optimizing for the common case where this "just work". My response to this would be that if you really care, you can throw an IAM policy together yourself? |
If a table has an index, the `grant()` methods will give permissions to the index as well. Updates the security diff engine to support `AWS::NoValue`. Fixes #1540.
I'm seeing a problem similar to the original one from #1540, and this fix is not working for me using 1.20.0. There are a couple of difference in my env from the original issue:
I'm still getting the same error: Is the expectation that this fix should apply to my case? |
@cursive-ide the issue is that we do not (currently) support adding permissions on the index for imported Tables. If you look in the code, you'll see that the index resource is only added if the What we would need to do is add extra attributes to the const licenceOrder = dynamodb.Table.fromTableAttributes(this, 'LicenceOrderTable', {
tableName: 'licence-order',
globalIndexes: ['my-global-index-name'],
localIndexes: ['my-local-index-name'],
}); This would also allow us to implement methods like Does this solution make sense @cursive-ide ? |
@skinny85 yes, I think so. Is there a good mechanism for importing existing resources to CDK for cases like this? My tables have production data so I would rather not delete & recreate them, but it seems unfortunate to have to repeat similar table schema information in a different format. Is it feasible to allow tables to be created using existing CDK syntax but to allow a |
Not really, no, and I'm not sure how that solves the repetition problem you mentioned. |
Ok, I suspected that might be hard. Never mind, I think your solution will work fine for my case. |
BTW is there a good workaround for this in the meantime? |
Probably adding the permissions "manually" (basically, doing what the role.addToPolicy(new iam.PolicyStatement({
actions: ['dynamodb:*'], // probably want to scope it down to something more manageable
resources: [`${this.tableArn}/index/*`],
})); |
@skinny85, I just hit the same problem as @cursive-ide. I applied your workaround. However, could we add an additional parameter to the Something along the line:
|
I don't think this is the correct solution. Instead, we should do what I mentioned in this comment. I've opened a feature request to do that: #6392 |
I'm having the same issue when importing a dynamo table, |
This totally just bit me. Really needs to be clearer in docs |
If a table has an index, the
grant()
methods will give permissions tothe index as well.
Updates the security diff engine to support
AWS::NoValue
.Fixes #1540.
Pull Request Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.