<!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> The agent for Kubernetes allows both pull- and push-based deployment support. Push-based support is provided through its GitLab CI/CD integration, called the CI/CD workflow. The integration allows [restricting the potential of CI jobs using Kubernetes RBAC](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html#impersonate-the-cicd-job-that-accesses-the-cluster). Until now, users could not restrict CI access to specific [environment tiers](https://docs.gitlab.com/ee/ci/environments/#deployment-tier-of-environments), increasing the security risks of the integration. The current release expands the `groups` the impersonated CI job account belongs to with environment-tier specific information. Kubernetes admins can target these groups with RBAC for improved control of CI access to clusters. ### Problem to solve When using job impersonation (`ci_access.access_as.ci_job`) in the CI/CD workflow for the GitLab agent, the impersonated user will have the group `gitlab:project_env:$project_id:$environment_slug`, which can be used in RBAC. The problem is that `$environment_slug` must be known ahead of time to use it in RBAC manifests, so we cannot use it for dynamically created environments, such as ```yaml # .gitlab-ci.yml review: stage: deploy environment: name: review/$CI_COMMIT_REF_SLUG action: start # ... ``` This is especially a problem when `staging` and `review/*` deploy to the same cluster. In this case, it is not currently possible to express the following in RBAC for `ci_access.access_as.ci_job` impersonation and a single agent: 1. the GitLab environment `staging` can only deploy to the namespace `staging` 2. the GitLab environments `review/*` can only deploy to the namespace `review` With a single agent, we could get pretty close with `ci_access.access_as.ci_user` and say (in RBAC): 1. only maintainers and above can deploy to the namespace `staging` 2. only developers and above can deploy to the namespace `review` but `ci_access.access_as.ci_user` has not been implemented (at the time of writing). See https://gitlab.com/gitlab-org/gitlab/-/issues/327410 for the tracking of that feature ### Proposal Dynamic environments can share a [**deployment tier**](https://docs.gitlab.com/ee/ci/environments/#deployment-tier-of-environments). This proposal is to: 1. Add an impersonation group of `gitlab:project_env_tier:<project-id>:<environment-deployment-tier>` 2. Add impersonation groups of `gitlab:group_env_tier:<group-id>:<environment-deployment-tier>` for each group the project belongs to. This would allow: 1. Granting `admin` access in the `review` namespace to all deployments to the `development` tier in project `12345` using the following role binding: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: gitlab:project_env_tier:12345:development:admin namespace: review subjects: - kind: Group name: gitlab:project_env_tier:12345:development apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: admin apiGroup: rbac.authorization.k8s.io ``` 1. Granting `admin` access in the `review` namespace to all deployments to the `development` tier in an entire group (ID `54321`) using the following role binding: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: gitlab:group_env_tier:54321:development:admin namespace: review subjects: - kind: Group name: gitlab:group_env_tier:54321:development apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: admin apiGroup: rbac.authorization.k8s.io ``` ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test) * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) * [Ingrid (Infrastructure Operator)](https://about.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator) * [Dakota (Application Development Director)](https://about.gitlab.com/handbook/product/personas/#dakota-application-development-director) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) * [Eddie (Content Editor)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#eddie-content-editor) --> ### Feature Usage Metrics <!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it? Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md --> <!-- Label reminders Use the following resources to find the appropriate labels: - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ --> <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->