Modern secrets management for multi-cloud DevOps and Kubernetes

At a glance

What this is: This guide argues that legacy secrets tooling breaks down when credentials must be governed across multi-cloud, Kubernetes, and CI/CD pipelines, because static secrets and fragmented lifecycles outpace operational controls.

Why it matters: It matters because IAM, PAM, and NHI teams need one governance model for workload identities, ephemeral credentials, and revocation, or secrets sprawl will keep expanding blast radius and audit exposure.

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.

👉 Read Akeyless's guide to modern secrets management in multi-cloud DevOps

Context

Secrets management is the discipline of issuing, scoping, rotating, and revoking credentials, tokens, API keys, and certificates so workloads can authenticate without creating permanent exposure. In multi-cloud DevOps, that discipline breaks down when every cloud, cluster, and pipeline applies different identity, policy, and audit models to the same credential lifecycle.

The primary IAM problem is not whether secrets exist, but whether they can be governed consistently across workload identity, CI/CD automation, and Kubernetes runtime access. Once credentials are copied into build logs, environment variables, image layers, or cluster stores, the organisation inherits a long-lived exposure problem that conventional single-system controls do not absorb well.

This is a typical failure pattern for teams that expanded from one cloud and one secrets store into distributed delivery pipelines without redesigning identity governance for machine identities.

Key questions

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. The result is secret sprawl, weak attribution and a wide blast radius if one value is exposed. Cloud-native teams then spend more time rotating and tracking credentials than governing access, which is a structural identity problem, not just a hygiene issue.

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. If secrets still appear in runner logs, environment variables, or ungoverned third-party actions, the control is not working as intended.

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.

Technical breakdown

Why single-environment secrets models fail in multi-cloud

Single-environment secrets systems assume one policy model, one audit format, and one operational team. Multi-cloud and hybrid estates break that assumption because AWS, Azure, and GCP each handle versions, deletion, and access differently, while Kubernetes adds another layer of runtime distribution. The result is not just more secrets, but more lifecycle states to reconcile. When governance is fragmented, security teams lose a reliable view of where credentials exist, which identities use them, and whether rotation actually happened.

Practical implication: map every secrets store and cloud-native manager to one governance model before adding more environments.

How dynamic secrets and identity-based authentication change the control plane

Dynamic secrets replace persistent credentials with short-lived values issued on demand for a specific workload or session. Identity-based authentication shifts the trust anchor from the secret itself to the workload identity presenting the request, such as a cloud identity, Kubernetes service account, or OIDC-federated pipeline. That changes the control plane materially because the secret is no longer the primary proof of trust. Instead, the authorisation decision is tied to runtime identity, scope, and expiry, which reduces the usefulness of any single leaked credential.

Practical implication: move high-frequency workloads to ephemeral, identity-bound access and reserve static secrets only where no alternative exists.

Kubernetes and CI/CD leak secrets differently, but they fail the same way

Kubernetes usually fails at runtime exposure, where secrets are mounted, stored in etcd, or granted through overly broad RBAC. CI/CD usually fails earlier, when credentials are embedded in scripts, environment variables, logs, or runner configurations. These are different delivery channels, but the same governance failure appears in both: long-lived secrets are allowed to travel further than their intended use. OIDC federation, external secrets injection, and admission control reduce that travel window by removing the stored credential from the pipeline.

Practical implication: treat Kubernetes and CI/CD as separate leak paths and apply different controls to each path.

Threat narrative

Attacker objective: The attacker aims to turn one exposed workload credential into broad, persistent access across distributed build and runtime environments.

1. Entry occurs when a credential is hardcoded into a pipeline, copied into a log, or stored in a cluster data store that was never meant to be a durable secret repository.
2. Escalation follows when that standing credential is reused across environments, giving an attacker broader access than the original workflow required.
3. Impact comes from lateral movement through connected clouds, registries, databases, and deployment systems before the secret is rotated or revoked.

Breaches seen in the wild

• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Multi-cloud secrets governance is really identity governance for machine actors. Once a workload spans AWS, Azure, GCP, and Kubernetes, no single platform-native secrets manager can represent the full lifecycle cleanly. The organisation must govern how workload identities authenticate, how secrets are issued, and how revocation is enforced across boundaries. The practical conclusion is that secrets programmes need cross-platform lifecycle ownership, not just tool deployment.

Dynamic credentials are a better fit than static vaulting for high-churn delivery systems. The guide’s strongest point is that ephemeral credentials reduce the value of leakage because the secret dies with the task. That aligns with OWASP Non-Human Identity Top 10 thinking and with NIST CSF controls on access governance. Practitioners should stop treating rotation as a maintenance activity and start treating expiry as the default state.

Secrets sprawl is now a blast-radius problem, not merely an inventory problem. When every pod, runner, and automation job can hold credentials, the security question becomes how far one compromised identity can reach before revocation catches up. The named concept here is identity blast radius: the reach of a single workload credential across clouds, pipelines, and dependent systems. Teams should measure and reduce that radius, not just count secrets.

Regulated environments need evidence across the lifecycle, not point-in-time encryption claims. Audit readiness depends on proving least privilege, rotation, immutable logging, and consistent policy enforcement across heterogeneous stores. A platform that cannot show the full credential journey will struggle under SOC 2, ISO 27001, PCI DSS, or GDPR scrutiny. The governance takeaway is that lifecycle evidence is the control, not a reporting afterthought.

From our research:

• 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.
• Start with NHI Lifecycle Management Guide if your programme needs a practical model for issuance, rotation, and revocation.

What this signals

Identity blast radius: the real programme risk is not how many secrets exist, but how many environments one leaked credential can reach before revocation closes the window. That shifts planning away from storage-centric design and toward lifecycle controls that reduce reach across pipelines, pods, and cloud accounts.

With 88% of security professionals already concerned about secrets sprawl, the governance gap is no longer hypothetical. Teams should expect pressure to prove runtime issuance, short-lived access, and cross-platform auditability in the same control narrative, especially where regulated workloads depend on machine identities.

The operational signal is simple: if your environment still needs separate ways to manage secrets in AWS, Azure, GCP, and Kubernetes, the programme has not yet converged on a real NHI control plane. The next step is to standardise lifecycle evidence, not just centralise storage.

For practitioners

• 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.
• Centralise lifecycle visibility across cloud-native stores Build one inventory of secrets, certificates, and machine identities across AWS, Azure, GCP, Kubernetes, and any legacy vaults before expanding further.
• Prove rotation and revocation with audit evidence Retain immutable records showing when credentials were issued, where they were used, and when they were rotated or revoked across every environment.

Key takeaways

• Legacy secrets tools fail when multi-cloud and Kubernetes growth turns one credential lifecycle into many incompatible ones.
• The most dangerous secret is often the one that remains valid after the workflow that created it has already ended.
• Identity-based authentication, dynamic issuance, and auditable revocation are the controls that change the risk equation.

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.
• 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.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.

👉 The full Akeyless guide covers Kubernetes controls, CI/CD patterns, and compliance considerations in more implementation detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.