Notifications
Clear all
Topic starter
12/06/2026 12:57 am
TL;DR: Access lifecycle tooling still has to prove whether it is governing people, service-like access, or machine-issued credentials with the same discipline, according to Zluri. Zluri’s GitLab Self Managed integration focuses on automating user onboarding, offboarding, role updates, usage visibility, and license allocation across GitLab environments.
NHIMG editorial — based on content published by Zluri: Automation How Zluri Helps You Get More Out Of GitLab (Self Managed)
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams govern GitLab access lifecycle automation?
A: Security teams should govern GitLab automation by tying every add, change, and remove action to a verified source of truth and a completion check.
Q: Why does GitLab offboarding still create identity risk after automation?
A: GitLab offboarding still creates risk because access can survive in multiple scopes even after the user is deactivated.
Q: What do IAM teams get wrong about GitLab license optimisation?
A: IAM teams often treat license cleanup as separate from access governance, but inactive users can still hold meaningful permissions.
Practitioner guidance
- Map GitLab access to all entitlement scopes Inventory user, group, project, admin, and feature flag permissions so that every lifecycle event is evaluated across the full access surface, not just the account record.
- Verify offboarding removes residual access everywhere Require a post-offboarding check that confirms no permissions remain in groups, projects, or feature flag lists after the user is deactivated or removed.
- Govern personal access tokens as secrets Track token owner, scope, and expiry, and assign a revocation owner so the token lifecycle is reviewed with the same discipline as any other sensitive credential.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step GitLab setup guidance for personal access tokens and required scopes.
- Exact onboarding, mid-lifecycle, and offboarding actions available through the integration.
- Usage tracking and license allocation examples tied to active user behaviour.
- A practical walkthrough for connecting GitLab Self Managed to Zluri.
👉 Read Zluri's guide to GitLab access automation and lifecycle controls →
GitLab user access automation: what IAM teams need to know?
Explore further
12/06/2026 10:31 am
GitLab lifecycle automation is only as strong as the identity state it can actually prove. Automating add, update, and remove actions reduces manual effort, but it does not solve the underlying governance problem if access lives in multiple scopes and systems. The control issue is not whether a task can be triggered automatically, but whether identity and entitlement state stay synchronised across the whole lifecycle. Practitioners should treat automation as an execution layer, not as evidence of governance.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when GitLab access is not fully revoked?
A: Accountability should sit with the team that owns lifecycle governance for the application and the identity source of record. If access is not fully revoked, the failure usually spans IAM operations, application owners, and security governance. Frameworks such as the NIST Cybersecurity Framework 2.0 support that shared responsibility model.
👉 Read our full editorial: GitLab access lifecycle automation reveals the NHI governance gap
