AWS Secrets Manager and the limits of native secrets governance

At a glance

What this is: Infisical’s guide explains how AWS Secrets Manager works and why its native controls still leave governance gaps around scope, rotation, cost, and multi-cloud coverage.

Why it matters: IAM, PAM, and NHI teams need to see where a cloud-native secrets store ends and broader governance begins, especially when secrets live across Terraform state, CI/CD, and non-AWS environments.

Context

AWS Secrets Manager is a managed secrets service, but it does not erase the governance problems that create secret sprawl in the first place. The article frames the core issue as control scope: storing and retrieving credentials centrally is useful, yet plaintext state, ad hoc access paths, and cloud boundary fragmentation can still expose sensitive material.

For identity teams, the practical question is not whether a secrets vault exists, but whether the surrounding IAM, lifecycle, and automation controls actually prevent credentials from escaping into code, Terraform state, shell history, or parallel stores. That is why secrets governance remains a programme problem, not just a storage decision.

The guide is strongest where it shows AWS-native convenience versus cross-environment operational reality. Secrets Manager is well suited to AWS-centric workflows, but the article makes clear that many teams still need policy, rotation, and audit discipline that reaches beyond a single managed service.

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 native secrets stores still leave governance gaps for IAM teams?

A: Because the vault is only one control point. Teams also have to govern where secrets are copied, how they are referenced in automation, how tightly IAM is scoped, and whether rotation can complete without breaking the workload. Central storage helps, but lifecycle control is what closes the gap.

Q: What breaks when secrets are stored in code and CI/CD tools?

A: Access becomes invisible, reusable, and hard to revoke, which means the organisation loses control of where authentication material exists. Once secrets are embedded in code or pipeline tools, discovery gets harder, offboarding slows down, and the same credential can survive multiple deployment cycles.

Q: What is the difference between storing secrets securely and governing them well?

A: Secure storage protects where the secret sits. Governance adds ownership, exposure history, lifecycle state, and dependency awareness so teams can decide when a secret should be rotated, revoked, or retired. In practice, the second problem is harder and more important, because it determines whether the secret is still usable by an attacker.

Technical breakdown

How AWS Secrets Manager handles encryption, access, and versioning

AWS Secrets Manager is not a simple password vault. It encrypts each secret at rest with AWS KMS, controls retrieval through IAM and resource policies, and tracks secret versions with staging labels such as AWSCURRENT, AWSPENDING, and AWSPREVIOUS. That version model matters because rotation is not a blind overwrite. Applications continue reading the current label while the new value is tested, which reduces downtime but still depends on correct policy scope and downstream compatibility. The technical takeaway is that the service is a controlled retrieval system, not a substitute for broader identity governance.

Practical implication: treat secret version labels and IAM scope as governance controls, not just implementation details.

Why Terraform state creates a hidden secret exposure path

Terraform can manage Secrets Manager resources, but the article correctly warns that Terraform state stores values in plaintext. That means the secret may be secure in AWS and still exposed in state backends, plans, and generated outputs if teams pass values directly through configuration. In practice, the security boundary shifts from the vault to the IaC workflow, which is why state must be treated as sensitive infrastructure data. This is a classic example of a governance failure outside the secret store itself: the platform is centralised, but the lifecycle of the credential is not.

Practical implication: keep secret material out of Terraform state wherever possible and govern state storage as sensitive infrastructure.

Why rotation helps, but only when the downstream system can absorb it

Secrets Manager rotation works by invoking a Lambda workflow that creates a new value, applies it, tests it, and then promotes it to AWSCURRENT. That makes rotation operationally safer than manual password changes, but it does not eliminate application fragility. Single-user rotation can interrupt in-flight sessions, while alternating-users rotation avoids that by switching between two identities. The deeper point is that rotation design and application behaviour are linked: if the workload cannot tolerate credential replacement, rotation becomes a change-management problem as much as a secrets problem.

Practical implication: align rotation strategy with application reconnect behaviour before turning it on broadly.

Threat narrative

Attacker objective: The attacker’s objective is to obtain reusable credentials that unlock cloud resources, application data, or deployment paths beyond the original secret’s intended scope.

