anchor.diff:  <3> Numerically larger numbers have greater priority. Nil or omitted is the lowest
   priority. Higher priority SCCs sort before lower priority SCCs, and thus have a
   better chance of matching a new pod.
  -<4> The `*runAsUser*` strategy is set to *MustRunAsRange*, which means UID range
  +<4> The `runAsUser` strategy is set to *MustRunAsRange*, which means UID range
   checking is enforced.
   <5> The UID range is 1000100001 through 1000100001 (a range of one value).
  -====
  -
  -Now, with `*runAsUser: 1000100001*` shown in the previous pod definition fragment,
  +
  +Now, with `runAsUser: 1000100001` shown in the previous pod definition fragment,
   the pod matches the new *nfs-scc* and is able to run with a UID of 1000100001.
   
   [[selinuxoptions]]
   == SELinux Options
   
  -All predefined SCCs, except for the *privileged* SCC, set the `*seLinuxContext*`
  +All predefined SCCs, except for the *privileged* SCC, set the `seLinuxContext`
   to *MustRunAs*. So the SCCs most likely to match a pod's requirements will force
   the pod to use an SELinux policy. The SELinux policy used by the pod can be
   defined in the pod itself, in the image, in the SCC, or in the project (which
   provides the default).
   
  -SELinux labels can be defined in a pod's `*securityContext.seLinuxOptions*`
  -section, and supports `*user*`, `*role*`, `*type*`, and `*level*`:
  +SELinux labels can be defined in a pod's `securityContext.seLinuxOptions`
  +section, and supports `user`, `role`, `type`, and `level`:
   
   [NOTE]
   ====
   Level and MCS label are used interchangeably in this topic.
   ====
   
  -====
   ----
   ...
    securityContext: <1>
  
positive.code: because:
  
  - it requests *1000100001* as its user ID,
  - all available SCCs use *MustRunAsRange* for their `*runAsUser*` strategy, so UID
  range checking is required, and
  - *1000100001* is not included in the SCC or in the project's user ID range.
  
  To remedy this situation, a new SCC can be created 
  with the appropriate user ID range. A new project could also be created with the
  appropriate user ID range defined. There are also other, less-preferred options:
  
  - The *restricted* SCC could be modified to include *1000100001* within its minimum and
  maximum user ID range. This is not recommended as you should avoid modifying the
  predefined SCCs if possible.
  - The *restricted* SCC could be modified to use *RunAsAny* for the `*runAsUser*`
  value, thus eliminating ID range checking. This is *_strongly_* not recommended, as
  containers could run as root.
  - The *default* project's UID range could be changed to allow a user ID of
  *1000100001*. This is not generally advisable because only a single range of user IDs
  
negative.code:       level: "s0:c123,c456" <2>
  ...
  ----
  <1> `level` can be defined globally for the entire pod, or individually for each
  container.
  <2> SELinux level label.
  
  
  Here are fragments from an SCC and from the *default* project:
  
  
  ----
  $ oc export scc scc-name
  ...
  