Notifications
Clear all
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.
NHIMG editorial — based on content published by Entro Security: Secrets encryption on AWS with Kubernetes and Terraform
Questions worth separating out
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 encrypted secrets still create risk in cloud automation?
A: Because encryption protects storage, not entitlement.
Q: What do teams get wrong about secrets rotation in multi-cloud environments?
A: They often rotate the credential but leave the surrounding identity pattern unchanged.
Practitioner guidance
- Separate secret storage from execution identity governance Map every Terraform, Kubernetes, and application identity that can retrieve or decrypt a secret, then restrict each one to the smallest workable secret path and environment scope.
- Audit KMS and Secrets Manager permissions together Review decrypt, get-secret-value, and key usage permissions as one control set so the team can see where a non-human identity can move from ciphertext to plaintext.
- Remove plaintext secrets from code and state artefacts Ensure Terraform code, plan files, and state files never carry live credentials, and move all runtime secret retrieval into controlled execution roles with clear ownership.
What's in the full article
Entro Security's full blog post covers the implementation detail this post intentionally leaves at a governance level:
- Step-by-step EKS secrets encryption setup with eksctl, YAML, AWS Console, and AWS CLI examples.
- Terraform examples that pull JSON-formatted secrets from AWS Secrets Manager and decode them safely into resource configuration.
- Operational notes on IAM permissions for Terraform execution roles and how those permissions affect secret retrieval.
- A cloud-native walkthrough of KMS and Secrets Manager integration that helps teams validate their own implementation choices.
👉 Read Entro Security's guide to AWS secrets encryption with Kubernetes and Terraform →
Kubernetes, Terraform, and AWS secrets encryption: what teams miss?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 6:32 am
Secrets encryption is a control, not a governance model: Encrypting secrets in AWS reduces exposure at rest, but it does not answer who may retrieve them, when, or across which execution paths. That distinction matters because NHI governance failures usually appear after encryption is already in place. Practitioners should treat encryption as the minimum cryptographic layer, not the endpoint of secrets governance.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- A separate finding from the same report shows that 23.7% of organisations share secrets through insecure methods such as email or messaging applications.
A question worth separating out:
Q: How do organisations know whether their secrets governance is actually working?
A: Look for fewer identities with decrypt rights, fewer hardcoded credentials in code and state, and clear evidence that retired workloads can no longer access secret paths. If secret use still depends on manual exceptions or shared automation roles, governance is present in theory but not in practice.
👉 Read our full editorial: Secrets encryption on AWS with Kubernetes and Terraform
