anchor.diff:  definition and the matching SCC's `runAsUser` is set to *MustRunAsRange*.
   - An SELinux label is required (`seLinuxContext` set to *MustRunAs*), which uses
   the project's default MCS label.
  +- `fsGroup` IDs are constrained to a single value due to the `FSGroup` strategy
  +being set to *MustRunAs*, which dictates that the value to use is the minimum
  +value of the first range specified.
  +- Because a range of allowable fsGroup IDs is not defined in the SCC, the
  +(minimum value of the) project's `openshift.io/sa.scc.supplemental-groups`
  +range (or as fallback, the same range used for user IDs) will be used for
  +validation and for a default ID, if needed.
  +- A default `fsGroup` ID is produced when a `fsGroup` ID is not specified in
  +the pod and the matching SCC's `FSGroup` is set to *MustRunAs*.
   - Arbitrary supplemental group IDs are allowed because no range checking is
  -required. This is a result of both the `supplementalGroups*` and `fsGroup`
  -strategies being set to *RunAsAny*.
  +required. This is a result of the `supplementalGroups` strategy being set to
  +*RunAsAny*.
   - Default supplemental groups are not produced for the running pod due to
   *RunAsAny* for the two group strategies above. Therefore, if no groups are
   defined in the pod definition (or in the image), the container(s) will have no
  
positive.code: matching SCC or project allows the group *5555*) will be members of the group
  *5555*, and will have access to the block volume, regardless of the container's
  user ID. If the pod matches the *restricted* SCC, whose `fsGroup` strategy is
  *RunAsAny*, then any `fsGroup` ID (including *5555*) will be accepted.
  However, if the SCC has its `fsGroup` strategy set to *MustRunAs*, and *5555*
  is not in the allowable range of `fsGroup` IDs, then the pod will fail to run.
  
  [[scc-fsgroup]]
  *fsGroups and Custom SCCs*
  
negative.code: by {product-title} to the container when those values are not supplied directly
  in the pod definition or image.
  
  Allowing access to SCCs with a *RunAsAny* `FSGroup` strategy may also have the
  unintended effect of preventing users from accessing their block devices. Pods
  need to specify an `fsGroup` in order to "take over" their block devices and
  this is normally taken care of when the SCC `FSGroup` strategy is set to
  *MustRunAs*. So if a user's pod is assigned an SCC with a *RunAsAny* `FSGroup`
  strategy, then the user may face "permission denied" errors until they discover
  that they need to specify an `fsGroup` themselves.
  
  SCCs may define the range of allowed IDs (user or groups). If range checking is
  required (for example, using *MustRunAs*) and the allowable range is not defined
  in the SCC, then the project determines the ID range. Therefore, projects
  