Secrets encryption on AWS with Kubernetes and Terraform

At a glance

What this is: This is a technical guide on encrypting AWS secrets across Kubernetes and Terraform, with the main point that encryption alone does not solve NHI governance complexity.

Why it matters: It matters because IAM, PAM, and NHI teams still need to govern who or what can retrieve, rotate, and decommission secrets across cloud and IaC workflows.

👉 Read Entro Security's guide to AWS secrets encryption with Kubernetes and Terraform

Context

Secrets encryption in AWS is a control problem as much as a cryptography problem. In Kubernetes and Terraform environments, the real issue is not whether a secret can be stored in encrypted form, but whether the identities that create, retrieve, and reuse that secret are governed consistently across systems. In AWS-heavy estates, that usually means non-human identities, not just human administrators.

Kubernetes, Terraform, KMS, and Secrets Manager each solve part of the exposure surface, but none of them on their own resolve lifecycle, privilege, and cross-environment consistency. The article is best read as a reminder that secret encryption is only one layer in NHI governance, especially where service accounts, automation tooling, and infrastructure code all touch the same credentials.

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. Teams should map every non-human identity that can read, decrypt, or pass a secret, then limit access by workload, environment, and purpose. The goal is not only to hide the secret, but to constrain every execution path that can turn ciphertext back into usable credentials.

Q: Why do encrypted secrets still create risk in cloud automation?

A: Because encryption protects storage, not entitlement. If a Terraform role, Kubernetes controller, or CI pipeline can decrypt broadly, the secret is still operationally available to any process that inherits that access. Risk falls only when decryption rights, retrieval rights, and secret lifetime are all tightly scoped.

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. If the same service account, pipeline role, or workload can still request the new secret, the exposure model barely changes. Rotation only helps when paired with access reduction, ownership clarity, and offboarding of unused non-human identities.

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.

Technical breakdown

How AWS KMS envelope encryption protects secrets

AWS Secrets Manager typically relies on envelope encryption, where KMS generates and protects a data key that is then used to encrypt the secret value itself. The plaintext key is discarded after use, which reduces exposure in storage and retrieval paths. This model is strong for confidentiality at rest, but it does not determine who should be allowed to request decryption or under what operational conditions.

Practical implication: treat KMS as the cryptographic boundary and IAM as the access boundary, then review both together.

Kubernetes secrets encryption still leaves identity risk

Kubernetes secrets are often backed by etcd, and enabling EKS secrets encryption means the API server encrypts new secrets before storing them. That removes plaintext from the storage layer, but the control plane still has to decrypt for authorised reads. In other words, encryption reduces storage exposure, while the identity and policy layer still governs runtime access to the secret.

Practical implication: pair etcd encryption with tight Kubernetes RBAC, API server access controls, and secret consumption review.

Terraform and secrets manager integration changes the exposure model

When Terraform pulls credentials from AWS Secrets Manager, the secret no longer needs to live inside code or state files in plaintext, which is a major reduction in accidental exposure. But Terraform still runs as a non-human execution identity with access to the secret path, so the relevant question becomes whether that execution role is scoped to the minimum necessary resources and environments.

Practical implication: bound Terraform execution roles to specific secret paths and isolate state, plan, and apply permissions.

Threat narrative

Attacker objective: The objective is to turn one exposed secret into broader infrastructure control and data access across AWS, Kubernetes, and Terraform workflows.

1. Entry occurs through overexposed secrets in infrastructure code, CI/CD paths, or cluster storage rather than through a classic exploit chain.
2. Credential access follows when KMS, Secrets Manager, or Kubernetes RBAC permits broad read or decrypt actions for non-human identities.
3. Impact appears as uncontrolled infrastructure provisioning, unauthorized database access, or lateral movement across cloud workloads through reused secrets.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Dynamic infrastructure demands lifecycle control for non-human identities: Kubernetes and Terraform both create fast-moving access relationships that outlive their original intent if they are not actively retired. The same secret may be reused by a cluster, a pipeline, and a provisioning role long after the business reason has changed. That is a lifecycle problem, not just a storage problem, and it belongs in NHI governance and recertification workflows.

