anchor.diff:  - my-admin-user
   groups:
   - my-admin-group
  -
  +----
  +====
  +
  +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]]
   
   == 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.
  +To delete an SCC:
  +
  +----
  +$ oc delete scc <scc_name>
  +----
  +
  +[NOTE]
  +====
  +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]]
   
   == Updating Security Context Constraints
   
  -[options="nowrap"]
  -----
  -$ oc edit scc privileged
  +To update an existing SCC:
  +
  +----
  +$ oc edit scc <scc_name>
   ----
   
   [[how-do-i]]
   
   == How Do I?
  +
  +The following describe common scenarios and procedures using SCCs.
   
   [[grant-access-to-the-privileged-scc]]
   
  
positive.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, you
  can edit the restricted SCC and change the `*runAsUser*` strategy:
  
  . Run:
  +
  ----
  $ oc edit scc restricted
  ----
  
  . Change `*runAsUser.Type*` 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 registry deployments. If
  you are testing and would like to use the `--mount-host` option, the recommended
  way to do so is:
  
  . Create a new 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:<namesapce>:<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.  In
  this case you may provide the ability to request additional capabilities in the pod spec 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.
  ====
  
  NOTE: 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 via the `*setcap*` command.  For
  example `*setcap cap_net_raw,cap_net_admin+p /usr/bin/ping*`.
  
  NOTE: If a capability is provided by default in Docker you do not need to modify the pod spec
  to request it.  For example `*NET_RAW*` is provided by default and capabilities should already be
  set on `*ping*`, no special steps should be required to run `*ping*`.
  
  . 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
  
  === Create a Cluster That...
  
  .  Does not pre-allocate UIDs, allows containers to run as any user, and prevents privileged containers
  +
   ----
   $ oc edit scc restricted
   ----
   Change runAsUser.Type to RunAsAny.
   Ensure allowPrivilegedContainer is set to false.
  
  .  Does not pre-allocated UIDs and does not allow containers to run as root
  +
   ----
   $ oc edit scc restricted
   ----
   Change runAsUser.Type to MustRunAsNonRoot.
  
  
  
negative.code: 
  . 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:
  
  ====
  