docs(aws-cloud): grant Secrets Manager write for pipeline secrets#1643
Open
pditommaso wants to merge 2 commits into
Open
docs(aws-cloud): grant Secrets Manager write for pipeline secrets#1643pditommaso wants to merge 2 commits into
pditommaso wants to merge 2 commits into
Conversation
The AWS Cloud Secrets Manager inline policy only granted read (GetSecretValue/ListSecrets). Seqera also creates each referenced pipeline secret in Secrets Manager when a pipeline launches and deletes it on completion, so the credential needs CreateSecret + DeleteSecret (scoped to tower-*). This is what enables Seqera Platform pipeline secrets on AWS Cloud / Intelligent Compute compute environments. Also splits ListSecrets into its own statement scoped to '*': secretsmanager:ListSecrets does not support resource-level permissions, so scoping it to tower-* (as before) denied the call used during secret cleanup. Signed-off-by: Paolo Di Tommaso <paolo.ditommaso@gmail.com>
✅ Deploy Preview for seqera-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
stefanoboriero
approved these changes
Jul 9, 2026
Contributor
|
Thanks, @pditommaso! Is this good to merge now or is there a specific date in mind? |
Contributor
Author
|
Leaving to @MichaelTansiniSeqera that's coordinating this |
justinegeffen
added
1. Editor review
Rewrite the introducer for the Secrets Manager inline policy to match the label→purpose shape of the sibling S3 and KMS entries: swap "lets Seqera manage" for "grants access to", drop the semicolon-joined "reads it at task startup" clause (implied by GetSecretValue in the policy below), and cut the trailing "Required for..." fragment that restated the opening clause. Wording kept identical across the cloud (.mdx) and enterprise (.md) mirrors. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Updates the Secrets Manager inline policy in the AWS Cloud / Intelligent Compute IAM setup so that Seqera Platform pipeline secrets work on these compute environments.
Applies to both current pages (versioned snapshots left unchanged):
platform-enterprise_docs/compute-envs/aws-cloud.mdplatform-cloud/docs/compute-envs/aws-cloud.mdxWhy
The documented Secrets Manager inline policy only granted read (
GetSecretValue,ListSecrets). But at launch Seqera creates each referenced pipeline secret in AWS Secrets Manager (astower-<workflowId>/<name>) and deletes it on completion — so the Seqera IAM credential also needsCreateSecretandDeleteSecret. Without them, pipelines that reference Seqera pipeline secrets fail to launch on AWS Cloud / Intelligent Compute.This mirrors the scheduler-side change in seqeralabs/sched (the
seqera-aws-cloud-policyin the CloudFormation stack gains the same grants). The scheduler-created ECS execution role'sGetSecretValuegrant is attached by the scheduler itself and needs no customer-facing change.Changes
secretsmanager:CreateSecretandsecretsmanager:DeleteSecret(scoped totower-*) alongside the existingGetSecretValue.secretsmanager:ListSecretsinto its own statement onResource: "*"—ListSecretsdoes not support resource-level permissions, so scoping it totower-*(as before) silently denied the list call used during secret cleanup.Notes
Draft: the Intelligent Compute pipeline-secrets feature is in preview and the scheduler-side support is not yet released. Merge alongside that release. Ready to flip out of draft on request.
🤖 Generated with Claude Code