Topic starter
06/09/2026 6:20 pm
TL;DR: Akeyless argues that legacy secrets tools break down once workloads span multiple clouds, Kubernetes, and CI/CD pipelines, leaving static credentials fragmented across separate lifecycle models and widening exposure windows. The governance problem is no longer storage, but whether machine identities can be issued, scoped, rotated, and revoked fast enough to match distributed delivery.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “Secrets Management in Multi-Cloud DevOps: 2026 Guide”.
By the numbers:
- 23.8 million new credentials leaked on public GitHub in 2024, with 70 percent of leaked secrets still active two years later.
- 35 percent of private repositories scanned contained at least one plaintext secret, and AWS IAM keys appeared in plaintext in 8 percent of private repositories.
Key questions
Q: What breaks when secrets management is stretched across multiple clouds and Kubernetes clusters?
A: Fragmentation breaks visibility, rotation, and revocation because each cloud and orchestration layer applies different secret lifecycles.
Q: Why do static credentials create more risk in CI/CD and Kubernetes environments?
A: Static credentials are copied into many places, reused by many systems, and difficult to revoke cleanly once they spread.
Q: How can security teams tell whether secret management is actually working?
A: Look for fewer plaintext secrets, narrower reuse, faster rotation, and a shrinking set of credentials that remain valid across multiple systems.
Practitioner guidance
- Standardize credential lifecycle across clouds Map AWS, Azure, and GCP secret handling into one policy model for issuance, versioning, rotation, and revocation so that platform differences do not create uneven control coverage.
- Remove durable secrets from CI/CD flows Replace stored keys in runners, scripts, and build variables with runtime retrieval through federation or dynamic issuance, then block hardcoded credentials from reaching the repository or build logs.
- Inject Kubernetes secrets at runtime Use external secret injection for pods and keep credentials out of etcd, environment variables, and image layers, while limiting service account access to only the secrets each workload needs.
Bottom line: Multi-cloud DevOps exposes a governance gap because secrets can outlive the workloads, pipelines, and clusters that first needed them.
What's in the full article
Akeyless's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step Kubernetes secrets injection guidance using external managers and admission control
- CI/CD implementation details for OIDC federation, runtime secret retrieval, and hardcoded secret scanning
- Multi-vault governance methods for standardising policy across existing secret stores without immediate migration
- Compliance-oriented controls for immutable audit trails, rotation evidence, and FIPS-validated encryption
👉 Read Akeyless's guide to modern secrets management for multi-cloud DevOps and Kubernetes →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/09/2026 6:21 pm
Secrets governance now fails at the lifecycle boundary, not the vault boundary. The core issue in multi-cloud DevOps is that credentials live longer and travel farther than the workflows that use them. Once secrets are copied into code, CI/CD tools, containers, and cluster storage, the problem becomes lifecycle control across environments rather than storage in one place. Practitioners should treat secrets management as an identity lifecycle discipline, not a repository problem.
A few things that frame the scale:
- 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to the 2024 State of Secrets Management Survey.
- Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to the State of Secrets in AppSec.
A question worth separating out:
Q: Should organisations choose dynamic credentials over static secrets everywhere?
A: Not everywhere. Dynamic credentials are the better default where applications and platforms can handle short-lived issuance and renewal, but some legacy systems still require static secrets. The right decision is to prioritise dynamic access for high-risk paths first, then reduce static exceptions through migration and tighter ownership.
👉 Read our full editorial: Modern secrets management for multi-cloud DevOps and Kubernetes