Secrets: Parameter Store and Secrets Manager

Your pipeline and your applications need secrets — database passwords, API keys, tokens. You already know the cardinal rule from the DevOps Foundation: secret values never live in code. This lesson is where they do live on AWS — Parameter Store and Secrets Manager — and how applications and pipelines get them safely. It closes the pipelines module, and it is the AWS-specific realisation of the Foundation's secrets lesson.

The rule, restated for AWS

The absolute rule from the Foundation holds: no secret values in Git, in images, or in workflow files. On AWS, secret values live in a managed secrets store, applications and pipelines fetch them at runtime with temporary credentials (the keyless access pattern), and your code contains only a reference to the secret — never the value. AWS gives you two managed stores for this: SSM Parameter Store and Secrets Manager.

Parameter Store and Secrets Manager

Both store configuration and secrets, retrieved by name via the AWS API, with access controlled by IAM. They overlap, and choosing between them is a common question:

• SSM Parameter Store — stores configuration and secrets as named parameters. SecureString parameters are encrypted with KMS. It is simple and free (standard tier), good for general configuration and secrets that do not need rotation. Much non-secret config (feature flags, endpoints) and many secrets live here.
• AWS Secrets Manager — purpose-built for secrets, with features Parameter Store lacks: automatic rotation (it can rotate a database password on a schedule, updating both the secret and the database), built-in integration for RDS credentials, and cross-region replication. It costs per secret per month.

The practical choice: use Parameter Store for configuration and simple secrets (cheap, sufficient); use Secrets Manager when you need rotation or its database-credential integration — chiefly for high-value credentials like production database passwords, where automatic rotation materially reduces risk. Many teams use both: Parameter Store for the bulk of config, Secrets Manager for the credentials that warrant rotation. Both keep the value out of your code and control access by IAM.

How applications get secrets

An application on EKS or ECS gets its secrets at runtime, without any stored keys, using the keyless patterns from earlier modules:

• Fetch via the AWS SDK with IRSA/task role. The app's pod (IRSA — the workloads lesson) or ECS task (task role) has an IAM role permitting it to read its specific secrets, and the AWS SDK fetches them at startup. Least privilege applies: the role can read only the secrets that app needs.
• Inject via the Secrets Store CSI driver / External Secrets Operator (EKS — the workloads lesson) — the cluster pulls the secret from Secrets Manager/Parameter Store and presents it to the pod as a file or Kubernetes Secret, so the real value comes from the managed store, not a committed Kubernetes Secret.
• ECS task definitions can reference secrets directly — a task definition can name a Secrets Manager or Parameter Store secret, and ECS injects it as an environment variable at launch, fetched with the task role.

In every case the app receives the secret value at runtime from the managed store, authenticated by its IAM role — and the secret's value never appears in the image, the manifest, the task definition, or Git. Only the reference (the secret's name/ARN) and the permission (the IAM role) are in your configuration. This is the Foundation's "values in a secrets manager, references in code" principle, realised on AWS.

How the pipeline gets secrets

The pipeline itself needs some secrets (to authenticate, to deploy), and it follows the same discipline:

• AWS access: via OIDC and an assumed role (the pipeline-design lesson) — no stored AWS key.
• Other secrets the pipeline needs: stored as GitHub Actions secrets (the Foundation) or fetched from Parameter Store/Secrets Manager using the assumed role during the run — never hard-coded in the workflow.
• The pipeline should not print secrets — masked in logs (the Foundation), and it passes secrets to the deploy (e.g. into a Kubernetes Secret or via the CSI driver) without exposing them.

So neither the running application nor the pipeline ever holds a long-lived secret in code: the app fetches from the managed store via its role, the pipeline authenticates via OIDC and fetches what it needs via its role.

Rotation, least privilege, and audit

Three practices that make AWS secrets management genuinely secure (tying to the IAM and Foundation lessons):

• Rotate high-value secrets. Secrets Manager can rotate a database password automatically; a rotated secret limits the damage of a leak (an old value stops working). Rotate what matters, and rotate immediately if a secret is ever exposed (the Foundation's "if committed, rotate now").
• Least privilege on secret access. An IAM policy should grant each role read access to only its own secrets (Resource scoped to specific secret ARNs — the IAM lesson), not all secrets in the account. So a compromised app can read only its secrets, not everyone's.
• Audit access. Both stores log access via CloudTrail, so you can see who or what read a secret — useful for investigating an incident.

The complete picture: secret values live in Parameter Store (simple) or Secrets Manager (rotation), encrypted with KMS; applications and pipelines fetch them at runtime via least-privilege IAM roles (IRSA/task role/OIDC); values never appear in code, images or manifests; high-value secrets are rotated; and access is audited. That is how production AWS handles secrets — and it is the Foundation's rule ("values in a manager, references in code") made real with AWS's managed stores and keyless access.

Check your work

The rule (for AWS): no secret values in Git/images/workflows; values live in a managed store, fetched at runtime with temporary credentials; code holds only a reference.

Two stores: Parameter Store (named params, SecureString KMS-encrypted, simple + free — general config and simple secrets) vs Secrets Manager (purpose-built: automatic rotation, RDS integration, replication; costs per secret). Use Parameter Store for config/simple secrets; Secrets Manager when you need rotation (e.g. prod DB passwords). Often both.

Apps get secrets: via the AWS SDK with IRSA/task role (least privilege — only its secrets), the Secrets Store CSI driver / External Secrets Operator, or ECS task-definition secret references. Value arrives at runtime; never in image/manifest/Git — only the reference + IAM permission are in config.

Pipeline gets secrets: AWS access via OIDC (no stored key); other secrets from GitHub Actions secrets or the stores via its role; masked in logs; never hard-coded.

Secure practices: rotate high-value secrets (and immediately if exposed); least privilege per role (scope Resource to specific secret ARNs); audit access via CloudTrail.

Practice

1. Restate the secrets rule and how it is realised on AWS (where values live, what's in code).
2. Compare Parameter Store and Secrets Manager and say when you'd use each.
3. Explain how an EKS pod gets a secret at runtime without any stored key, naming the mechanisms.
4. Explain how the pipeline authenticates and fetches secrets without a hard-coded AWS key.
5. Explain why secret rotation reduces risk, and what you do if a secret is exposed.
6. Write (in words) a least-privilege policy approach so an app role can read only its own secrets.

Official documentation

• AWS — Secrets Manager user guide — Storing and rotating secrets.
• AWS — SSM Parameter Store — Named parameters and SecureString.
• AWS — Choosing Parameter Store vs Secrets Manager — When to use each.

Next: the Observability module.