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.
How do I choose which template to use?
Individual or Bulk Access Request
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 using this same template if multiple people require access to different systems. When access is being requested for multiple people who report to different managers but are part of the same department or division, approval can be obtained by the manager at the highest level; that is, the Director, Vice President, or Executive of the department or division.
Instructions
Title the issue Full Name, System(s), Role using the details of the person requesting access information. If bulk access is being requested then Bulk Access, System(s), Role
Step 1. Personal Information
Personal Information: Please provide a list of people who are requesting access. Include the relevant information.
SSH Keys: Add the public ssh key only if needed for the type of access being requested.
Step 2. Access Request
Remove or add lines for the systems you need access to. Make sure to follow the format from the template (also included below). Be as specific as possible with the access you are requesting by adding the role, vault, group, channel or project you are requesting access to.
If administrative access is being granted, add the label admin-access. Request the least amount of access you need as per the least privilege review and explain why you need access in the rationale section.
If the request involves access to systems owned by the Infrastructure team (according to the tech stack, mention @gitlab-com/gl-infra/managers and ask them to approve by adding the ~InfrastructureApproved label.
- [ ] System name: Which vault, which group, which channel, which project, which role?
- Justification for this access: Please explain why this access is needed.
Step 3: Assign to Manager for approval
If you are a manager requesting access for one of your reports, please skip to step 4.
Add the label AR-Approval::Needs Manager Approval to the issue.
Assign the issue to your manager. When access is being requested for multiple people who report to different managers but are part of the same department or division, approval can be obtained by the manager at the highest level; that is, the Director, Vice President, or Executive of the department or division.
Step 4: Managers to do
If you are the manager of this person, add the labels AR-Approval::Manager Approved and ReadyForProvisioning to the issue; if you are the one asking for access, then you have to assign to your manager for approval and they must add the labels AR-Approval::Manager Approved and ready for provisioning.
Before provisioning, consider that team members should only be granted the minimum necessary access to perform their function. Determine whether the access level is necessary or if a lower access level would be sufficient.
If the access level is adequate proceed with provisioning the account after verifying the AR-Approval::Manager Approved label is present.
Under step 2, please check off the system you provisioned.
If administrative access is being granted, add the label admin-access to this request so Security Operations knows who has admin access.
If admin access is being granted to GitLab.com ensure the user is added to the GitLab Instance Administrators group
Inform the user 2fa is required and they will be locked out if it is not immediately setup
Shared Account Access Request
Instructions
Prior to submitting this Issue Request
Please review our Access Control Policy and Procedures to ensure that your request is in line with GitLab’s policies and procedures. If after review you feel that a shared account is still needed, complete submit the issue using the template. Note that systems with PCI data is not allowed shared accounts.
Please note that shared account request(s) will need to be reviewed and approved by IT Ops and the listed Tech Stack Owner.
An Exception Request will need to be logged for each user you are requesting to be added. Note that with an Exception Request the maximum exception length is 90 days (365 days for device exceptions only).
After the Exception Length, you will be required to submit another Exception Request for review and approval.If the exception request is not logged, reviewed, and approved for an extension, note that the Shared Account will be disabled. Please refer to our Information Security Policy Exception Management Process handbook page for more information.
Instructions on how to submit this issue request
Title issue “Shared Account Request, Role, System(s)” using your information.
Fill out the User Details section and remove or add lines as needed.
Add lines for the system(s) you need access to so only the ones you want are left in the issue. Do not check them off.
Request the least amount of access you need as per the least privilege review and explain why you need access in the rationale section and name the role you are requesting. Be specific.
If you are the manager of this person, add the labels AR-Approval::Manager Approved and ready for provisioning to the issue; if you are the one asking for access, then you have to assign to your manager for approval and they must add the labels AR-Approval::Manager Approved and ready for provisioning.
Instructions and Guidance for IT for Shared Accounts
Review the Shared Account Access Request and ensure that there is an Exception Request for each user that is being added to the shared account. Review the Exception Request and document in the Access Request issue the Exception Length. Ensure that the Exception Request has been reviewed and approved by Security prior to adding your approval or setting up the shared account.
All shared accounts must be managed via Okta. If 1password must be used (okta not technically possible), this needs to be outlined in the Access Request.
If the shared account will be managed in Okta - Set a review/reminder date in Okta to review shared account access dependent on exception timeline and close issue.
When notification is received from Okta regarding timeline length nearing expiration, log a new Shared Account Access Request and assign to the Shared Account Owner to complete.
If the shared account will be managed in 1Password - Add a Due date dependent on exception timeline and leave issue open.
When notification is received from GitLab.com regarding timeline length nearing expiration, close existing issue and log a new Shared Account Access Request and assign to the Shared Account Owner to complete.
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.
What this means is:
A GitLab Team member gets transferred to a different role.
The team member’s profile in Workday is changed.
This profile change automatically triggers a change in the team member’s Okta profile accordingly.
This, in turn, results in the team member getting assigned to new applications based on their new department and role.
Simultaneously all old applications that are not relevant to their new role get revoked/unassigned.
Additionally, the Okta administrator gets an Email from Okta, that there has been a change to a User profile - (Email Subject line: 1 existing user updated). Okta automation already happens in the background, this email is informational only.
While this application automation will take place in Okta, “true” system provisioning and deprovisioning will still need to be manually completed within the impacted systems via an Access Change Request.
Slack, Google Groups, 1Password Vaults or Groups Access Requests
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 using this same template if multiple people require access to different systems. When access is being requested for multiple people who report to different managers but are part of the same department or division, approval can be obtained by the manager at the highest level; that is, the Director, Vice President, or Executive of the department or division.
Instructions
Title issue “Full Name - System - Role” (ex: Laura Croft Google Group: adventurer)
Remove or add rows for the access you need.
Assign to your manager to get approval by label if this request is for (they must apply labels AR-Approval::Manager Approved and ReadyForProvisioning:
access to a 1Password vault or group
admin access
access to a slack group for a non-internal person, including shared Slack channels
Please note if a non-internal person has been removed from a slack channel and is requesting access again they will need a new access request and manager approval
Title the issue Full Previous Name to Full New Name - Name Change Request.
Please complete all applicable sections as described in the issue template.
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.
Please @ mention @gitlab-com/business-technology/end-user-services 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.
I need access
My AR request has been open for a while, how can I get traction on it?
Review that the access request has been completed according to the instructions and that you have included the system/vault/group/project you need access to plus the role or permissions needed.
Most access requests need Manager approval so make sure to tag your manager in the AR and ask them to add the ~“AR-Approval::Manager Approved” and ~“ReadyForProvisioning” labels to the issue
Make sure you have tagged and assigned the issue to the correct provisioner(s) for the tool(s) you are requesting access to. You can find the provisioners for all our tools in our Tech Stack
If the provisioner is the IT team, please make sure to add the ~“IT::to do” label to the AR.
If you have followed all the steps above and your access request is still not being worked on, reach out to the team that owns the tools in their Slack channel. You can find the Slack Channel for each team in our Tech Stack
So you need access to a system or a group/vault?
Choose a template based on your needs: most people use the Bulk or Single Person template.
Do not open an Access Request for anything that is part of a baseline entitlement unless it got missed during onboarding.
When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.
Cookie Policy
User ID: c4a8a2d3-e1dd-4012-a645-23adf19cf4fc
This User ID will be used as a unique identifier while storing and accessing your preferences for future.
Timestamp: --
Strictly Necessary Cookies
Always Active
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, enabling you to securely log into the site, filling in forms, or using the customer checkout. GitLab processes any personal data collected through these cookies on the basis of our legitimate interest.
Functionality Cookies
These cookies enable helpful but non-essential website functions that improve your website experience. By recognizing you when you return to our website, they may, for example, allow us to personalize our content for you or remember your preferences. If you do not allow these cookies then some or all of these services may not function properly. GitLab processes any personal data collected through these cookies on the basis of your consent
Performance and Analytics Cookies
These cookies allow us and our third-party service providers to recognize and count the number of visitors on our websites and to see how visitors move around our websites when they are using it. This helps us improve our products and ensures that users can easily find what they need on our websites. These cookies usually generate aggregate statistics that are not associated with an individual. To the extent any personal data is collected through these cookies, GitLab processes that data on the basis of your consent.
Targeting and Advertising Cookies
These cookies enable different advertising related functions. They may allow us to record information about your visit to our websites, such as pages visited, links followed, and videos viewed so we can make our websites and the advertising displayed on it more relevant to your interests. They may be set through our website by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant advertisements on other websites. GitLab processes any personal data collected through these cookies on the basis of your consent.