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

{{< details >}}

• Tier: Free, Premium, Ultimate
• Offering: GitLab.com, GitLab Self-Managed

{{< /details >}}

[!warning] This feature was deprecated in GitLab 14.5. To connect your cluster to GitLab, use the GitLab agent for Kubernetes instead.

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

• A Role-based access control (RBAC) cluster, which is the GitLab default and recommended option.
• An Attribute-based access control (ABAC) cluster.

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 role	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 role	Deploying to a cluster

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 instance runners on GitLab.com. They don't have this security issue.
• Set up your own runners that use docker+machine.