Access Requests (AR) Services
Access Requests are owned by the Corporate Security Helpdesk team. All onboarding, offboarding and role change (career mobility) requests are owned by the People Connect Team.
If you have any access requests related questions, please reach out to #it_help
in Slack or the tool provisioner in Slack.
Issue Trackers
- Team Members (use this by default): Access Request Issue Tracker
- Temporary Service Providers: Lifecycle Issue Tracker
- Employment Onboarding: Employment Issue Tracker
- Employment Career Mobility: Employment Issue Tracker
- Employment Offboarding: Employment Issue Tracker
Team Member Issue Templates
- Specific Application Requests (use Individual or Bulk Person Access Request if not listed)
- Standard Access Requests
- (Use this by default) Individual or Bulk Person Access Request: One or multiple people requesting access to systems
- Create one issue for one or multiple people to get access to the same system
- Create one issue for one person to get access to multiple systems (checklist)
- Create multiple issues (one per system) to grant multiple people to the each (same) system
- 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 (ex. Director, Vice President, Division E-Group Leader). Comment approval by cross-functional managers is sufficient since only one manager can apply the approved label.
- Access Change Request: Remove or change the level of access to an application/system/distro (non-urgent change).
- Access Reviews
- (Use this by default) Individual or Bulk Person Access Request: One or multiple people requesting access to systems
- Infrastructure
- New AWS Account (Individual) - self service using Sandbox Cloud (powered by HackyStack)
- New AWS Account (Group/Team/Service)
- Add IAM Users to AWS Account
- New GCP Project (Individual) - self service using Sandbox Cloud (powered by HackyStack)
- New GCP Project (Group/Team/Service)
- Add IAM Users to GCP Project
- Sysadmin (BLACK) Account Requests
- Special Use Case Access Requests
- Demo Accounts and Licenses
- Service Accounts
- GitLab.com SaaS Service Account Requests - Admin only, not needed for group/project tokens
- GCP or Google Workspace API/Service Account Requests
- Okta Admin Service Account Requests for apps, groups, and users
- Other Service Account (App to App)
- Other API Token Request
- Tech Stack
Role Based Entitlements
-
Role based entitlements are a pre-approved set of permissions that are granted to all people in a role. Make sure that whatever set of permissions you are adding to these templates should be granted to anyone with that role.
-
Role based entitlements need to be approved only once, when the template is created, and they don’t need to be approved again on a case-by-case basis.
-
These templates cannot be edited to remove or add extra permissions once created, unless those changes are approved by a manager (or higher) of the team the role belongs to. Note that an approval is still required even if a change comes from a manager or higher on a baseline entitlement template to mitigate the risk of a permission change being pushed through by a single team member.
-
We have decided to remove all SOX applications from the Role-Based Entitlements templates. Therefore, any access that is requested for our SOX-in-scope systems should follow the standard A/R process outlined here in our handbook. The impact to you is for any access going forward that was granted automatically via a role based entitlement will now need to be requested via a standard A/R so we can ensure approvals are properly captured.
-
Please note when editing an existing template or creating a new one do not include access of any kind to a rolebased access template. Full listing of SOX applications can be found here
Need help?
- Please mention
@gitlab-com/business-technology/end-user-services
in the issue, with no particular SLA. - If your request is urgent, post a link to your access request in the
#it_help
channel in Slack with a note on why it is urgent.
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.
Tech Stack Changes
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
b684cdaf
)