-
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
feat(integ-tests): expose adding IAM policies to the assertion provider #20769
Conversation
Currently the `AwsApiCall` construct will try and automatically create the correct IAM policy based on the service and api call being used. The assumption was that in most cases this would work, but it turns out that in the first couple use cases we've seen this is not the case. This PR adds another method `addToRolePolicy` on the `AssertionsProvider` construct and then makes the provider a `public` attribute on `AwsApICall`. This allows you to add additional policies.
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.
The ideal solution would be an internal map from operations to necessary policies, that we could generate automatically from some canonical source. But I'm not aware of any such thing :(
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). |
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). |
…er (aws#20769) Currently the `AwsApiCall` construct will try and automatically create the correct IAM policy based on the service and api call being used. The assumption was that in most cases this would work, but it turns out that in the first couple use cases we've seen this is not the case. This PR adds another method `addToRolePolicy` on the `AssertionsProvider` construct and then makes the provider a `public` attribute on `AwsApICall`. This allows you to add additional policies. ---- ### All Submissions: * [ ] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Currently the
AwsApiCall
construct will try and automatically createthe correct IAM policy based on the service and api call being used. The
assumption was that in most cases this would work, but it turns out that
in the first couple use cases we've seen this is not the case.
This PR adds another method
addToRolePolicy
on theAssertionsProvider
construct and then makes the provider apublic
attribute on
AwsApICall
. This allows you to add additional policies.All Submissions:
Adding new Unconventional Dependencies:
New Features
yarn integ
to deploy the infrastructure and generate the snapshot (i.e.yarn integ
without--dry-run
)?By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license