Topic starter
30/09/2026 7:10 pm
TL;DR: A GitLab CI/CD pipeline using a GCP service account starts read-only, fails on write, then succeeds after a five-minute just-in-time elevation, illustrating how standing permissions turn routine builds into privilege escalation opportunities, according to P0 Security. The real issue is not pipeline automation itself, but persistent machine access that should expire with the task.
NHIMG editorial: based on content published by P0 Security: a video demo of just-in-time elevation for machine identity permissions in GitLab pipelines
Questions worth separating out
Q: What breaks when CI/CD service accounts do not use just-in-time access?
A: Standing access turns build automation into a persistent privilege path.
Q: Why do standing permissions in GitLab pipelines increase security risk?
A: Because the identity can act outside the specific build step that needed access.
Q: How do you know if just-in-time elevation is actually working?
A: JIT is working only when privilege is time-bound, task-scoped, and revoked at the end of the session without relying on a later scheduled rotation.
Practitioner guidance
- Define pipeline-specific baseline roles Start every GitLab service account with the smallest role that allows the build to begin, then separate read, compute, and write steps so only the write step can request elevation.
- Use time-bound elevation for write actions Grant temporary permissions only for the exact build step that needs them, and set the expiry so the identity returns to its original state automatically.
- Record approvals and expiry events Keep an auditable trail for every privilege change, including who approved it, what scope was granted, and when the access window closed.
What's in the full article
P0 Security's full video covers the operational detail this post intentionally leaves for the source:
- The exact GitLab pipeline sequence used to demonstrate read-only access, failed write access, and temporary elevation
- The approval flow for granting five minutes of elevated storage.objectCreator access to the service account
- The automatic permission reversion that returns the identity to storage.objectViewer after the time window expires
- The live rerun of the build after elevation, showing how the write step succeeds only inside the approved window
👉 Read P0 Security's demo on just-in-time elevation for GitLab service accounts →
GitLab service accounts and just-in-time access: what changes for teams?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
30/09/2026 7:11 pm
Standing access is the core governance failure in CI/CD machine identity programmes. The article makes clear that the risky condition is not pipeline automation itself, but service accounts that retain broad permissions after the build step ends. Once a GitLab pipeline can write to cloud storage whenever it runs, the identity has become a standing operator rather than a task-scoped actor. Practitioners should treat persistent elevation as a lifecycle defect, not a convenience choice.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What is the difference between just-in-time access and standing privilege for NHIs?
A: Just-in-time access grants permissions only when a task requires them and removes them afterward, while standing privilege leaves access in place continuously. For NHIs, the difference is critical because ephemeral access only reduces risk if revocation and monitoring are automatic.
👉 Read our full editorial: Just-in-time elevation for GitLab service accounts reduces CI/CD risk
