Access controls with cluster certificates (RBAC or ABAC) (DEPRECATED)

Version history
  • Restricted service account for deployment was introduced in GitLab 11.5.
  • Deprecated in GitLab 14.5.
caution
This feature was deprecated in GitLab 14.5. To connect your cluster to GitLab, use the GitLab Kubernetes Agent instead.

When creating a cluster in GitLab, you are asked if you would like to create either:

When GitLab creates the cluster, a gitlab service account with cluster-admin privileges is created in the default namespace to manage the newly created cluster.

Helm also creates additional service accounts and other resources for each installed application. Consult the documentation of the Helm charts for each application for details.

If you are adding an existing Kubernetes cluster, ensure the token of the account has administrator privileges for the cluster.

The resources created by GitLab differ depending on the type of cluster.

Important notes

Note the following about access controls:

  • Environment-specific resources are only created if your cluster is managed by GitLab.
  • If your cluster was created before GitLab 12.2, it uses a single namespace for all project environments.

RBAC cluster resources

GitLab creates the following resources for RBAC clusters.

Name Type Details Created when
gitlab ServiceAccount default namespace Creating a new cluster
gitlab-admin ClusterRoleBinding cluster-admin roleRef Creating a new cluster
gitlab-token Secret Token for gitlab ServiceAccount Creating a new cluster
Environment namespace Namespace Contains all environment-specific resources Deploying to a cluster
Environment namespace ServiceAccount Uses namespace of environment Deploying to a cluster
Environment namespace Secret Token for environment ServiceAccount Deploying to a cluster
Environment namespace RoleBinding admin roleRef Deploying to a cluster

The environment namespace RoleBinding was updated in GitLab 13.6 to admin roleRef. Previously, the edit roleRef was used.

ABAC cluster resources

GitLab creates the following resources for ABAC clusters.

Name Type Details Created when
gitlab ServiceAccount default namespace Creating a new cluster
gitlab-token Secret Token for gitlab ServiceAccount Creating a new cluster
Environment namespace Namespace Contains all environment-specific resources Deploying to a cluster
Environment namespace ServiceAccount Uses namespace of environment Deploying to a cluster
Environment namespace Secret Token for environment ServiceAccount Deploying to a cluster

Security of runners

Runners have the privileged mode enabled by default, which allows them to execute special commands and run Docker in Docker. This functionality is needed to run some of the Auto DevOps jobs. This implies the containers are running in privileged mode and you should, therefore, be aware of some important details.

The privileged flag gives all capabilities to the running container, which in turn can do almost everything that the host can do. Be aware of the inherent security risk associated with performing docker run operations on arbitrary images as they effectively have root access.

If you don’t want to use a runner in privileged mode, either:

  • Use shared runners on GitLab.com. They don’t have this security issue.
  • Set up your own runners that use docker+machine.