Notifications
Clear all
Topic starter
25/06/2026 10:40 pm
TL;DR: Connecting CI/CD pipelines to the GitLab REST API with short-lived OAuth 2.0 tokens can replace hardcoded credentials and narrow access scope for machine workflows, according to Aembit. The underlying governance issue is bigger than token format: pipeline identity still needs lifecycle control, scoped authorization, and revocation discipline.
NHIMG editorial — based on content published by Aembit: Aembit Server Workload Cookbooks Series | GitLab
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams secure GitLab access from CI/CD pipelines?
A: Security teams should assign each pipeline a distinct workload identity, issue short-lived credentials at runtime, and scope those credentials to the exact GitLab actions required.
Q: Why do hardcoded credentials in CI/CD pipelines create so much risk?
A: Hardcoded credentials create standing access that outlives the job, the team, and sometimes the project itself.
Q: What breaks when pipeline credentials are not tied to lifecycle controls?
A: What breaks is accountability.
Practitioner guidance
- Inventory pipeline identities and their API scopes Map every CI/CD workflow that reaches GitLab or other external systems, then record the identity, owner, scope, and expiry for each one.
- Replace long-lived secrets with runtime-issued tokens Use short-lived OAuth 2.0 tokens or equivalent workload credentials so that access is minted only when the job runs.
- Add offboarding to pipeline lifecycle management When a project ends, a runner is retired, or a team changes ownership, revoke the pipeline's credentials and remove the trust path immediately.
What's in the full article
Aembit's full resource covers the operational detail this post intentionally leaves for the source:
- Step-by-step implementation patterns for connecting CI/CD pipelines to the GitLab REST API with short-lived OAuth 2.0 tokens.
- Reusable cookbook guidance for replacing hardcoded credentials with identity-based access in build workflows.
- Implementation notes that help teams adapt the pattern to their own runners, repositories, and automation boundaries.
- Clear examples aimed at practitioners who are ready to move from governance intent to configuration.
👉 Read Aembit's guide to secure CI/CD access to the GitLab REST API →
GitLab API access from CI/CD pipelines: are your controls ready?
Explore further
25/06/2026 11:19 pm
CI/CD pipelines are workload identities, not temporary implementation artefacts. Once a pipeline can call GitLab, it is exercising a persistent identity relationship even if the job itself is short-lived. That means the same governance questions used for service accounts apply here: who owns the identity, what it may access, and how it is revoked when the workflow changes. Practitioners should treat pipeline access as part of identity inventory, not build tooling.
A few things that frame the scale:
- From our research: 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: How do teams know if CI/CD secret controls are actually working?
A: They should be able to answer three questions quickly: where every pipeline secret exists, who owns the identity behind it, and how fast it is revoked when a workflow changes. If a team cannot produce those answers, the control is mostly inventory, not governance. Effective controls leave a clear issue, expiry, and offboarding trail.
👉 Read our full editorial: CI/CD pipeline access to GitLab needs short-lived tokens
