The goal of baseline and role-based entitlements is to increase security while reducing access management complexity by moving towards role-based access control. The basic idea is that if we configure all of our systems for access based on the specific job families that require access to each system, then as we scale we can simply add new GitLab team-members to these pre-defined groups and system-level access will be granted automatically. The difficult part in this implementation is accurately defining the access each role should have and collecting/maintaining all related approvals. The GitLab solution to this challenge is to use baseline and role-based entitlements. These entitlements define what systems each role should have access to and to pre-approve access to those systems so provisioning can be sped up. Okta will be a huge help in this process as we continue to build out that tool, but these baseline entitlements can still define pre-approved access to systems not managed by Okta. Baseline and role-based entitlements can also help automate access reviews since we will have a solid source of truth for what access should exist for each role and which GitLab team-members should be a part of each role.
The basic workflow for using a baseline or role-based entitlement is:
The hope with the above workflow is that everyone will contribute to the creation of the baseline and role-based entitlements and they will be prioritized based on how frequently the roles have access provisioned for them. The other benefit of this approach to access is that each access request template for the specific baseline or role-based entitlement role can have very specific instructions and links.
For certain roles, role-based entitlement templates have been created and can be used during onboarding. A list of all the roles that have templates can be found on the Access Request project.
issues_templates in the Access Request project is used to document the configuration and approvals for the baseline and role-based entitlements. Any changes to these approved configurations require the approval of the management groups outlined in each of the runbooks.
Role-based entitlement templates should be maintained accordingly, based on the speicifc requirements documented in the Access Management Policy. These templates are utilized internally by Security Compliance and externally by External Auditors when assessing access management controls and procedures at GitLab.
100% of team-members should have access to the following systems at the following levels of access as part of their work at GitLab. This list has been pre-approved so if any team-member needs access to these systems they can reach out directly to the system admin(s) and request access based on this pre-approval.
|System Name||Business Purpose||System Role (What level of access)||Data Classification|
|1Password||User Password Management||Team Member||RED|
|BambooHR||Human Resource Platform||Employee||RED|
|Calendly||Add-in for meeting Scheduling||Employee||YELLOW|
|CultureAmp||360 Feedback Management||User||YELLOW|
|EdCast||Structured and personal learning experiences||User||YELLOW|
|Expensify||Expense Claims and Management||Employee||ORANGE|
|GitLab.com||GitLab Application for Staff||Employee||RED|
|Google Workspace||Email, Calendar, and Document sharing/collaboration||GitLab.com Org Unit||RED|
|Jamf||Apple Device Management Tool||User||RED|
|Modern Health||Employee Assistance Program||Employee||ORANGE|
|Navex Global||LMS Training tool||Employee||ORANGE|
|Okta||Identity and Single Sign On||User||ORANGE|
|PTO by Roots/Treehoppr||PTO tool||User||RED|
|Sertifi||Digital signatures, payments, and authorizations||User||YELLOW|
|Slack||GitLab async communications||Member||RED|
|Sisense (Periscope)||Data Analysis and Visualisation||User||RED|
|Will Learning||Staff Training and Awareness Portal||User||YELLOW|
|YouTube||Video sharing platform||User||ORANGE|
|ZenDesk (non US Federal instance||Customer Support - Incident Management||Light Agent||RED|
|Zoom||For video conferencing / meetings||Pro||RED|
The goal of baseline and role-based entitlements is to increase security while reducing access management complexity by moving towards role-based access control. The basic idea is that if we configure all of our systems for access based on the specific job families that require access to each system, then as we scale we can simply add new GitLab team-members to these pre-defined groups and system-level access will be granted automatically.
There are two ways to go about creating a new role-based entitlement template:
The instructions below mention how to create one from scratch but read through them as they will also help answer any questions on how the format of the templates should be.
Before you get started, please keep in mind there is an approval process for adding new templates. The following people need to review and approve the template before it can be merged:
If you cannot find a template for a role in this list, please create one by following this format
role_backend_engineer.md) and place it in the correct department directory. The title needs to match a valid title in BambooHR (don't include seniority level). You can find the directories and templates here.
For engineering roles or roles with a specialty: The Access Requests are created on a role level and can be created for the specialty level as well. For example if you have a person with the role
Senior Frontend Engineer, Secure. The code will look for two templates:
role_frontend_engineer_secure.md and combine both of them into 1 access request for the new team member. You don't have to have both templates created, it depends on what your needs are. In this example, the
role_frontend_engineer.md template should be a catch-all for all access needed by all Frontend Engineers, regardless of seniority and specialty. Create a separate specialty template if your team members need more access depending on the team they are a part of.
If there's no directory for your department created yet, you can add this as well. Make sure it's in the following format:
A template to get you started can be found here
Provisioners only section, please include all the tools that need to be provisioned under the different teams that need to provision them. You can find the provisioners for the different tools in our tech stack. For example:
#### IT to-do: * [ ] `name of tool`: `level of access or group/project that needs to be accessed by team member` #### Sales to-do: * [ ] `name of tool`: `level of access or group/project that needs to be accessed by team member` #### PeopleOps to-do: * [ ] `name of tool`: `level of access or group/project that needs to be accessed by team member`
Do Not Edit Below, please include the role of the Director or Senior Leader and Manager who will be approving the template creation and changes.
Changes to permissions must be approved and reviewed by: - Director of `Department` - `Team` Manager Changes to permissions must be reviewed by: - Security Manager, Security Operations
As a last step, please make sure your template includes the
/confidential quick action and labels for the different teams/tools/level of access included in the template (find list below). Do not remove the labels that are already part of the template. Also, make sure to assign provisioners to the template after the
/assign quick action. You can find the different provisioners for each tool in the tech stack
/confidential /label ~"NewAccessRequest" ~"ReadyForProvisioning" ~"AR::2-backlog" ~"AR-Approval::Manager Approved" ~"BaselineEntitlementAR" /assign
Labels for different teams:
~"To Do - SalesOPS"
Labels for different tools:
Labels for admin level access:
Once a Role Based Entitlement template has been created and approved by all authorized team members, any access modification will require the same approval process workflow for creating a Role Based Entitlement template.
Role based entitlements are pre-defined groups and system-level access that are granted automatically to team members depending on their role. Role based entitlements Access Requests are created automatically for a new team member on their second day at GitLab if a template exists for their role. We recommend creating a template for all the roles that you are currently hiring for so the new team member's onboarding is as smooth as possible. You can create a new template for any role following these instructions. These templates need to include the tools/systems that all people in a role should get access to and nothing should be added/removed when creating a new issue.
If you haven't created a role based entitlement template for a role you are hiring for, you'll need to manually create a Single Person Access Request for your new hire.
Please use the following steps only in the following situations: A new team member is onboarding and their access request wasn't created OR a current team member is moving to another position internally
All existing role based entitlement templates can be found in this list. The templates are organized by department. Once you have found the template you would like to use:
Editat the top of the file.
Cancelbutton at the bottom of the page
Issuesand create a new issue in the Access Request project.
<!-- include: role_tasks -->
.gitlab/issue_templates/role_baseline_access_request_tasks/under the correct department for the role. Example:
.gitlab/issue_templates/role_baseline_access_request_tasks/department_people_success/role_people_group_fullstack_engineer.mdthis is the path for the Role:
People Group Fullstack Engineer,
Department: People Success.
Start an MR and tag the Business Systems Analysts (@gitlab-com/business-technology/enterprise-apps/bsa) or reach out to us in #business-technology