Security context constraints

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

Overview

Pods in OpenShift receive permissions based on their security context constraints. Security context constraints, often abbreviated SCC, simplify the role based access control mechanism for use in large scale deployments. Administrators may consult the upstream documentation to gain more insight into how security context constraints work and their place in OpenShift

Administrators may also consult the following resources:

  1. Managing Security Context Constraints in OpenShift
  2. A Guide to OpenShift and UIDs

Security context constraints within the GitLab deployment

The gitlab-controller-manager deployment creates and manages the pod containing the Operator processes. This and any other pod it creates and manages run with the restricted security context constraint.

The Operator uses a ServiceAccount with robust permissions allowing it to manage all resources required by the GitLab application.

The Operator manages the component services comprising Cloud Native GitLab. It actively terminates and replaces pods that do not conform to the UID specified by the Operator. This mechanism enforces the principle of least privilege.

GitLab application custom resource definitions

Pods deployed by the Operator to satisfy GitLab custom resources use the non-root-v2 security context constraint. Security context constraints for third party operators and resources are covered in the next section.

The gitlab-app-nonroot ServiceAccounts has no granted privileges and exists solely to bind the nonroot-v2 security context constraints to GitLab application pods.

The security context constraints will be tightened in future releases as the full read/write behaviors of the GitLab application are validated within the OpenShift security model.

Administrators coming to Cloud Native GitLab from a Linux package installation should note that Linux package installation tasks performed with sudo are handled by OpenShift and the underlying Kubernetes engine. Pods are individual services which, in a Linux package installation, drop privilege to run as an application-specific user. The Operator will terminate any pod that is not operating with the expected UID.

Third party resource definitions

Ingress controller

GitLab recommends and tests deployments using the nginx-ingress-controller when deploying Cloud Native GitLab. It uses its own nginx-ingress-scc security context constraint.

If selecting an alternative Ingress controller, please consult the relevant documentation to learn more about its security context constraints.

SSL encryption

GitLab Operator requires cert-manager to be installed separately as a prerequisite. GitLab Operator configures cert-manager Issuers and Certificates to manage TLS across the GitLab application. cert-manager sets no security context constraints directly, therefore OpenShift will apply the restricted security context constraint by default.