Protected runner - a new runner type

Problem to solve

In order to meet PCI segregation of duties requirements, financial services organization needs to ensure that only authorized users can use runners associated with production 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" (Note - this will require a separate issue as we will need to iterate on delivering the final solution.)

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's is used for deploying code to a production environment.
As a maintainer of a a group (namespace) on GitLab.com (SaaS), I need to restrict the use of an group-level type runner to specific users or groups to ensure that only authorized users have access to a runner that's is used for deploying code to a production environment.

There are several use cases for this problem and 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.

Intended users

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

Protected Runner

Create a new runner of type = protected_runner.
If a runner of type = protected_runner is created at the instance level and therefore a Shared Runner, then this new runner, by default will not be accessible by any user or project in the GitLab instance.
If created as an instance-level Shared Runner, then do not list the runner of type = protected_runner by default to groups, sub-groups or projects in the instance.
If a runner of type = protected_runner is created at the group level and therefore a Shared Runner, then this new runner, by default will not be accessible by any sub-group, user or project.
If created as a group level runner, do not list by default the Protected Runner in the runners view for each sub-group, or project in the group.
If created as a group level runner, then the group Maintainer must be able to manage the authorized user list without needing to engage a GitLab instance administrator.
Implement audit logging of any changes to the authorized list of user for any runner of type= protected_runner.

Conceptual workflow (Instance Level Protected Runner)

Questions

Assuming this proposal is the solution we decide to move forward with in addressing the problem and requirements, then here are a few questions to consider:

Will Protected Runners be available to only protected branches?
Will a Protected Runner automatically be displayed in /settings/ci_cd page for all projects in a GitLab instance?
Should Protected Runners be associated in some way to Protected Environments?
Is the use of the term Protected Runner going to cause confusion given the fact that we already use this term in setting the Protected flag on a runner. https://docs.gitlab.com/ee/ci/runners/#prevent-runners-from-revealing-sensitive-information.
What is the solution for hybrid customers on GitLab SaaS?

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?