Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

DevOps PAM and ephemeral access: are your controls keeping up?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 12212
Topic starter  

TL;DR: DevOps pipelines increase the spread of API keys, tokens, and admin credentials, and static PAM models often struggle to keep pace with cloud-native delivery, according to SSH Communications Security. The real issue is not speed alone but whether access can be governed, audited, and removed fast enough to avoid standing privilege and credential sprawl.

NHIMG editorial — based on content published by SSH Communications Security: DevOps is often the engine that drives rapid market growth and innovation in an enterprise

Questions worth separating out

Q: How should security teams govern privileged access in DevOps pipelines?

A: Security teams should treat DevOps privileged access as a lifecycle problem, not a one-time approval problem.

Q: Why do static credentials create more risk in DevOps environments?

A: Static credentials are dangerous in DevOps because they spread across code, build systems, containers, and cloud services faster than teams can review them.

Q: What do teams get wrong about just-in-time access for DevOps?

A: Teams often assume just-in-time access is only a convenience feature, when it is actually the core model for replacing standing privilege in ephemeral workflows.

Practitioner guidance

  • Inventory all privileged secrets in delivery paths Map API keys, tokens, admin accounts, and cloud roles across CI/CD, containers, and IaC so you can see where standing privilege still exists.
  • Replace persistent access with task-scoped grants Use just-in-time approvals and short-lived credentials for deployment, troubleshooting, and production support, then revoke access automatically when the task ends.
  • Integrate PAM into the tooling developers already use Connect controls to Kubernetes, Jenkins, GitLab, GitHub Actions, Azure DevOps, and cloud IAM so teams do not bypass security for speed.

What's in the full article

SSH Communications Security's full article covers the operational detail this post intentionally leaves for the source:

  • Implementation guidance for secrets management across DevOps toolchains and cloud-native environments
  • Specific ways to use just-in-time and ephemeral access in CI/CD and production support workflows
  • Examples of automation-first PAM features for provisioning, rotation, and de-provisioning
  • Customer case detail on securing privileged access for DevOps pipelines and configuration management

👉 Read SSH Communications Security's analysis of DevOps PAM requirements →

DevOps PAM and ephemeral access: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 11787
 

DevOps PAM fails when it is treated as a vault instead of a governance layer. The article describes a world where credentials are created, consumed, and discarded across pipelines, cloud services, and developer workflows. That is not a storage problem alone. The governance requirement is visibility into where privileged access lives, how it is issued, and when it disappears, because static credential handling cannot keep pace with delivery velocity. Practitioners should treat this as a lifecycle and control-design problem, not a tooling feature checklist.

A few things that frame the scale:

A question worth separating out:

Q: How can organisations tell whether DevOps PAM is actually working?

A: A working DevOps PAM programme should show fewer long-lived secrets, fewer manual access exceptions, and a complete audit trail for who or what used a privileged credential. If access still persists after deployment tasks are done, the control model is not keeping pace with the environment.

👉 Read our full editorial: DevOps PAM for ephemeral access and secrets governance



   
ReplyQuote
Share: