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.
At a glance
What this is: This is a guide to modern secrets management for multi-cloud DevOps and Kubernetes, with the central finding that single-environment secrets tools cannot govern static credentials across fragmented cloud and pipeline lifecycles.
Why it matters: It matters because IAM, PAM, and NHI teams have to control machine identities, not just store secrets, when credentials move through cloud, cluster, and CI/CD boundaries.
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.
👉 Read Akeyless's guide to modern secrets management for multi-cloud DevOps and Kubernetes
Context
Modern secrets management is the governance of credentials, API keys, certificates, and tokens across the systems that issue and consume them. In multi-cloud DevOps, the problem is not that secrets exist, but that they persist across clouds, clusters, and pipelines that each apply different lifecycle rules.
The article argues that this creates a governance gap for non-human identities because machine credentials outnumber human users in enterprise environments and are often copied into code, logs, environment variables, and pipeline configs. Once that happens, rotation and revocation become cross-system problems rather than single-tool tasks.
Kubernetes and CI/CD sharpen the issue because they rely on short-lived execution contexts but often inherit long-lived secrets from older operational models. The result is a control environment where access is technically present long after the workload or deployment step that needed it has ended.
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. Teams end up governing the same credential class through multiple policy models, which makes audit evidence inconsistent and offboarding slow. The practical failure is not storage alone, but inability to enforce one lifecycle for every place a secret is consumed.
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. In CI/CD and Kubernetes, that persistence increases blast radius because one exposed secret can unlock multiple workloads, environments, or cloud resources.
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. If the same password or API key can still unlock several services, secret management is not yet reducing blast radius in practice.
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.
Technical breakdown
Why static secrets fail across multi-cloud lifecycles
Static secrets fail in multi-cloud because each platform exposes a different credential lifecycle. AWS, Azure, and GCP do not manage versions, deletion, and policy enforcement in the same way, so a team operating across all three ends up with multiple governance models for the same credential class. That creates fragmentation in auditability, rotation, and ownership. The real failure is not just that secrets exist in too many places, but that each platform’s lifecycle semantics differ enough to make centralized control brittle. Practical implication: design secrets governance around a common lifecycle layer, not per-cloud storage mechanics.
Practical implication: standardize lifecycle policy across clouds before extending secrets storage into more environments.
How Kubernetes and CI/CD turn secrets into a distribution problem
Kubernetes and CI/CD do not only store secrets, they move them. Secrets can land in etcd, pod specs, environment variables, build logs, runner configs, and container layers, which means every handoff creates a new exposure point. Kubernetes Secrets are base64-encoded by default, not encrypted, so the cluster data store becomes part of the trust boundary. CI/CD adds another layer because pipelines often need ephemeral access but are still configured with durable credentials. Practical implication: push credential issuance as close as possible to runtime and keep the secret out of durable build artefacts.
Practical implication: remove secrets from persistent pipeline artefacts and cluster storage wherever runtime injection is possible.
What identity-based authentication changes for machine credentials
Identity-based authentication replaces the idea that workloads should present stored secrets with the idea that they should prove who they are at runtime. In practice, a cloud workload, Kubernetes service account, or CI/CD identity authenticates first, then receives scoped credentials only when needed. That matters because the credential becomes a consequence of verified identity, not the primary proof itself. This is the essential shift from static secret distribution to dynamic access issuance. Practical implication: move authentication upstream so access is minted per workload, per session, or per deployment step.
Practical implication: use workload identity and federation to eliminate standing credentials from routine automation flows.
Threat narrative
Attacker objective: The attacker aims to turn one leaked machine credential into persistent access across cloud, Kubernetes, and delivery systems.
- Entry occurs when a credential is hardcoded into source, a deployment script, a pod spec, or a CI/CD runner configuration and then copied into logs or version history.
- Credential access follows when that stored secret is reused across environments or survives beyond the workload that originally needed it, leaving an attacker a valid authenticator.
- Escalation happens when the same machine identity is trusted across cloud, container, and pipeline boundaries, allowing the credential to open more than one environment.
- Impact comes from lateral movement and persistence through long-lived credentials that outlast the deployment, making containment slower and broader than the original use case.
Breaches seen in the wild
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Multi-cloud turns one credential policy into three or more incompatible execution models. AWS, Azure, and GCP handle secret versioning, deletion, and access differently, which means central governance has to reconcile conflicting lifecycle behaviour. That fragmentation undermines consistent offboarding, rotation, and audit evidence even when teams think they have a single policy. The practical conclusion is that policy consistency matters more than platform count.
Secrets sprawl is really identity blast radius expansion. Every place a secret is copied becomes another potential control failure when the credential is reused, logged, or cached. The blast radius is not limited to the secret itself but extends to the systems and pipelines that trust it. That is why machine identity governance has to focus on issuance scope, expiry, and revocation paths rather than only on storage encryption.
Static secrets are an operational assumption, not a security strategy. They assume credentials can remain valid until a human remembers to rotate them. In distributed DevOps that assumption breaks because the actor that consumes the credential is often a workload, a runner, or a pod whose useful life is much shorter than the secret’s lifetime. The field should treat static credential persistence as a governance debt to be removed, not merely reduced.
Modern secrets management is becoming the control plane for machine identity. The article’s model points toward identity-based authentication, dynamic issuance, and automated expiration as the operating pattern for infrastructure access. That aligns with OWASP-NHI and NIST CSF thinking around access permissions and lifecycle control. Practitioners should reframe secrets platforms as governance systems for non-human identities rather than as password vaults.
From our research library:
- 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.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Identity blast radius is now the more useful lens than secret count. The operational question is no longer how many secrets exist, but how many systems still trust credentials after the workload, pipeline, or deployment step has ended. That makes issuance time and expiry time the governing variables for multi-cloud NHI control.
Secrets lifecycle governance has become a cross-domain IAM problem. DevOps teams need policy alignment across Kubernetes, CI/CD, and cloud providers because each environment can extend credential life in a different way. The more fragmented the storage and retrieval pattern, the harder it is to prove that offboarding and rotation are actually happening.
Runtime issuance will matter more than vault centralization. Centralized storage still helps, but it does not solve secrets that are copied into persistent artefacts or reused by workloads after their intended window. The stronger control objective is to reduce the time a credential exists and the number of places it can be replayed.
For practitioners
- 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.
- Automate rotation and revocation for machine identities Set short expiry for database, API, SSH, and cloud credentials, then tie revocation to workload termination, pipeline completion, or access policy changes rather than manual change windows.
Key takeaways
- Multi-cloud DevOps exposes a governance gap because secrets can outlive the workloads, pipelines, and clusters that first needed them.
- The strongest evidence in the article is that leaked credentials remain active long after exposure, which turns rotation and revocation into lifecycle problems.
- Teams need dynamic issuance, tighter runtime controls, and clearer offboarding for machine identities if they want secrets governance to scale.
Key terms
- Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- 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.
- Identity-Based Authentication: Identity-based authentication verifies a specific person or subject rather than a pooled credential. In shared environments, it preserves accountability by keeping access tied to the individual even when the resource, workstation, or application is used by many people.
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
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.
Published by the NHIMG editorial team on September 6, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org