Secrets encryption on AWS with Kubernetes and Terraform

At a glance

What this is: This is a technical guide on encrypting secrets in AWS when Kubernetes and Terraform are part of the workflow, with the main finding that native encryption helps but does not resolve underlying NHI governance gaps.

Why it matters: It matters because IAM, PAM, and NHI programmes can mistake encrypted storage for control completeness, when the real risk sits in secret lifecycle, access scope, and cross-environment sprawl.

Context

Secrets encryption protects confidential credentials by making them unreadable at rest or in transit, but it does not solve who can create, retrieve, reuse, or retire those credentials across platforms. In AWS environments that combine Kubernetes orchestration and Terraform provisioning, the governance problem is broader than storage because the same secret may be touched by service accounts, CI/CD tools, and application workloads.

The article frames AWS KMS and Secrets Manager as the base layer for this model, while noting that Kubernetes secrets, Terraform variables, and NHI-driven automation add complexity. The practical issue for identity teams is that encryption controls can be technically correct yet still leave lifecycle and access management inconsistent across clusters, accounts, and deployment environments.

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 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. The real security boundary is not the vault alone. It is the full path from creation to rotation to revocation across every consumer.

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. EKS encryption protects secrets in etcd, but it does not remove the need to control who can create, read, mount, or update those secrets. Without that governance layer, the decryption path becomes the real attack surface.

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.

Technical breakdown

How envelope encryption protects AWS secrets

Envelope encryption uses a data key to encrypt the secret value and a separate KMS key to encrypt that data key. Secrets Manager stores the encrypted data key alongside the secret metadata, then calls KMS to decrypt it only when access is authorised. That design reduces plaintext exposure in storage and retrieval paths, but it does not change who can request decryption or how long that access remains valid. In identity terms, the control protects secrecy, not governance.

Practical implication: Treat envelope encryption as a storage safeguard, not as a substitute for credential lifecycle control.

Why Kubernetes secrets need more than base64 encoding

Kubernetes stores secrets in etcd, and base64 encoding is only obfuscation, not protection. When EKS secrets encryption is enabled, the API server uses a KMS key to encrypt new secrets before writing them to etcd and to decrypt them on read. That improves confidentiality at rest, but the access model still depends on API server permissions, cluster configuration, and who can query the secret path. The weak point is not the cipher; it is unmanaged access to the decryption workflow.

Practical implication: Audit who can read, patch, or mount Kubernetes secrets, not just whether encryption is turned on.

Terraform secret retrieval creates an identity dependency chain

Terraform should not hardcode sensitive values in code or state. The article shows a pattern where Terraform reads a secret from Secrets Manager and decodes it for use in resource provisioning, which means the execution identity inherits access to the secret at runtime. That is an NHI pattern, because the secret is consumed by an automated workload rather than a person. The governance challenge is that the secret now depends on the identity of the pipeline, the scope of the IAM policy, and the retention of those credentials over time.

Practical implication: Constrain Terraform execution identities to the exact secrets they need and review those permissions as part of IaC lifecycle governance.

Threat narrative

Attacker objective: The objective is to reuse cloud secrets and automation credentials to expand access across AWS, Kubernetes, and Terraform-controlled resources.

1. Entry occurs when a Kubernetes workload, Terraform runner, or other non-human identity gains access to a stored secret through an approved but overbroad integration path.
2. Credential access then depends on the same runtime identity being able to read from Secrets Manager or decrypt through KMS, which turns configuration scope into the exposure surface.
3. Escalation follows when the retrieved secret can be reused across environments, giving the actor broader access than the original provisioning task required.
4. Impact is unauthorised movement across clusters, cloud resources, or infrastructure states using secrets that were meant to stay compartmentalised.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

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 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.

Secret storage without lifecycle control creates trust debt: In Kubernetes and Terraform environments, the same credential can be consumed by multiple automation paths over time. That makes the real control question one of ownership, rotation, and offboarding rather than storage format. The implication is that teams should treat every persistent secret as accumulated identity debt until its access path is explicitly retired.

Terraform and Kubernetes expose a shared NHI dependency pattern: Infrastructure-as-code and orchestration are both consumers of non-human identities, so their controls must be aligned. A secret that is properly encrypted but broadly retrievable still expands blast radius across environments. The practitioner conclusion is that identity scope, not just encryption state, is the unit of governance.

Multi-environment secret sprawl is the named concept here: When AWS native controls are applied cluster by cluster or pipeline by pipeline, the organisation gets local protection without global accountability. That fragmentation is why the same secret can be secure in one system and overexposed in another. The implication is that central visibility across all NHI secret consumers is what makes the model governable.

OWASP-NHI and Zero Trust assumptions both apply here: Least privilege is only meaningful when the secret consumer is known, bounded, and reviewable. In AWS, Kubernetes, and Terraform workflows, that means every retrieval path must be auditable and every NHI credential must have an explicit owner. The practitioner conclusion is to govern the access path, not just the encrypted payload.

From our research library:

• 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.
• Read next: Ultimate Guide to NHIs

What this signals

Multi-environment secret sprawl: AWS-native encryption controls can protect individual stores while leaving the organisation with fragmented authority over who can retrieve a secret across clusters, pipelines, and accounts. That means the governance problem shifts from ciphertext to consumer visibility, and the programme has to track every non-human identity that can reach a secret path.

In practice, the identity boundary is the point of failure: once a Terraform runner or Kubernetes service account can retrieve a secret, the security question becomes whether that credential is still necessary for the current task. Teams that keep treating secret storage as the end state will keep inheriting access paths they cannot easily offboard.

For practitioners

• 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.
• Harden Terraform execution identities Limit Terraform runners to the minimum Secrets Manager read scope they require and review those permissions whenever infrastructure modules, environments, or pipelines change.
• Reduce Kubernetes secret blast radius Use cluster-level encryption, but also verify who can mount, patch, or query secret objects so that etcd protection is not mistaken for end-to-end control.

Key takeaways

• AWS encryption features improve confidentiality, but they do not by themselves solve who can retrieve or reuse a secret across automation workflows.
• The main exposure comes from NHI consumers such as service accounts, CI/CD jobs, and Terraform runners that retain access longer than the task requires.
• Governance has to focus on secret ownership, retrieval scope, and offboarding, otherwise the same encrypted secret can remain broadly usable.

Key terms

• Secrets At Rest Encryption: Secrets at rest encryption is the practice of protecting stored secret data with encryption inside the cluster datastore or backing storage. It reduces exposure if the underlying store is accessed improperly, but it does not replace access control, because authorised users and workloads can still misuse readable secrets.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Envelope Encryption: A two-layer encryption pattern that uses a short-lived data encryption key to protect the data and a longer-lived key encryption key to wrap that data key. It scales rotation, supports tenant separation, and keeps the primary key material out of direct data handling.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.