Efficient Offboarding of Users in GitLab

Introduction

When people leave an organization, it can be challenging both operationally and personally. Their absence is felt, and navigating these transitions requires both sensitivity and a solid strategy to keep things on track.

Offboarding users from GitLab is a crucial step to ensure security and continuity within an organization. It’s important to handle this process carefully to protect sensitive information while keeping operations running smoothly. This article explores the challenges of offboarding and outlines an effective approach to manage it.

Key Considerations in GitLab User Offboarding

1. User Tokens

• Personal Access Tokens (PATs) are revoked when a user is blocked
• Potential issues if PATs are used in critical systems or workflows
• Need to identify and address dependencies on personal tokens before offboarding

2. Scheduled Pipelines

• Scheduled Pipelines (SP) are bound to individual users
• Blocking a user disables their associated Scheduled Pipelines
• Requires ownership transfer to an active user to maintain pipeline functionality

Automated Offboarding Process

To address these challenges, we’ve implemented an automated offboarding process that includes safety checks and escalation procedures. Here’s an overview of the process:

1. Initiation: IT department triggers the offboarding process via an API call to a Lambda function.
2. Initial Validation: The Lambda function performs basic checks, such as verifying the user’s email domain.
3. Jenkins Job Activation: A Jenkins job is triggered to perform more detailed checks:
   a. Check for active tokens used within the last 14 days
   b. Identify any Scheduled Pipelines associated with the user
4. Decision Making:
   • If any checks return true (active tokens or SPs exist), a Jira support ticket is created for the DevOps team.
   • The DevOps team collaborates with the user’s manager to address any potential issues.
   • If no issues are found, the process proceeds to block the user.
5. User Blocking: An API call is made to GitLab to block the user if all checks pass.

Visual Representation of the Offboarding Process

The following flowchart illustrates the step-by-step process of our automated GitLab user offboarding system:

This diagram outlines the key decision points and actions taken during the offboarding process, from initial triggering by IT to the final blocking of the user in GitLab. It highlights the automated checks, escalation procedures, and the role of the DevOps team in resolving any issues that arise.

Jenkins Process Flowchart

To better visualize the workflow implemented in our Jenkins file, we’ve created the following flowchart. This diagram illustrates the main steps of the GitLab user offboarding process, including user verification, checks for scheduled pipelines and tokens, and the decision-making process for either creating a Jira ticket or blocking the user.

Benefits of This Approach

1. Risk Mitigation: Prevents accidental disruption of critical systems relying on personal tokens or scheduled pipelines.
2. Automated Checks: Reduces manual effort and the likelihood of human error in the offboarding process.
3. Escalation Procedure: Ensures that potential issues are reviewed by appropriate stakeholders before taking action.
4. Compliance: Helps maintain security by ensuring timely offboarding while considering operational dependencies.

Best Practices for Preventing Token and Pipeline Issues

To minimize complications during the offboarding process, consider implementing these best practices:

1. Regular Token Audits: Conduct periodic reviews of active tokens and their usage.
2. Token Expiration Policies: Enforce short-lived tokens with automatic expiration.
3. Shared Service Accounts: Use dedicated service accounts for critical systems instead of personal accounts.
4. Pipeline Ownership Documentation: Maintain a centralized registry of Scheduled Pipeline ownership.
5. Automated Pipeline Transfers: Implement a process to automatically transfer pipeline ownership during offboarding.

Case Study: Improved Offboarding Efficiency

After implementing this automated offboarding process, our organization observed the following improvements:

• 80% reduction in time spent on manual offboarding tasks
• 95% decrease in incidents related to unintended service disruptions during offboarding
• 100% compliance with security policies for timely access revocation

Future Improvements

To further enhance the offboarding process, consider these potential improvements:

1. Self-Service Portal: Develop a user interface for managers to initiate and track the offboarding process.
2. Integration with HR Systems: Automate the trigger of the offboarding process based on HR events.
3. Collect the data from GitLab DB: In our setup, accessing the GitLab DB would be a slightly complicated task and an unwanted overhead for the application. We compromised using the above Python code with a runtime of ~30 min that is acceptable at this time. In different architectures of GitLab (not omnibus), accessing the DB and querying the user info will be much easier and more accessible.

Conclusion

Efficient offboarding of users in GitLab requires a balanced approach that addresses security concerns while maintaining operational continuity. By implementing an automated process with built-in safety checks and escalation procedures, organizations can streamline their offboarding workflow, reduce risks, and ensure a smooth transition when users leave the system. Regular reviews and continuous improvement of the offboarding process will help organizations stay ahead of potential issues and maintain a secure and efficient GitLab environment.