Security context constraints


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 anyuid security context constraint. Security context constraints for third party operators and resources are covered in the next section.

The gitlab-app-anyuid and gitlab-app-nonroot ServiceAccounts have no granted privileges. They exists solely to bind the anyuid and nonroot 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

Operator deploys the cert-manager-operator from JetStack to manage SSL certificates across the GitLab application. The cert-manager-operator sets no secure context constraints directly, thus OpenShift will apply the restricted security context constraint by default.