Access Level Wristband Colors

Purpose

We provision different levels of access to systems at GitLab based on your role and user type.

You are likely familiar with our Data Classification color coding of RED, ORANGE, YELLOW, and GREEN.

We have completed the colors of the rainbow with our Access Level Categories, also referred to as wristband colors. The color of your wristband dictates which level of access each account has, and allows us to easily audit and manage controls and processes for each category.

Never heard of these wristband colors or access levels? It is safe to assume that all of your user accounts and access are PURPLE accounts, and you likely don’t need to worry about any other access levels for your own user credentials unless you have elevated or admin access. If you’re not sure, please ask for assistance in #it_help.

Access Level Categories

BLUE

A BLUE account is any human user that is not classified in the Team Member Types. We only provide access to the applications and specific roles needed to based on job responsibilities (usually related to the scope of work for the contract).

See the Temporary Service Provider handbook page to learn more.

PURPLE

When a team member joins GitLab, there are several systems that are provisioned as part of the normal onboarding process including Okta, Google Workspace (ex. Gmail), and 1Password. We refer to these as your PURPLE wristband accounts.

Any processes and systems that use your {handle}@gitlab.com email address and are part of Baseline and Role Entitlements or an access request are provisioned in your PURPLE account.

For team members in Infrastructure, IT, Security, or other departments with elevated access, your elevated or admin access will usually be provisioned in your BLACK Account.

GRAY

Gray accounts are secondary user accounts when required for a specific appllication function, different role, or test account.

The user must also have an active Blue or Purple account.

This is a corner case that is usually used by IT and Security team members for test accounts, or secondary accounts for Salesforce (SFDC).

BROWN

A BROWN account is for any system user that is used for API tokens, bots, service accounts, or other system related (non-human) credentials. The methodology will vary based on the system and we have a lot of legacy service accounts that may not comply with this policy. This standard is designed for new service accounts and any service accounts that get updated so we iteratively update and migrate legacy service accounts.

Most service accounts require an email address. If an Okta user account is not required, we usually create a Google Group email alias for the service account with DRI team members as members. All service account credentials are stored in a new 1Password Vault (per service) that the DRI team members for that Google Group are added to.

BLACK

For IT Systems Engineers, IT Analysts, IT Security Engineers, Security Incident Response Team Engineers, Site Reliability Engineers, Audit/Compliance team members (read only), and other roles that require elevated or admin access to compliance in-scope or specifically identified critical tier systems, we provide an additional user account ({firstInitial}{lastName}-admin@gitlab.com) to securely distinguish and manage your elevated access to these systems. We refer to these as your BLACK wristband accounts. You will usually have both a PURPLE and BLACK account for these systems.

Unlike your PURPLE Okta account or 1Password vault that you can access from your mobile device, your BLACK admin accounts have stricter policies and are restricted to a Chrome profile on your GitLab laptop with full separation from your normal PURPLE accounts that are stored in a separate 1Password account and vault and has YubiKey 5 FIPS MFA enforced for security and compliance reasons.

See Okta Admin Account Onboarding Runbook to learn more.

Please contact Jeff Martin for questions or assistance with BLACK accounts.