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

NameTypeDetailsCreated when
gitlabServiceAccount default namespaceCreating a new cluster
gitlab-adminClusterRoleBinding cluster-admin roleCreating a new cluster
gitlab-tokenSecretToken for gitlab ServiceAccountCreating a new cluster
Environment namespaceNamespaceContains all environment-specific resourcesDeploying to a cluster
Environment namespaceServiceAccountUses namespace of environmentDeploying to a cluster
Environment namespaceSecretToken for environment ServiceAccountDeploying to a cluster
Environment namespaceRoleBinding admin roleDeploying to a cluster

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

ABAC cluster resources

GitLab creates the following resources for ABAC clusters.

NameTypeDetailsCreated when
gitlabServiceAccount default namespaceCreating a new cluster
gitlab-tokenSecretToken for gitlab ServiceAccountCreating a new cluster
Environment namespaceNamespaceContains all environment-specific resourcesDeploying to a cluster
Environment namespaceServiceAccountUses namespace of environmentDeploying to a cluster
Environment namespaceSecretToken for environment ServiceAccountDeploying 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.