1. Entry occurs when secrets are copied into code, configuration files, shell history, or Terraform state instead of remaining inside governed storage.
2. Credential access follows when those plaintext or replicated values are retrieved from places that were never meant to function as secret stores.
3. Escalation occurs when broad IAM scope, environment duplication, or shared naming patterns let the same credential reach more services than intended.
4. Impact is the exposure of database access, API access, or operational control across AWS and adjacent environments.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
• 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 and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secret governance fails when teams confuse central storage with central control: A managed vault does not solve the fact that credentials still leak into state files, build systems, and local workflows. The article shows that the real control problem is not where the secret is stored, but whether every copy, reference, and retrieval path is governed. For practitioners, this means the secrets programme has to cover the full lifecycle, not just the vault.

Plaintext Terraform state is a separate identity risk surface: Infrastructure as code often becomes the place where secret governance quietly breaks down. If a password enters state, the vault is no longer the only system that matters because the deployment pipeline has become a credential repository in its own right. The implication is that NHI governance must extend to IaC state handling as a first-class control boundary.

Rotation is only as strong as the application’s ability to survive it: Automatic rotation reduces exposure windows, but it also creates an operational dependency on reconnect logic, version labels, and downstream testing. That makes rotation less a checkbox and more a coordination discipline between identity, platform, and application owners. Teams should measure whether rotation changes behaviour safely, not just whether it runs.

AWS-native secrets management is a local optimisation, not a universal governance model: The article makes clear that AWS Secrets Manager works best inside a single cloud boundary, while many modern estates span multiple clouds, on-premises systems, and SaaS integrations. That is why the category is moving toward governance layers that can unify policy, audit, and lifecycle across environments. The practitioner conclusion is to design for portability in the control plane, even if the workload remains cloud-specific.

Secret sprawl is now a lifecycle problem, not a storage problem: The named concept here is secret sprawl, but the deeper issue is that secrets now move through code, pipelines, automation, and runtime access patterns. A secrets manager reduces sprawl only if the surrounding lifecycle is controlled. For practitioners, the test is whether a secret can be created, used, rotated, and retired without reappearing elsewhere in the estate.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 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.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Secret sprawl is the real control problem: When credentials live in code, config files, CI/CD systems, and Terraform state, the vault only solves part of the lifecycle. The rest of the programme has to govern every copy, reference, and retrieval path, or the organisation simply relocates exposure rather than removing it, according to the Ultimate Guide to NHIs.

Runtime retrieval changes the governance boundary: AWS-native secret access is useful when the workload stays inside one cloud boundary, but multi-cloud estates force teams to think about policy consistency, offboarding, and auditability across multiple stores. That is why secrets management needs to be treated as a cross-environment identity control, not a single-service feature.

For practitioners

• Scope IAM to specific secret ARNs Grant GetSecretValue only on the exact secret paths a workload needs, and avoid wildcard access that turns a single secret into a broad retrieval surface.
• Keep credential values out of Terraform state Use sensitive variables, generated credentials, or a separate write step so passwords do not land in state files, plans, or outputs.
• Choose rotation patterns that match application behaviour Use single-user rotation only where short reconnect failures are acceptable, and use alternating-users rotation where service continuity matters.
• Treat secret scanning as a backstop control Scan repositories, build logs, and related automation for leaked credentials because a managed vault does not remove every exposed copy.
• Standardise naming and ownership for secret paths Adopt a clear hierarchy such as environment, service, and purpose so policies, audits, and offboarding can follow the same pattern across the estate.

Key takeaways

• Secrets management reduces the chance of hardcoded credentials, but it does not eliminate the governance failures that create duplicate copies and uncontrolled access paths.
• The article’s own examples show that Terraform state, CLI history, and CI/CD workflows can all become secret exposure points if teams do not control where values land.
• The right response is to govern the full credential lifecycle with tight IAM scope, rotation discipline, and scanning for stray copies outside the vault.

Key terms

• Secret Manager: A secret manager is a control that stores and sometimes rotates credentials such as tokens, keys, and certificates. It reduces exposure of sensitive material, but it does not by itself establish ownership, entitlement context, or revocation accountability, which means governance can still fail even when storage is secure.
• Terraform State: Terraform state is the record that links declared infrastructure code to the live resources actually running in the cloud. It is the mechanism that makes reconciliation, drift detection, and controlled change possible, and it becomes critical when existing resources are imported rather than recreated.
• 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.
• Alternating-Users Rotation: Alternating-users rotation is a credential rotation pattern that uses two accounts so one can stay live while the other is changed in the background. It reduces service disruption, but it still requires accurate downstream configuration and careful control over which account is active.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.