Support environment deployment tiers in GitLab agent

Release notes

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.

Until now, users could not restrict CI access to specific environment tiers, 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

# .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 #327410 for the tracking of that feature

Proposal

Dynamic environments can share a deployment tier. 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:

   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

2. 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:

   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

Feature Usage Metrics

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.