anchor.diff:  
   == Overview
   You can manage
  -link:../architecture/additional_concepts/authorization.html#security-context-constraints[security context constraints]
  -in your instance via the `oc` command as a normal API objects.
  +link:../architecture/additional_concepts/authorization.html#security-context-constraints[security
  +context constraints] (SCCs) in your instance as normal API
  +link:../architecture/core_concepts/overview.html[objects] using
  +link:../cli_reference/overview.html[the CLI].
  +
  +[NOTE]
  +====
  +You must have
  +link:../architecture/additional_concepts/authorization.html#roles[*cluster-admin*
  +privileges] to manage SCCs.
  +====
   
   [[listing-security-context-constraints]]
   
   == Listing Security Context Constraints
   
  -[options="nowrap"]
  +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
   ----
  +====
   
   [[creating-new-security-context-constraints]]
   
   == Creating New Security Context Constraints
   
  -Creating a new SCC is accomplished with the `oc create` command.  First, define the SCC in a json
  -or yaml file and then run `oc create` passing the file.
  -
  -[options="nowrap"]
  +To create a new SCC, first define the SCC in a JSON or YAML file:
  +
  +.Security Context Constraint Object Definition
  +====
   ----
   kind: SecurityContextConstraints
   apiVersion: v1
  
positive.code: - my-admin-user
  groups:
  - my-admin-group
  
  $ 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]]
  
  == Deleting Security Context Constraints
  
  [options="nowrap"]
  ----
  $ oc delete scc scc-admin
  securitycontextconstraints/scc-admin
  ----
  
  NOTE: If you delete the default security context constraints they will not be regenerated upon
  restart unless you delete all security context constraints.  If any constraint already exists
  within the system, no generation will take place.
  
  [[updating-security-context-constraints]]
  
  == Updating Security Context Constraints
  
  [options="nowrap"]
  ----
  $ oc edit scc privileged
  ----
  
  [[how-do-i]]
  
  == How Do I?
  
  [[grant-access-to-the-privileged-scc]]
  
  
negative.code: === 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:
  
  . Edit the *restricted* SCC:
  +
  ----
  $ oc edit scc restricted
  ----
  
  . Change the `*runAsUser.Type*` strategy to *RunAsAny*.
  
  [IMPORTANT]
  ====
  This allows images to run as the root UID if no *USER* is specified in the
  *_Dockerfile_*.
  ====
  
  [[use-mount-host-on-the-registry]]
  
  === Use --mount-host on the Registry
  
  It is recommended that persistent volumes be used for
  link:install/docker_registry.html[registry deployments]. If you are testing and
  would like to use the `oadm registry` command with the `--mount-host` option,
  the recommended way to do so is:
  
  . Create a new link:service_accounts.html[service account].
  . Add the service account user name to the *privileged* SCC using:
  +
  ----
  $ oc edit scc privileged
  ----
  +
  Note that a fully-qualified service account user name is in the form of
  *system:serviceaccount:<namespace>:<name>*.
  
  . Create the registry using:
  +
  ----
  $ oadm registry --service-account=<name> --mount-host=<dir> ...
  ----
  
  === 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.
  
  [IMPORTANT]
  ====
  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:
  
  . Create a new SCC or edit the *privileged* SCC:
  +
  ----
  $ oc edit scc <name>
  ----
  
  . Add the allowed capability using the `*allowedCapabilities*` field.
  
  . When creating the pod, request the capability in the
  `*securityContext.capabilities.add*` field.
  
  [[modify-cluster-default-behavior]]
  
  === 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:
  
  . Edit the *restricted* SCC:
  +
  ----
   $ oc edit scc restricted
  ----
  
  . Change `*runAsUser.Type*` to *RunAsAny*.
  
  . Ensure `*allowPrivilegedContainer*` is set to false.
  
  . Save the changes.
  
  To modify your cluster so that it does not pre-allocate UIDs and does not allow
  containers to run as root:
  
  . Edit the *restricted* SCC:
  +
  ----
   $ oc edit scc restricted
  ----
  
  . Change `*runAsUser.Type*` to *MustRunAsNonRoot*.
  
  . Save the changes.
  