This is a cache of https://docs.openshift.com/enterprise/3.0/admin_guide/manage_scc.html. It is a snapshot of the page at 2024-11-25T04:43:57.856+0000.
Managing Security Context Constraints | Administration | OpenShift Enterprise 3.0
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history
×

Managing Security Context Constraints

Overview

Security context constraints allow administrators to control permissions for pods. To learn more about this API type please refer to the security context constraints (SCCs) architecture documentation. You may manage SCCs in your instance as normal API objects using the CLI.

You must have cluster-admin privileges to manage SCCs.

Listing Security Context Constraints

To get a current list of SCCs:

$ oc get scc
NAME         PRIV      CAPS      HOSTDIR   SELINUX     RUNASuser
privileged   true      []        true      RunAsAny    RunAsAny
restricted   false     []        false     MustRunAs   MustRunAsRange

Examining a Security Context Constraints Object

To examine a particular SCC, use oc get, oc describe, oc export, or oc edit.

$ oc edit scc restricted
allowHostDirVolumePlugin: false
allowHostNetwork: false
allowHostPorts: false
allowPrivilegedContainer: false
allowedCapabilities: null
apiVersion: v1
groups:
- system:authenticated
kind: SecurityContextConstraints
metadata:
  creationTimestamp: 2015-09-08T07:37:54Z
  name: restricted (1)
  resourceVersion: "58"
  selfxref: /api/v1/securitycontextconstraints/restricted
  uid: 849d9228-55fc-11e5-976b-080027c5bfa9
runAsuser:
  type: MustRunAsRange
seLinuxContext:
  type: MustRunAs
1 The SCC name specified in the oc edit command.

Creating New Security Context Constraints

To create a new SCC, first define the SCC in a JSON or YAML file:

Example 1. Security Context Constraint Object Definition
kind: SecurityContextConstraints
apiVersion: v1
metadata:
  name: scc-admin
allowPrivilegedContainer: true
runAsuser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
users:
- my-admin-user
groups:
- my-admin-group

Although this example definition was written by hand, another way is to modify the definition obtained from examining a particular SCC.

Then, run oc create passing the file to create it:

$ oc create -f scc_admin.yaml
securitycontextconstraints/scc-admin

$ oc get scc
NAME         PRIV      CAPS      HOSTDIR   SELINUX     RUNASuser
privileged   true      []        true      RunAsAny    RunAsAny
restricted   false     []        false     MustRunAs   MustRunAsRange
scc-admin    true      []        false     RunAsAny    RunAsAny

Deleting Security Context Constraints

To delete an SCC:

$ oc delete scc <scc_name>

If you delete the default SCCs, they will not be regenerated upon restart, unless you delete all SCCs. If any constraint already exists within the system, no regeneration will take place.

Updating Security Context Constraints

To update an existing SCC:

$ oc edit scc <scc_name>

Updating the default Security Context Constraints

If you would like to reset your security context constraints to the default settings for any reason you may delete the existing security context constraints and restart your master. The default security context constraints will only be recreated if no security context constraints exist in the system.

How Do I?

The following describe common scenarios and procedures using SCCs.

Grant Access to the Privileged SCC

In some cases, an administrator might want to allow users or groups outside the administrator group access to create more privileged pods. To do so, you can:

  1. Determine the user or group you would like to have access to the SCC.

  2. Run:

    $ oc edit scc <name>

  3. Add the user or group to the users or groups field of the SCC.

For example, to allow the e2e-user access to the privileged SCC, add their user:

$ oc edit scc privileged

allowHostDirVolumePlugin: true
allowPrivilegedContainer: true
apiVersion: v1
groups:
- system:cluster-admins
- system:nodes
kind: SecurityContextConstraints
metadata:
  creationTimestamp: 2015-06-15T20:44:53Z
  name: privileged
  resourceVersion: "58"
  selfxref: /api/v1/securitycontextconstraints/privileged
  uid: 602a0838-139f-11e5-8aa4-080027c5bfa9
runAsuser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
users:
- system:serviceaccount:openshift-infra:build-controller
- e2e-user (1)
1 The e2e-user added to the users section.

Grant a Service Account Access to the Privileged SCC

First, create a service account. For example, to create service account My_SVCACCT in project My_Project:

$ cat <<EOF | oc create -n My_Project -f -
kind: ServiceAccount
apiVersion: v1
metadata:
  name: My_SVCACCT (1)
EOF

Then, add the service account to the privileged SCC.

$ oc edit scc privileged

Add the following under users:

   - system:serviceaccount:My_Project:My_SVCACCT

Enable Images to Run with user in the Dockerfile

To relax the security in your cluster so that images are not forced to run as a pre-allocated UID, without granting everyone access to the privileged SCC:

  1. Edit the restricted SCC:

    $ oc edit scc restricted

  2. Change the runAsuser.Type strategy to RunAsAny.

This allows images to run as the root UID if no user is specified in the Dockerfile.

Use --mount-host on the Registry

It is recommended that persistent storage using PersistentVolume and PersistentVolumeClaim objects be used for registry deployments. If you are testing and would like to instead use the oadm registry command with the --mount-host option, you must first create a new service account for the registry and add it to the privileged SCC. See the Administrator Guide for full instructions.

Provide Additional Capabilities

In some cases, an image may require capabilities that Docker does not provide out of the box. You can provide the ability to request additional capabilities in the pod specification which will be validated against an SCC.

This allows images to run with elevated capabilities and should be used only if necessary. You should not edit the default restricted SCC to enable additional capabilities.

When used in conjunction with a non-root user, you must also ensure that the file that requires the additional capability is granted the capabilities using the setcap command. For example, in the Dockerfile of the image:

setcap cap_net_raw,cap_net_admin+p /usr/bin/ping

Further, if a capability is provided by default in Docker, you do not need to modify the pod specification to request it. For example, NET_RAW is provided by default and capabilities should already be set on ping, therefore no special steps should be required to run ping.

To provide additional capabilities:

  1. Create a new SCC or edit the privileged SCC:

    $ oc edit scc <name>

  2. Add the allowed capability using the allowedCapabilities field.

  3. When creating the pod, request the capability in the securityContext.capabilities.add field.

Modify Cluster Default Behavior

To modify your cluster so that it does not pre-allocate UIDs, allows containers to run as any user, and prevents privileged containers:

  1. Edit the restricted SCC:

     $ oc edit scc restricted

  2. Change runAsuser.Type to RunAsAny.

  3. Ensure allowPrivilegedContainer is set to false.

  4. Save the changes.

To modify your cluster so that it does not pre-allocate UIDs and does not allow containers to run as root:

  1. Edit the restricted SCC:

     $ oc edit scc restricted

  2. Change runAsuser.Type to MustRunAsNonRoot.

  3. Save the changes.

Use the hostPath Volume Plug-in

To relax the security in your cluster so that pods are allowed to use the hostPath volume plug-in without granting everyone access to the privileged SCC:

  1. Edit the restricted SCC:

    $ oc edit scc restricted

  2. Add allowHostDirVolumePlugin: true.

  3. Save the changes.