This handbook section defines the latest iteration of infrastructure and security standards for GitLab team members. These provide a baseline for the GitLab organization, and we have Infrastructure Realms for each of our infrastructure teams that override these standards to meet specific business needs.
The following standards are covered:
These standards were created by a cross-department collaboration in this sandbox-cloud#3 Budget and Cost Allocation issue and infrastructure&257 Provide cloud resources for non-production usage.
These standards apply to new infrastructure. Existing resources can adopt these standards as infrastructure is iterated, unless advised by Infrastructure Security, IT, Reliability SRE.
You can think of each realm as a domain or namespace that provides flexibility for department(s) and group(s) that use that realm to customize their infrastructure configuration and security policies as needed without affecting other departments or realms at GitLab.
For cloud infrastructure, we have created top-level AWS organizational units and GCP folders under the respective cloud provider top-level organization account that we refer to as "realms".
| Realm | Data Classification | Resources Managed By | Usage Documentation | Slack Channel |
|---|---|---|---|---|
infra-shared-services |
Red/Orange/Yellow/Green | infra-realm-owners |
Realm Docs | #infra-realm-owners |
it |
Orange/Yellow/Green | IT Engineering | Realm Docs | #it_help (tag @it-eng) |
saas |
Red/Orange/Yellow/Green | Reliability Engineering | Realm Docs | #infrastructure-lounge |
sandbox |
Green | Self Service (Team Member) | Sandbox Cloud | #sandbox-cloud-questions |
security |
Orange/Yellow/Green | Infrastructure Security | Realm Docs | #security-infrasec |
Are you looking to deploy a production or production-like service? All engineering or product related production infrastructure should be deployed and managed in the saas realm that is managed by the Engineering Infrastructure team with SRE on-call coverage. All business (non-engineering) production infrastructure should be deployed in the it realm in the GCP project or AWS account specified by the security team. All standardized security and logging resources that are not managed in the saas or it realm should be deployed in the security realm.
Want to add a realm? Any departments without their own realm should have resources for their groups (teams) created in the sandbox or it realms. If there are enough cloud resources and a dedicated infrastructure engineer team member to justify creating a new realm, please see the instructions for creating a new infrastructure realm.
Approximately ~750 of the GitLab team members are in departments that use cloud infrastructure for development, experiment, testing or non-production purposes. This includes team members in Customer Success, Engineering division departments, Support, etc. For documentation purposes, we refer to this as the GitLab infrastructure community.
For any groups that are not part of the GitLab infrastructure community (ex. Finance, Marketing, Sales, etc), please reach out to #it_help for assistance with your infrastructure needs.
We've standardized how we create and manage ephemeral (sandbox) infrastructure that GitLab team members provision.
The oversimplified user story is "I need to spin up VM(s) or cluster(s) in GCP or AWS to try something (anything, may not be GitLab product specific), what's the company infrastructure standards for doing that?"
The Sandbox Cloud is a custom-built web application that automates the provisioning of an AWS account or GCP project for each GitLab team member that needs one for ephemeral sandbox and testing use cases.
The goal is to create a frictionless approach for technical team members that includes the tagging needed for cost allocation, best practice security configurations, and provide you the ability to create any resources that you need using the AWS or GCP web console or use our shared library of Terraform modules that include documentation and usage examples that can be copied into the Terraform configuration file for each user account. When you sign in with OKTA, we use the OKTA meta data that is integrated with Workday to determine your department and entity for cost reporting, and use this for the auto-creation of a tagging policy for resources that you create.
Learn more on the sandbox realm handbook page.
Are you looking for a sandbox or testing AWS account or GCP project? Please use the GitLab Sandbox Cloud which gives you access to your own private AWS account or GCP project that grants you owner permissions and has centrally managed billing with the GitLab master account.
Are you looking for an AWS account or GCP project to deploy experimental or testing resources that you will share with your team? You can request a Group AWS account or GCP project using the Sandbox Cloud. See the handbook page for instructions.
In the near future, we will be introducing readiness reviews for more infrastructure realms.
Each realm has one or more team members that are system owners that are the DRI or stable counterparts responsible for all of the infrastructure architecture, billing, resource provisioning and security policies in that realm.
Each realm DRI or counterpart is an engineering manager or experienced infrastructure engineer who can perform all actions needed for day-to-day management of the realm, including responding to security incidents and supporting group owners and counterparts in their realm.
Our infrastructure standards are designed to provide a well defined baseline with guidelines for customization by realm owners as needed within their realm.
You can see the list of infrastructure realm owners in the Google Group (internal).
The AWS architecture is currently being designed. Please create a GitLab issue and tag jeffersonmartin, dawsmith, and jurbanc for assistance in the interim.
