Topic starter
08/07/2026 6:57 pm
TL;DR: AWS Secrets Manager improves storage, rotation, and auditability for database credentials, API keys, and tokens, according to Infisical, but native convenience does not solve plaintext state exposure, multi-environment sprawl, or the need for tightly scoped IAM and lifecycle discipline. Centralised secrets management helps, yet governance still has to extend beyond the AWS boundary.
Editorial analysis by NHI Mgmt Group, based on content published by Infisical: “AWS Secrets Manager: Complete Guide, Best Practices, and Tips”.
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 native secrets stores still leave governance gaps for IAM teams?
A: Because the vault is only one control point.
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.
Practitioner guidance
- 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.
Bottom line: Secrets management reduces the chance of hardcoded credentials, but it does not eliminate the governance failures that create duplicate copies and uncontrolled access paths.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
08/07/2026 7:20 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AWS Secrets Manager and the limits of native secrets governance