Project walkthrough
Kubernetes secrets with AWS Secrets Manager: sync is only half the workflow
Keeping credentials out of Git is a useful starting point. The rest of the workflow needs just as much care: who can read each secret, how it reaches Kubernetes and when the application starts using a changed value.
- AWS Secrets Manager
- IRSA authentication
- External Secrets Operator
- Kubernetes Secret
- Application consumption
Follow a single credential
The repository defines an ExternalSecret that maps the password and username properties of myapp/database into a Kubernetes Secret. Its refresh interval is one hour. A ClusterSecretStore supplies the AWS provider settings and references the service account used for authentication.
- Match the store name, region and remote secret path.
- Check that the IAM role trusts the exact service account and namespace.
- Keep secret values out of commits, screenshots and diagnostic output.
Make namespace isolation real
A shared ClusterSecretStore is a different trust decision from a namespace-scoped SecretStore. The example namespace-scoped store needs review: its service-account reference points to the operator namespace. For namespace-scoped authentication, align the service account, store and workload namespace with the supported provider configuration.
- Review which teams can create ExternalSecret resources against a shared store.
- Scope IAM permissions to the secrets the integration actually needs.
- Render Helm templates and verify resource names before applying them.
Plan the application side of rotation
A refreshed Kubernetes Secret does not automatically replace environment variables in an already running container. Applications consuming mounted files also need a reload strategy. Decide whether the workload can reload configuration or needs a controlled rollout, then test the complete rotation path.
- Measure provider update, controller reconciliation and application adoption separately.
- Check readiness and database connection behavior during a credential change.
- Define recovery steps for denied AWS access or a failed application reload.
What I can demonstrate from this repository
The example shows the secret mapping and intended IRSA integration. It does not include runtime evidence of automatic rotation, zero downtime or a compliance audit. I treat those as separate validation work rather than outcomes implied by installing an operator.
Checks to run in your environment
Inspect reconciliation status in an authorized sandbox; do not print Secret payloads.
kubectl -n myapp get externalsecret myapp-database
kubectl -n myapp describe externalsecret myapp-databaseThese are suggested verification steps, not a record of a production test run. Check prerequisites and resource access before using them.
Source and references
Project links point to the exact source revision reviewed for this note.