Ephemeral credential trust debt: Static secrets remain the default failure mode even when teams add cloud-native encryption controls. The issue is not only that secrets exist, but that organisations continue to rely on long-lived credentials inside automation paths that were built for persistent access. Practitioners need to recognise that the hidden debt is the assumption that a secret remains safe simply because it is encrypted.

Least privilege must be enforced at the execution identity, not just the secret store: Terraform, Kubernetes controllers, and application workloads all operate as non-human identities with distinct access patterns. If those identities can decrypt or retrieve far more secrets than they operationally need, encryption only narrows one exposure channel while leaving overprivilege intact. NHI governance must therefore follow the execution identity through the full access path.

Cross-environment consistency is now the governance problem: The article’s AWS focus is useful, but the real operational issue is consistency across multi-cloud and hybrid estates. Once secrets management spans clusters, pipelines, and multiple clouds, local controls stop being enough. Practitioners should use this pattern as a signal that secrets policy, rotation, and offboarding need a common identity layer, not isolated per-platform settings.

From our research:

• 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.
• For a wider lifecycle view, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows why provisioning, rotation, and offboarding must be governed together.

What this signals

Ephemeral credential trust debt: The practical risk is not that teams encrypt secrets, but that they continue to extend long-lived trust to the identities that consume them. With 23.5% of security professionals unsure about the biggest threat to their non-human identities, per The 2024 Non-Human Identity Security Report, the governance gap is often still invisible to the programme itself.

Kubernetes and Terraform make this visibility problem worse because the same credential can appear in storage, state, orchestration, and runtime policy. The correct response is to align secret lifecycle management with the identity lifecycle of the workloads that depend on it, using the Ultimate Guide to NHIs , Static vs Dynamic Secrets as a baseline for decision-making.

For IAM and PAM teams, the signal is clear: security now depends on whether execution identities can be constrained to narrow, auditable, short-lived access paths. That is a governance change, not just a vaulting change, and it affects cloud operations, infrastructure code, and NHI offboarding together.

For practitioners

• 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.
• Build offboarding into secret lifecycle management When a cluster, pipeline, or automation role is retired, revoke its secret access and verify that no remaining non-human identity can still reach the credential path.

Key takeaways

• AWS secret encryption reduces exposure at rest, but it does not by itself solve who can retrieve or reuse the credential.
• The real control issue is non-human identity governance across Kubernetes, Terraform, and cloud execution paths, where access often outlives the original business need.
• Teams should pair encryption with scoped decrypt rights, lifecycle offboarding, and state-file hygiene if they want to reduce actual blast radius.

Key terms

• Non-Human Identity: A non-human identity is any machine, workload, service account, token, or application identity that authenticates to systems without a person present. In practice, these identities often hold the credentials that move data, trigger deployments, and access cloud resources, so they need lifecycle and access governance of their own.
• Envelope Encryption: Envelope encryption protects a secret by encrypting the secret with a data key and then protecting that data key with a stronger key management service. It reduces storage exposure, but it does not decide who is allowed to request decryption or under what policy conditions.
• Secrets Lifecycle: Secrets lifecycle is the end-to-end management of a credential from creation through use, rotation, and retirement. For non-human identities, lifecycle governance matters because a secret can stay usable long after the original workload, pipeline, or service account should have lost access.
• Execution Identity: An execution identity is the non-human identity that performs a task at runtime, such as a Terraform role, Kubernetes controller, or CI/CD service account. It is the identity that matters when evaluating who can actually retrieve or decrypt a secret in production.

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.

👉 Entro Security's full post includes implementation steps for EKS, Terraform, and AWS Secrets Manager

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.