Skip to content
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

Merged
merged 3 commits into from
Jul 7, 2022
Merged

feat(integ-tests): expose adding IAM policies to the assertion provider #20769

merged 3 commits into from
Jul 7, 2022

Conversation

corymhall
Copy link
Contributor

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:

Adding new Unconventional Dependencies:

  • This PR adds new unconventional dependencies following the process described here

New Features

  • Have you added the new feature to an integration test?
    • 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 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.
@gitpod-io
Copy link

gitpod-io bot commented Jun 16, 2022

@github-actions github-actions bot added the p2 label Jun 16, 2022
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Jun 16, 2022
@aws-cdk-automation aws-cdk-automation requested a review from a team June 16, 2022 19:30
Copy link
Contributor

@otaviomacedo otaviomacedo left a 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 :(

packages/@aws-cdk/integ-tests/README.md Outdated Show resolved Hide resolved
@otaviomacedo otaviomacedo added the pr/do-not-merge This PR should not be merged at this time. label Jul 7, 2022
@corymhall corymhall removed the pr/do-not-merge This PR should not be merged at this time. label Jul 7, 2022
@mergify
Copy link
Contributor

mergify bot commented Jul 7, 2022

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).

@mergify mergify bot merged commit c2f40b7 into aws:main Jul 7, 2022
@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
  • Commit ID: a8aad63
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Jul 7, 2022

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).

daschaa pushed a commit to daschaa/aws-cdk that referenced this pull request Jul 9, 2022
…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*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contribution/core This is a PR that came from AWS. p2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants