Access Requests (ARs)

This is a Controlled Document

In line with GitLab’s regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.

Access Requests are owned by the IT team, while onboarding, offboarding and internal transition requests are owned by the People Connect Team.

If you have any access requests related questions, please reach out to #it_help or the tool provisioner in Slack.

Get Started

All open and closed ARs can be found in the access-requests project, and you can create a new issue here.

When creating a new AR, you’ll be given the option to chose from various templates to help you figure out exactly what additional information is needed to fulfil your request and if additional approvals are required. We made sure to add all the required lables for each issue type, it’s possible that we missed something so please make sure to double check your request before submitting it

While there are a large number of templates available, they typically fall into one of the categories below.

A full list of all available templates cane be found here

Individual or Bulk Access Request

Individual or Bulk Access Requests should be used if none of the oher templatess match what you are looking for.

You can use this template to request access for individuals or multiple people, as long as all the people are requesting access to the same systems. Create multiple issues if multiple people require access to different systems.

Access Change Request

Access Change Requests are logged when a team member no longer requires access to a currently provisioned system or no longer requires the same level of access (downgraded access from admin to user etc). Refer to For Total Rewards Analysts: Processing Promotions & Compensation Changes section of the GitLab handbook for additional information.

It is important to note that while Okta has provisioning/deprovisioning automation in place, this is not a complete/accurate reflection of access provisioning and deprovisioning. Okta has been configured to assign integrated/implemented applications based on a user’s role/group. This makes applications accessible via Okta but users may still have the ability to access the systems directly. Refer to Okta Application Stack for a list of applications set up in Okta.

Application-Specific Templates

These issues relate to access to or withing specific applications and services. For example, you can use the 1Password Request Form to modify existing vaults and groups, or to create new ones.

Admin (Black) Accounts

We support the provisioning of admin access to various core services, such as Okta, 1Password, and Google Workspace. This proccess typically first involves requesting the creation of an admin account with a new email address. Once the admin account has been created, additional ARs need to be submitted for admin access to specific services.

Name Change Request

You can use this template when you want to change your preferred name. We will then work with the People Ops team to update your name across all systems and provide you with a new email address.

Baseline Entitlements

These issues help us assign the appropriate access to new-hires. These are created automatically for many roles and don’t typically require additional approvals. However, if the automation does not create the issue, it is the responsibility of the new-hire’s manager to manually create the issue.

A list of baseline issue templates can be found here and can be freely customized.

For additional support when creating Baseline Entitlement Requests, please reach out via #it_help in Slack.

Working on Access Requests

Department Access Request Boards

If you need additional labels or have suggestions for improving the process until we can fully automate, please open an issue.
ARs are auto-assigned and auto-labeled when possible by department. In some cases, there are multiple provisioners per tool. If a template cannot be auto-assigned, Business Technology will provide a board where the provisioners can review their department’s issues by label (ie dept::to do. It is up to the department to manage the workflow on who works the issues to completion.
Moving an issue from one column to another will remove the first label (per the column header) and add the second label. Please use caution when moving issues between columns.
Departments can check their outstanding access request issues by viewing their board below.

AR boards: to-do:

Adding Access Request Process for a new item in the Tech Stack

If you need to initiate an Access Request process for a new item in the tech stack:

Confirm the tool is added to the tech stack
Confirm a team member is included as the provisioner deprovisioner
Document the requirement to submit an Access Request in any relevant handbook pages

Additional help

Please @ mention @gitlab-com/gl-security/corp/helpdesk in the issue, with no particular SLA.
If your request is urgent, @ mention it-helpin the #it_help channel in slack with a note on why it is urgent.