Limit access to a runner to specified users, group or projects (#6058) · Epics · GitLab.org

Limit access to a runner to specified users, group or projects

## Problem(s) to solve - To comply with the segregation of duties, organizational policy, or security requirements, organizations, customers in financial services, or the federal government market segment must ensure only authorized users can use runners associated with particular CI build environments. - For GitLab SaaS customers, the problem statement is further refined to "**Managed runner groups aren't available to large enterprises with compliance concerns on SaaS GitLab**" ### Jobs to be done (JTBD) - As an administrator of a self-managed GitLab instance, I need to restrict the use of an `instance-level` type runner to specific users or groups to ensure that only authorized users have access to a runner that is used for deploying code to a production environment. In this case, the CI build environment and target production environment should not be considered to be the same. - As a maintainer of a group (namespace) on GitLab.com (SaaS), I need to restrict the use of a `group-level` type runner to specific users or groups to ensure that only authorized users have access to a runner that is used for deploying code to a production environment. There are several use cases for this problem that are typically related to limiting who can deploy to particular environments. From discussions with customers, the current capabilities in GitLab (protected environments, protected branches) do not provide the type of rigorous controls that some organizations require. ## Requirements / Use Case Scenarios ### Use Case 1: AWS Security #### Current configuration - In this use case, the enterprise customer has configured an EC2 instance to host a runner. - The runner uses an instance profile with a role that trusts ec2.amazonaws.com - The role has the ability to assume a powerful provisioning role that has access to all of the accounts in AWS. - In GitLab, the runner is associated with a specific group. Example group name = `aws-account-guardrails` group - Any project in the `aws-account-guardrails` group can use the AWS runner. - Group Owners or Maintainers can configure individual projects to further restrict which Git branches (like main) can run a pipeline that uses this runner. #### Risks/issues with the current configuration - GitLab group, subgroup, or project membership can be changed by accepting a request to join as a Developer or Maintainer, or adding someone to a parent group without realizing the cascading membership to this project. - GitLab project Owner or Maintainer removing protected branch status within a project, opening up pipelines to users with a Developer role. - GitLab runner misconfiguration to associate the runner with an unintended group. #### User Story / requirements - As the GitLab administrator, I want to make sure only authorized individuals can perform actions in AWS through a pipeline, but right now the best I can do is give the runner those permissions in full, and hope the runner remains configured to be usable only by the right people. ### Use Case 2: PCI-DSS 6.4.2 #### PCI-DSS 6.4.2 requirements - A separation of duties between personnel that are assigned to the development/test environments and those persons assigned to the production environment. - To meet this requirement organizations typically use a set of credentials for the production environment that is separate from those used in the development/test environments. “Not only will this directly help address PCI DSS Requirement 6.4.2, but a review of access controls will demonstrate that a user performed a specific role while using an account intended for that dedicated purpose, which establishes accountability.” #### Customer requirements to address PCI-DSS 6.4.2 - How do we protect the GitLab runners properly? - How do you prevent a user from setting the wrong tag in the .gitlab-ci.yml file? In the case of this customer, setting the wrong tag may result in the user deploying code to the wrong environment. - How do you prevent a user from deploying into an environment that they don't have access to? - Is there any way to set up a protected series of GitLab runners, i.e. runners that only a specific team can access even though they are associated with multiple projects or groups? ### Use Case 3: Financial Services organization with a large organization structure and stringent compliance requirements. - The customer has over 1500 teams/groups. These groups are organized into lines of business. - The customers need to restrict the usage of runners by lines of business. However, in this case, creating and managing over 1500 group runners is not scalable. So the requirement is to have instance-level runners, that can be restricted to a group or groups. So groups in the organization must only use a Runner that the line of business supports. #### Example hierarchy | Line of Business | Mnemonic |Mnemonic - Group ID's| | ------ | ------ |------ | | Line of Business A | AGX | AGX-00, AGX-01, AGX-02| | Line of Business B | BGX | BGX-00, BGX-01,BGX-02| ## Intended users * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * GitLab instance administrator * GitLab group maintainer ## User experience goal - **Self-Managed GitLab**: The admin user should be able to restrict the use of an instance level runner to specific groups or users. - **GitLab SaaS or Self-Managed**: The Group maintainer should be able to restrict the use of a group level runner to specific groups or users. ## Proposal: Access control list, for instance, or group runner - An administrator at the instance level or group owner at the group namespace level can define an access control list for a Runner. - An administrator can specify the group namespaces with access to an instance Runner. - A group owner can specify the sub-groups and projects with access to the group Runner. - Once a Runner's access is limited by the access control list, it will not accept jobs from groups or project that are not in the list. ## Questions to resolve - Will administrators be able to set an allow list for group runners? - Will the allow-list feature be available to just top-level groups or sub-groups as well? - Can groups owners override allow lists for sub-groups? - At scale, will there be any performance impacts as a result of the additional checks that the system will need to make to validate that a job can in fact run on an access control list enabled Runner? ## Permissions and Security {placeholder for iterating on the permissions and security model.  ## Is this a cross-stage feature? This is very likely a cross stage feature.  ## Links / references   *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*

epic