KMS
AWS Key Management Service (KMS) creates and stores the encryption keys other AWS services use to encrypt data at rest. The platform encrypts everything at rest, and creates its own keys only where controlling the key policy matters.
What it does
A KMS key never leaves the service; applications ask KMS to encrypt or decrypt small pieces of data, and services such as S3 use it to wrap the data keys that protect objects. Each key has a key policy that says who may use it and who may administer it, which is a second access control on top of IAM. A customer-managed key (CMK) is one you create and whose policy you write. An AWS-managed key is created by a service on your behalf; it costs nothing extra and its policy is fixed. Automatic rotation replaces the key material every year without changing the key id. An alias is a friendly name such as alias/acme-sops-dev.
How BuiltForProd uses it
The AWS Baseline creates customer-managed keys where the key policy is itself a control:
| Key | Where | What it protects | Notes |
|---|---|---|---|
| Audit log key | modules/audit-log-bucket, core-audit | The audit bucket and the organization CloudTrail | Annual rotation; key policy lets CloudTrail, Config and Flow Logs write and authorized principals read across the organization |
alias/acme-sops-sandbox, -dev, -staging, -prod | modules/sops-kms, core-security | The SOPS-encrypted files in the secrets blueprint | One key per stage; leads may use all four, engineers only sandbox and dev, the syncer role may decrypt only |
| DNSSEC key-signing keys | modules/route53-zones/dnssec.tf, core-dns, us-east-1 | Signing of the apex, prod and staging public zones | Asymmetric ECC_NIST_P256; about $1 per month each |
ECR repositories in core-artifacts are created with KMS encryption, and the account baseline turns on EBS default encryption in every account. Elsewhere the platform relies on AWS-managed keys: the state bucket and the data-lake buckets use SSE-KMS with the default S3 key, SSM SecureString parameters, the security alerts SNS topic and EKS secrets encryption use their services' default keys, and the frontend and shared artifact buckets use SSE-S3. The design decisions record this split as deliberate: CMKs are reserved for data whose access must be governed by key policy, which keeps key sprawl and cost down.
Key policies are how the secrets blueprint enforces its access matrix. Whether a developer can read a production secret is decided by the alias/acme-sops-prod key policy, not by GitHub permissions, and the same policy is what lets the acme-secrets-syncer role decrypt during a sync.
Terms you will see
| Term | Meaning |
|---|---|
| Customer-managed key (CMK) | A key you create and whose policy you control. |
| AWS-managed key | A key a service creates for you; free, with a fixed policy. |
| Key policy | The resource policy on a key; the platform uses it to decide who can read which secrets. |
| Alias | A name that points at a key, such as alias/acme-sops-dev. |
| SSE-KMS and SSE-S3 | Server-side encryption of S3 objects with a KMS key, or with keys S3 manages itself. |
| Key rotation | Yearly replacement of key material under the same key id. |
| Asymmetric key | A public and private key pair; used here as the DNSSEC signing key. |
Where to read more
- AWS Baseline overview for the security services these keys support.
- Secrets Blueprint overview for how the per-stage keys are used day to day.
- S3 for every bucket and its encryption setting.