Notifications
Clear all
Topic starter
06/09/2026 6:20 pm
TL;DR: Legacy secrets tools were built for single-environment deployments, but multi-cloud, Kubernetes, and CI/CD sprawl now force separate lifecycles and fragmented governance, according to Akeyless. The core problem is not storage volume alone but the persistence of static credentials and the lack of lifecycle control across machine identities.
NHIMG editorial — based on content published by Akeyless: Modern Secrets Management in Multi-Cloud DevOps
By the numbers:
- 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as very concerned.
- Only 44% of organisations are currently using a dedicated secrets management system.
Questions worth separating out
Q: What breaks when static secrets are used in cloud-native environments?
A: Static secrets break down when the same credential is reused across many services, repositories and pipelines.
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.
Q: How do security teams know if workflow secret handling is actually working?
A: Look for three signals: fewer long-lived secrets in workflows, strong inventory of which jobs can access which credentials, and successful use of short-lived federated auth for cloud access.
Practitioner guidance
- Replace persistent pipeline credentials with federated workload identity Use OIDC federation or native cloud identity to let pipelines authenticate without storing long-lived access keys in runners, scripts, or variables.
- Move high-value secrets to dynamic issuance Issue credentials at runtime for specific jobs, pods, or database sessions and let them expire automatically after the task completes.
- Separate Kubernetes and CI/CD control paths Apply different controls to etcd exposure, pod mount permissions, build logs, and runner storage so one leak path does not imply all-path compromise.
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 secret injection patterns using external managers and admission control.
- CI/CD implementation guidance for OIDC federation, runtime secret retrieval, and pre-commit scanning.
- Multi-vault governance detail for teams that need to unify legacy stores without immediate migration.
- Compliance-oriented controls for regulated environments, including audit trail and rotation practices.
👉 Read Akeyless's guide to modern secrets management in multi-cloud DevOps →
Secrets sprawl in multi-cloud DevOps: what IAM teams need now?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
06/09/2026 6:21 pm
Static secret persistence is the control failure that matters most here. The article repeatedly shows that credentials outlive the workflow that created them, whether they are buried in logs, copied into scripts, or stored in cluster data. That is not a detection problem first, it is a lifecycle problem in which the exposure window remains open long after the intended transaction ends. Practitioners should treat persistence, not volume, as the primary risk variable.
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.
- Only 44% of organisations are currently using a dedicated secrets management system, which shows how many teams are still relying on fragmented controls.
A question worth separating out:
Q: What is the difference between vaulting secrets and governing them?
A: Vaulting is storage control. Governing secrets means knowing where they move, who owns them, when they expire, and whether they are still justified. A secret can be safely stored and still be operationally unsafe if it is copied into chat tools, duplicated in files, or left active after offboarding.
👉 Read our full editorial: Modern secrets management for multi-cloud DevOps and Kubernetes
