Skip to content

Latest commit

 

History

History
158 lines (130 loc) · 7.07 KB

04-scc.adoc

File metadata and controls

158 lines (130 loc) · 7.07 KB
Raw

Security Context Constraint (SCCs)

Red Hat OpenShift provides security context constraints (SCCs), a security mechanism that restricts access to resources, but not to operations in OpenShift.

SCCs limit the access from a running pod in OpenShift to the host environment. SCCs control:

  • Running privileged containers.

  • Requesting extra capabilities for a container

  • Using host directories as volumes.

  • Changing the SELinux context of a container.

  • Changing the user ID.

Some containers developed by the community might require relaxed security context constraints to access resources that are forbidden by default, such as file systems, sockets, or to access a SELinux context.

You can run the following command as a cluster administrator to list the SCCs defined by OpenShift:

oc get scc
NAME                              PRIV    CAPS         SELINUX     RUNASUSER          FSGROUP     SUPGROUP    PRIORITY     READONLYROOTFS   VOLUMES
anyuid                            false   <no value>   MustRunAs   RunAsAny           RunAsAny    RunAsAny    10           false            ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
hostaccess                        false   <no value>   MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <no value>   false            ["configMap","downwardAPI","emptyDir","hostPath","persistentVolumeClaim","projected","secret"]
hostmount-anyuid                  false   <no value>   MustRunAs   RunAsAny           RunAsAny    RunAsAny    <no value>   false            ["configMap","downwardAPI","emptyDir","hostPath","nfs","persistentVolumeClaim","projected","secret"]
hostnetwork                       false   <no value>   MustRunAs   MustRunAsRange     MustRunAs   MustRunAs   <no value>   false            ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
machine-api-termination-handler   false   <no value>   MustRunAs   RunAsAny           MustRunAs   MustRunAs   <no value>   false            ["downwardAPI","hostPath"]
node-exporter                     true    <no value>   RunAsAny    RunAsAny           RunAsAny    RunAsAny    <no value>   false            ["*"]
nonroot                           false   <no value>   MustRunAs   MustRunAsNonRoot   RunAsAny    RunAsAny    <no value>   false            ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
privileged                        true    ["*"]        RunAsAny    RunAsAny           RunAsAny    RunAsAny    <no value>   false            ["*"]
restricted                        false   <no value>   MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <no value>   false            ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]

  1. Log in to the cluster as the developer user.

oc login -u developer -p developer

  1. Create the authorization-scc project.

oc new-project authorization-scc

  1. Deploy an application named gitlab using the container image located at quay.io/redhattraining/gitlab-ce:8.4.3-ce.0. This image is a copy of the container image available at docker.io/gitlab/gitlab-ce:8.4.3-ce.0. Verify that the pod fails because the container image needs root privileges.

    1. Deploy the gitlab application.

oc new-app --name gitlab --image quay.io/redhattraining/gitlab-ce:8.4.3-ce.0

  1. Determine if the application is successfully deployed. It should give an error because this image needs root privileges to properly deploy.

oc get pods -w
NAME
gitlab-6d7895868d-mnr9r   0/1     Error     4 (57s ago)   2m31s

  1. Review the application logs to confirm that the failure is caused by insufficient privileges.

oc logs pod/gitlab-7d67db7875-gcsjl -f
...output omitted...
================================================================================
Recipe Compile Error in /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/default.rb
================================================================================

Chef::Exceptions::InsufficientPermissions
-----------------------------------------
directory[/etc/gitlab] (gitlab::default line 26) had an error: Chef::Exceptions::InsufficientPermissions: Cannot create directory[/etc/gitlab] at /etc/gitlab due to insufficient permissions
...output omitted...

  1. Log in as the admin user.

oc login -u admin -p redhat

  1. Check if using a different SCC can resolve the permissions problem.

oc get pod/gitlab-6d7895868d-mnr9r -o yaml | oc adm policy scc-subject-review -f -
RESOURCE                      ALLOWED BY
Pod/gitlab-6d7895868d-mnr9r   anyuid

  1. Create a new service account and assign the anyuid SCC to it.

    1. Create a service account named gitlab-sa.

oc create sa gitlab-sa
serviceaccount/gitlab-sa created

  1. Assign the anyuid SCC to the gitlab-sa service account.

oc adm policy add-scc-to-user anyuid -z gitlab-sa
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "gitlab-sa"

  1. Modify the gitlab application so that it uses the newly created service account. Verify that the new deployment succeeds.

    1. Log in as the developer user.

oc login -u developer -p developer

  1. Assign the gitlab-sa service account to the gitlab deployment.

oc set serviceaccount deployment/gitlab gitlab-sa
deployment.apps/gitlab serviceaccount updated

  1. Verify that the gitlab redeployment succeeds. You might need to run the oc get pods command multiple times until you see a running application pod.

oc get pods -w
NAME                   READY   STATUS    RESTARTS   AGE
gitlab-86d6d65-zm2fd   1/1     Running   0          55s

  1. Verify that the gitlab application works properly.

    1. Expose the gitlab application. Because the gitlab service listens on ports 22, 80, and 443, you must use the --port option.

oc expose service/gitlab --port 80

  1. Get the exposed route.

oc get route
NAME     HOST/PORT                                                           PATH   SERVICES   PORT   TERMINATION   WILDCARD
gitlab   gitlab-authorization-scc.apps.cluster-754d.sandbox478.opentlc.com          gitlab     80                   None

  1. Verify that the gitlab application is answering HTTP queries.

curl -s gitlab-authorization-scc.apps.cluster-754d.sandbox478.opentlc.com
<html><body>You are being <a href="http://gitlab-authorization-scc.apps.cluster-754d.sandbox478.opentlc.com/users/sign_in">redirected</a>.</body></html>

Clean-up

oc delete project authorization-scc