Topic starter
24/06/2026 9:21 pm
TL;DR: AWS KMS and Secrets Manager can encrypt secrets for Kubernetes and Terraform workflows, but the underlying problem is broader: NHIs, lifecycle gaps, and multi-environment access complexity still create exposure, according to Entro Security. Native encryption helps, yet governance fails when secret storage is treated as the end state rather than one control in a wider identity model.
Editorial analysis by NHI Mgmt Group, based on content published by Entro Security: “Secrets Encryption on AWS with Kubernetes and Terraform”.
Key questions
Q: How should security teams govern secrets in Kubernetes and Terraform environments?
A: Treat secret encryption as one control within a wider NHI programme.
Q: Why do AWS secrets still create risk when they are centrally stored?
A: Central storage reduces exposure, but risk remains when IAM scope is too broad, Terraform state retains plaintext values, or applications cache credentials beyond their intended use.
Q: What breaks when Kubernetes secrets are treated as fully protected after EKS encryption is enabled?
A: The assumption that storage security equals access security breaks immediately.
Practitioner guidance
- Map every secret consumer Inventory which Kubernetes service accounts, CI/CD jobs, and Terraform runners can read or decrypt each secret, then remove any consumer that is not needed for a current deployment path.
- Separate encryption from access governance Keep KMS and Secrets Manager in place, but apply explicit IAM boundaries so decryption rights match the exact automation task and do not bleed across environments.
- Review secret lifecycle ownership Assign a human owner to each NHI-backed secret, including rotation cadence, offboarding criteria, and the point at which the secret should be replaced rather than reused.
Bottom line: AWS encryption features improve confidentiality, but they do not by themselves solve who can retrieve or reuse a secret across automation workflows.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
25/06/2026 6:32 am
Secrets encryption is a confidentiality control, not a governance model: The article correctly shows that KMS and Secrets Manager can protect secret material at rest, but the identity problem remains unchanged. Service accounts, pipelines, and workloads still need lifecycle oversight, access scoping, and revocation discipline. The practitioner takeaway is that encryption reduces exposure, but it does not define who should hold the secret or for how long.
A few things that frame the scale:
- 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to the 2024 State of Secrets Management Survey.
- Enterprises manage far more machine secrets than human ones: 20 times as many according to Enterprise Strategy Group, and 45 times according to GitGuardian.
A question worth separating out:
Q: What should teams do when Terraform needs to read production secrets?
A: Give the Terraform execution identity the narrowest possible secret-read permission, tie it to a named environment, and review it whenever the module or pipeline changes. If the same runner can touch unrelated secrets, the infrastructure workflow has turned into a broader NHI access path than intended.
👉 Read our full editorial: Secrets encryption on AWS with Kubernetes and Terraform
This post was modified 1 day ago by NHI Mgmt Group