This is a Controlled Document
Inline with GitLab's regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.
Centralized access management is key to ensuring that the authorized GitLab team-members have access to the correct data and systems at the correct level. GitLab access controls are guided by the principle of least privilege and need-to-know.
These controls apply to information and information processing systems at the application and operating system layers, including networks and network services.
The access request project is used to request and track the following access-related activities:
The Temporary Service Providers>Lifecycle Management project is used for requesting and tracking all short-term non GitLab team member (consultant, vendor, contractor, etc.) access:
Usage guidelines for each of the access templates is outlined on the Team Member enablement's handbook page.
These templates should be used during the onboarding process and throughout the employment tenure of a GitLab Team Member. Access required as part of the team member's onboarding should be requested using the New Access Requests or if applicable, one of the available Role-based entitlements templates.
| Role | Responsibility |
|---|---|
| Security Assurance | Responsible for implementing and executing this procedure |
| Business or System Owners | Alignment to this procedure and any related standards |
| Security Assurance Management (Code Owners) | Responsible for approving significant changes and exceptions to this procedure |
| Team Members | Responsible for adhering to the requirements of this policy |
All new access or permissioning change requests that are not part of a team member's baseline role-based entitlements will require a New Access Request.
Shared accounts may not be used for customers.gitlab.com, dev.gitlab.org, Shopify, Stripe, and Zuora in order to comply with PCI-DSS requirements. Currently, GitLab's financial controls prohibit the use of shared accounts within the following applications: NetSuite.
Shared and group credentials are restricted. Any systems that require shared accounts or credentials and are not yet implemented or configured into Okta must have an Access Request approved and an exception to this procedure for each user. Bulk access requests are not allowed for shared or group credentials.
All access requests must be approved by the team member's manager with the exception of:
Please note that ARs for access to internal systems for "external to GitLab individuals" (eg. customers, prospects) require managerial approval. This includes access to Google Workspace security groups also require managerial approval.
Access requests are required when requesting a role above developer (i.e. maintainer, owner) on the following GitLab repositories and Groups:
For all projects, access requests should be submitted when requesting explicit access to private groups, sub-groups, and repositories, as well as public facing repositories that are limited in access to GitLab team members in order to facilitate deprovisioning. This also allows for greater oversight of permissions being granted across GitLab projects.
Requests for access to Infrastructure assets (servers and databases) require a second layer of approval from Infrastructure Management.
All access requests must be provisioned as approved. An AR that is approved without a role specified should not be provisioned until the role being requested is identified and re-approved.
Administrative permissions should be considered operational in nature. This means they are granted for the sole purpose of system management, configuration, and support. They should be recognized as privileged accounts and as such, activities must be logged and the logs protected and regularly reviewed.
Time-based access may be provided if administrative action is required for a set period of time. This should be documented as part of the Access Request SLAs.
All requests for new service accounts require a New Service Account Request
All requests for new service accounts must be approved by a member of Infrastructure Management.
In regard to support during or prior to provisioning, please do not tag the Security Operations team in the AR issue; to ask Security for help with AR assignments, please use the #it_help channel.
If admin-level access is being requested, the request must be approved by the team member's manager and Infrastructure Management if applicable.
GitLab has an established RBAC via the formalization and maintainence of Baseline Role-Based Entitlements. RBAC is subject to continuous control monitoring by the Security Compliance team to ensure that GitLab meets it's regulatory and compliance obligations related to user access to information. Additionally, as noted per the requirements in the role baseline template, changes to permissions on these documents are required to be reviewed and approved by the Director, Senior Leader or Manager of the team that the role belongs to. If an update is proposed by a Manager or above, it should be reviewed by another, more senior manager of the team that role belongs too.
The structure of the baseline role-based entitlements ensures that team members receive the appropriate access privileges when they join GitLab. These templates are based off one of the following:
Specific instructions for the creation, review, and maintenance of these templates can be found here. These instructions also include details on any nuances that should be considered as part of the creation of the template.
An access request is not required for Google Drive folders or files.
Managerial approval is not required when requesting access to:
Bulk access requests are those that are for multiple GitLab team-members. Bulk requests can be submitted for the following three types of requests:
Please note that the above use cases do not apply to ADMIN-level access, which needs to be submitted using the one issue per GitLab team-member rule.
During the onboarding process, the manager should determine which email and slack groups the new team member should be added to. Also determine if new team member will need access to the dev server, which is used by engineers to prepare fixes for security issues and also allows for access to version.gitlab.com and license.gitlab.com. If so, request the creation of a new dev.GitLab.org account with the same username the team member has on gitlab.com and an invitation to the gitlab group as a Developer. Fill out one access request for both the groups and Dev account if needed.
GitLab operates its access management under the principle of least privilege. Under least privilege, a team member should only be granted the minimum necessary access to perform their function. An access is considered necessary only when a GitLab team member cannot perform a function without that access. If an action can be performed without the requested access, it's not considered necessary. Least privilege is important because it protects GitLab and its customers from unauthorized access and configuration changes and in the event of an account compromise by limiting access.
A least privilege review should be performed by a system's administrator and the manager of the team member for whom access is being requested. System administrators should be provided security training that includes specific training on least privilege and its application.
To perform a least privilege review, compare the rationale provided for the service(s) to which access is being requested with the level of access being requested.
rationale section of the access request.If the access requested provides the team member only the access they require to perform what's in the rationale section of the access request, the access request should be approved. In this case, simply proceed with approving the access request. An access request approval is considered confirmation the request has been reviewed for least privilege. Once your approval has been submitted, there's no more action for you to take for the least privilege review.
If the access requested provides the team member access beyond what is required in the information provided in the rationale section of the access request, the request doesn't align with the principle of least privilege and the request should be temporarily rejected until the appropriate access can be defined. To reject an access request on the basis of least privilege, respond to the issue with the following information:
Should there be disagreement on an access request rejection on the basis of least privilege, an exception request should be submitted. An exception request is important because it provides a clearly defined escalation process, promotes transparency, and allows us to appropriately track any deviations from policy.
In the case of a separation from the company, all access will be deprovisioned within 5 business days from the date on which the offboarding request is submitted unless otherwise specified.
All attempts will be made for individual access removal requests to be processed within the SLA requested. If no SLA is noted, access will be deprovisioned within 5 business days of the submission of the issue.
If access removal needs to occur immediately, please follow the panic email procedures, which will alert the Security Team on-call.
An access review should be documented and performed as part of a formal job transfer. The review should be perfomed by the new manager of the team member who is transferring to a new role.
Upon notification of a reassignment or transfer, management reviews the GitLab Team Member's access for appropriateness. Access that is no longer required is revoked and documented.
Access reviews will be formally documented using the Access Reviews template.
gitlab.org owners and maintainers will be performed quarterly by the Security Compliance team and verified by Infrastructure for appropriate permissions.As part of an access review, existing access may be modified or revoked. New access (not modification of existing access) requires the submission of a New Access Request.
Please note that access reviews should include a least privilege review. This is considered as part of the review of appropriateness of system entitlements, aka access level.
Review and recertification is generally performed by team member's manager or someone above them in their reporting hierarchy. For example, review can be performed by a Director and include their direct reports' direct reports.
If reviewer is not the manager of team member, reviewer should be the system owner or the data owner, or an individual with sufficient understanding of the system(s), the system entitlements, and the ability to assess the appropriateness of the access granted.
Reviewers must never recertify their own access; this must be reviewed and recertified by an alternate system administrator, system owner, or the primary reviewer's manager (or someone above them in their reporting hierarchy).
Please refer to the Access reviews page for additional information.
GitLab's access controls include the following control activities:
The generic @gitlab-bot account should not be used for new automations, and for each
different tasks a new service account should be created. The rationales
behind this are:
A New Service Account Requests should be filled to request a new service account.
Access tokens for each service account should be requested accordingly.
+admin@gitlab.com as the email address: username+ADMIN@gitlab.com-admin appended: username-adminThe admin account "Full name" should include text to indicate it is an admin account: First Last (Admin)
+[TASK NAME]-bot@gitlab.com as the email address: GROUP+TASK-BOT@gitlab.comgitlab and append with the task name and -bot: gitlab-task-botIf you would like to check whether or not a team-member is a member of a Slack or a Google Workspace group, you can view the following automated group membership reports:
Google Workspace Group Membership Reports
Slack Group Membership Reports
Every service and application must use unique identifiers for user accounts and prevent the re-use of those identifiers.
For example, if a user account is identified with a username, there can only be one account with that username. Accounts may eventually be deleted and that username (or other unique identifier) intentionally released for re-use, but that new account may not have the same permissions or access as the first account that was deleted. This doesn't preclude the use of shared accounts (except where it is strictly forbidden, like in-scope PCI systems) and applies to both individual and shared accounts. If a shared account is used, that account must have a unique identifier in the same way an individual, non-shared account does.
This is required to allow the actions of any given account to be associated back with that particular account. If two accounts share an identifier, if a malicious action were taken, we'd have no way of identifying which of the two accounts performed that malicious action. It's also important to preserve the confidentiality of information; if access or permission are given to an account, they should only be given to the specific account for which they were intended.
For anyone hired after 2020-03-23: GitLab will block and reclaim team-members gitlab accounts during the offboarding process. The reasoning behind this is due to the case of visibility into confidential issues; if the closed-assigned or participant issues are in public projects, the former team-member will continue to have access to the closed issues and will continue to be updated and can access the confidential issues where they are a participant. For this reason, we advise team members to not utilize your work GitLab account for personal projects.
For anyone hired before 2020-03-23: Upon offboarding - IT Operations will update your email address on your GitLab account to be your personal email that is on file in Workday and you will be allowed to take your account with you. Please note: should you ever be rehired at GitLab, you will be required to make a new GitLab account. Access to all GitLab related projects and groups will be removed.
Access to all systems including gitlab accounts should be removed throughout the off boarding process to mitigate the risk of off-boarded employees retaining access to our systems and confidentail information. In line with our SOX requirements please refer to our SOX ITGC Compliance HB page control LA.2 for additional information related to our ITGC controls.
Exceptions to this procedure will be tracked as per the Information Security Policy Exception Management Process.