5.7 KiB
| stage | group | info |
|---|---|---|
| Configure | Configure | To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments |
Access controls with cluster certificates (RBAC or ABAC) (deprecated) (FREE)
- Restricted service account for deployment was introduced in GitLab 11.5.
- Deprecated in GitLab 14.5.
WARNING: 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:
- 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 |
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.
| 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.