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:
- the GitLab environment
staging
can only deploy to the namespacestaging
- the GitLab environments
review/*
can only deploy to the namespacereview
With a single agent, we could get pretty close with ci_access.access_as.ci_user
and say (in RBAC):
- only maintainers and above can deploy to the namespace
staging
- 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:
- Add an impersonation group of
gitlab:project_env_tier:<project-id>:<environment-deployment-tier>
- Add impersonation groups of
gitlab:group_env_tier:<group-id>:<environment-deployment-tier>
for each group the project belongs to.
This would allow:
-
Granting
admin
access in thereview
namespace to all deployments to thedevelopment
tier in project12345
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
-
Granting
admin
access in thereview
namespace to all deployments to thedevelopment
tier in an entire group (ID54321
) 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.