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: by {product-title} to the container when those values are not supplied directly
  in the pod definition or image.
  
  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
  
negative.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
  *MustRunAs*, then the pod will fail to run. However, if the SCC has its
  `fsGroup` strategy set to *RunAsAny*, then any `fsGroup` ID (including *5555*)
  will be accepted. Note that if the SCC has its `fsGroup` strategy set to
  *RunAsAny* and no `fsGroup` ID is specified, the "taking over" of the block
  storage does not occur and permissions may be denied to the pod.
  
  [[scc-fsgroup]]
  *fsGroups and Custom SCCs*
  