What you receive
You receive a working secret management path, from an encrypted file in Git to a SecureString parameter in each of your plat accounts, together with the Git repository that runs it, customized for your organization, and the documentation to operate it. After handover your engineers own the repository and every secret in it.
How delivery works
The blueprint is part of the full deployment tier, where it is one of the two blueprints chosen alongside the Baseline, or is deployed on its own for customers who already run the Baseline. In both cases the BuiltForProd team deploys it. See blueprints for how the three blueprints fit together and purchasing and licensing for the terms.
The repository
acme-aws-blueprint-secrets, where acme is your namespace:
| Item | What it does |
|---|---|
.sops.yaml | Routes each stage folder to its own KMS key, so SOPS picks the right key by path |
sandbox/, dev/, staging/, prod/ | One encrypted YAML file per application per stage; two example applications show the layout |
.github/CODEOWNERS | Developers review sandbox and dev; platform leads or infrastructure admins review staging, prod and tooling |
.github/workflows/plan.yml | On a pull request: checks each stage for template placeholders and lists the parameters it would write |
.github/workflows/sync.yml | On merge to main: decrypts each stage and writes its parameters into that stage's account |
scripts/validate.sh | The placeholder check |
scripts/push-to-ssm.sh | Decrypts a stage's files and writes each key as a SecureString parameter |
The example applications ship with every value set to PLACEHOLDER, and the placeholder check refuses them. Your real values replace them before the first sync.
What is set up for you
- The four stage folders, each tied to its stage's key and its stage's account.
- Your namespace, region, GitHub organization and team handles in the configuration, the review rules and the workflows.
- GitHub Environments named after the four stages;
stagingandprodrequire approval from the platform leads before their sync runs.
What comes from the Baseline
The blueprint uses pieces the AWS Baseline already creates in your accounts:
- The four SOPS keys in the security account, one per stage, with key policies that limit staging and prod to the leads.
- The syncer role in the security account, which only this repository can assume, and a lookup that maps each stage to its account.
- A deployer role in each plat account that trusts the syncer role, so the sync can write into that account.
- The Identity Center groups and permission sets the key policies match.
The blueprint adds no infrastructure of its own. Read the architecture overview to see how the pieces connect.
The documentation
This documentation set: the architecture and key topology, the path convention, both workflows and both scripts, the role chain, the environment protection, day-2 procedures for editing, adding and removing secrets and applications, how workloads consume the parameters, the governance model and the incident playbook.
How it fits with the other blueprints
The Web App Blueprint reads Parameter Store through the External Secrets Operator, and its operator may read every parameter under its stage's prefix, so a value this blueprint writes can be mapped into the application's pods as an environment variable without an IAM change.