Secrets
Secrets encrypted in Git, decrypted only by the identities that should be able to. Reviewed like code, enforced by cryptography.
What it is
The Secrets Blueprint is a centralized secret management pattern delivered as one repository and deployed into your BuiltForProd Baseline. Secrets live encrypted in Git with SOPS, one file per application per stage. Each stage — sandbox, dev, staging and production — has its own AWS KMS key in the security account. On merge, the values are synced to SSM Parameter Store as SecureStrings, and External Secrets Operator delivers them to workloads.
The point is not storage. Every team has somewhere to put secrets. The point is that the question “who can read the production database password?” has an answer that does not depend on anyone behaving well.
A developer with repository write access still cannot read a production secret, because KMS refuses the request.
How a secret moves
One SOPS-encrypted file per application per stage. The keys are readable, the values are ciphertext. Changes arrive as pull requests, so a secret change is reviewed exactly like a code change, with history.
A separate customer-managed KMS key per stage, held in the security account. The stage boundary is a key boundary: access to dev grants nothing in production.
A syncer role with permission to use that stage’s key writes the value into SSM Parameter Store as a SecureString. The pipeline does the writing; nobody decrypts anything on a laptop.
External Secrets Operator pulls the parameter into the cluster and a read-only role consumes it. The application receives a value; it never receives the means to read any other one.
Separation of duties
For staging and production, changing a secret takes five distinct roles. No single person holds the whole path.
The lead writes
A platform or DevOps lead makes the change in the encrypted file.
A second code owner approves
CODEOWNERS requires a reviewer who did not write the change.
-
An environment reviewer approves
The protected environment adds a second, separate approval before anything is applied.
The syncer role writes
Only the pipeline identity may use the stage key and write the parameter.
A read-only role consumes
The workload reads the value and can do nothing else with the key.
What this gives an auditor
A documented, enforced answer to “who can read production secrets?” backed by key policies and pull request history rather than by an assurance. How evidence is produced.
When something goes wrong
An incident playbook
Five scenarios written out in advance, including a plaintext value committed by mistake and a compromised key. Rehearsed beats improvised at two in the morning.
A rotation procedure
Seven documented steps. Rotation is manual and the documentation says so, because a procedure you believe is automated and is not is worse than one you know you have to run.
A check that blocks placeholders
A pull request check fails on any remaining placeholder value, so a stage is never deployed with a secret that was meant to be filled in later.
When teams choose this Blueprint
| Situation | What it changes |
|---|---|
| Secrets live in .env files, CI variables and chat messages | One encrypted, versioned home per application per stage, reviewed like code. |
| An auditor asks who can read production secrets | A KMS-enforced answer with key policies and approval history behind it. |
| A secret was committed in plaintext | A written playbook and a rotation procedure, rather than a scramble to work out the blast radius. |
| A contractor or a departing engineer had broad access | Removing their access removes their ability to decrypt, immediately and everywhere. |
Questions about this Blueprint
What is the Secrets Blueprint?
The Secrets Blueprint is a centralized secret management pattern delivered as one repository and deployed into your BuiltForProd Baseline. Secrets live encrypted in Git with SOPS, are encrypted under a separate AWS KMS key per stage, and are synced to SSM Parameter Store as SecureStrings when a change is merged.
How can a secret live in Git safely?
Because what is in Git is ciphertext, and the key that decrypts it lives somewhere else. SOPS encrypts each value under an AWS KMS key held in the security account, one key per stage. The repository stores the encrypted file; the ability to read it is an IAM and KMS decision, not a repository permission.
Who can read a production secret?
Only the identities granted use of the production KMS key. A developer with write access to the repository still cannot read or change a production secret, because AWS KMS refuses the request. That is a cryptographic boundary rather than a convention, which is what makes it demonstrable to an auditor.
How does a secret reach a workload?
On merge, a syncer role writes the decrypted value into SSM Parameter Store as a SecureString. External Secrets Operator then delivers it into the cluster, and a read-only role consumes it. The application never sees the repository and the repository never sees the plaintext.
Is rotation automated?
No, and the documentation says so plainly. Rotation is a documented seven-step manual procedure, and the Blueprint ships an incident playbook covering five scenarios, including a plaintext value committed by mistake and a compromised key. What is automated is the check that blocks a placeholder value from being merged.
What infrastructure does it add?
Almost none of its own. The Secrets Blueprint uses the KMS keys, the Parameter Store and the pipelines that already exist in the Baseline, which is why it is usually the cheapest Blueprint to add and the first one teams want after the foundation.
See the whole catalog, the Baseline it deploys into, or how this fits the wider credential model — where no long-lived cloud key exists for anyone.
Find out what production would take.
Tell us what you are running and what is coming: a funding round, an audit, a first enterprise customer, a migration. We will tell you what we would build, what it costs, and whether we are the right fit.