Centralized access management is key to ensuring that the correct GitLab team-members have access to the correct data and systems and 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 GitLabber. 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.
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 policy 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:
Access requests should be submitted when requesting explicit access to private groups, sub-groups, and repositories in order to facilitate deprovisioning.
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 that 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.
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 or 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 of 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 GitLabber 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.
rationalesection 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 3 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 3 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 GitLabber's access for appropriateness. Access that is no longer required is revoked and documented.
gitlab.orgowners 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:
+firstname.lastname@example.org the email address: username+ADMIN@gitlab.com
The admin account "Full name" should include text to indicate it is an admin account: First Last (Admin)
If 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:
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.