-
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
(pipelines): missing SecretsManager permissions for asset action role #15628
Labels
@aws-cdk/aws-secretsmanager
Related to AWS Secrets Manager
@aws-cdk/pipelines
CDK Pipelines library
bug
This issue is a bug.
needs-triage
This issue or PR still needs to be triaged.
Comments
hoegertn
added
bug
This issue is a bug.
needs-triage
This issue or PR still needs to be triaged.
labels
Jul 17, 2021
github-actions
bot
added
the
@aws-cdk/aws-secretsmanager
Related to AWS Secrets Manager
label
Jul 17, 2021
rix0rrr
added a commit
that referenced
this issue
Jul 22, 2021
(Longer description here...) (Still needs testing...) (Still needs the KMS key hack taken out...) Fixes #15628.
mergify bot
pushed a commit
that referenced
this issue
Jul 23, 2021
…ts (#15718) We used to use an immutable singleton role with `*` permissions for the assets projects, because if there were many different destinations in a pipeline, and each asset build had to publish to each destination, the policy could grow too long and exceed the maximum policy size. However, this also disabled the automatic policy wrangling that CodeBuild would do for us, like automatically adding permissions to bind to a VPC, and adding permissions to read Secrets Manager secrets. This especially becoming relevant since that now in the modern API, it's possible to modify build the environment in a way that normally automatically adds SecretsManager permission, but now won't (and it's not possible to fix either). Replace the immutable singleton role with a mutable singleton role, but in such a way that it won't add permissions statements for which it already has a `*` statement (to cut down on duplication), and have the CB project do the automatic VPC bind permissions again. Fixes #15628. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
TikiTDO
pushed a commit
to TikiTDO/aws-cdk
that referenced
this issue
Aug 3, 2021
…ts (aws#15718) We used to use an immutable singleton role with `*` permissions for the assets projects, because if there were many different destinations in a pipeline, and each asset build had to publish to each destination, the policy could grow too long and exceed the maximum policy size. However, this also disabled the automatic policy wrangling that CodeBuild would do for us, like automatically adding permissions to bind to a VPC, and adding permissions to read Secrets Manager secrets. This especially becoming relevant since that now in the modern API, it's possible to modify build the environment in a way that normally automatically adds SecretsManager permission, but now won't (and it's not possible to fix either). Replace the immutable singleton role with a mutable singleton role, but in such a way that it won't add permissions statements for which it already has a `*` statement (to cut down on duplication), and have the CB project do the automatic VPC bind permissions again. Fixes aws#15628. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
hollanddd
pushed a commit
to hollanddd/aws-cdk
that referenced
this issue
Aug 26, 2021
…ts (aws#15718) We used to use an immutable singleton role with `*` permissions for the assets projects, because if there were many different destinations in a pipeline, and each asset build had to publish to each destination, the policy could grow too long and exceed the maximum policy size. However, this also disabled the automatic policy wrangling that CodeBuild would do for us, like automatically adding permissions to bind to a VPC, and adding permissions to read Secrets Manager secrets. This especially becoming relevant since that now in the modern API, it's possible to modify build the environment in a way that normally automatically adds SecretsManager permission, but now won't (and it's not possible to fix either). Replace the immutable singleton role with a mutable singleton role, but in such a way that it won't add permissions statements for which it already has a `*` statement (to cut down on duplication), and have the CB project do the automatic VPC bind permissions again. Fixes aws#15628. ---- *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
@aws-cdk/aws-secretsmanager
Related to AWS Secrets Manager
@aws-cdk/pipelines
CDK Pipelines library
bug
This issue is a bug.
needs-triage
This issue or PR still needs to be triaged.
If you specify environment variables of the SecretsManager for the CodeBuild projects, only the synth and the self-mutate action have the appropriate IAM permissions but all actions get the environment config.
Reproduction Steps
If the stack/stage contains assets the asset upload project has the environment config
but the role does not have the needed
secretsmanager:GetSecretValue
permissions. The roles for synth and self-mutate do get the permissions.What did you expect to happen?
The asset upload role has the needed permissions
What actually happened?
No permissions are granted
Environment
Other
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: