feat: Allow access on all indexes of a table in GuDynamoDBPolicy #2024
Conversation
This change includes all table indexes in the blanket GuDynamoDBReadPolicy and GuDynamoDBWritePolicy classes. Without this consumers will see failures querying of updating items in Global Secondary Indexes. Adding read/write access to indexes of a table in these policies is intended to make it easier to use these policies by allowing access to indexes as might be expected.
kenoir
force-pushed
the
rk/allow-read-on-table-indexes
branch
from
dc43562 to
0e463c3
Compare
kenoir
changed the title
kenoir
force-pushed
the
rk/allow-read-on-table-indexes
branch
from
6c74202 to
0a86d82
Compare
| resources: [`arn:aws:dynamodb:${scope.region}:${scope.account}:table/${props.tableName}`], | ||
| resources: [ | ||
| `arn:aws:dynamodb:${scope.region}:${scope.account}:table/${props.tableName}`, | ||
| `arn:aws:dynamodb:${scope.region}:${scope.account}:table/${props.tableName}/index/*`, |
There was a problem hiding this comment.
Are we sure this will work for the actions people are using in practice? There aren't many actions that support indexes as a resource, just the basics like Scan:
https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html
If people have added other action props, this might break their stacks if CloudFormation then rejects the index resource for that action?
There was a problem hiding this comment.
Good question. I've tested that the CloudFormation that gets generated will successfully apply by deploying https://github.com/guardian/crosswordv2/pull/38 to our CODE environment (CF updates successfully and the expected behaviour can be observed with regard to permissions).
I think this is similar to the case where wildcard resources can be applied to sets of actions. See the AmazonDynamoDBReadOnlyAccess managed policy attached.
The documentation that I can find is not explicit on this point, but does state:
If you specify a resource type in a statement with an action that does not support that resource type, then the statement doesn't allow access.
So I believe we're safe from disrupting existing stacks here. I will add a comment describing this to the change as it does seem like a potential point of confusion.
|
🎉 This PR is included in version 50.11.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
What does this change?
This change includes all table indexes in the blanket
GuDynamoDBReadPolicyandGuDynamoDBWritePolicyclasses.Without this consumers will see failures querying or updating items in Global Secondary Indexes.
Adding read/write access to indexes of a table in these policies is intended to make it easier to use these policies by allowing access to indexes as might be expected.
How to test
See: https://github.com/guardian/crosswordv2/pull/38
How can we measure success?
Consumers are able to use the read/write policies in more expected use cases.
Have we considered potential risks?
This does expand the permissions of these policies, but not in a surprising way (probably not in issue as currently consumed).