anchor.diff:  
   Supplemental groups are regular Linux groups. When a process runs in Linux, it
   has a UID, a GID, and one or more supplemental groups. These attributes can be
  -set for a container's main process. The `*supplementalGroups*` IDs are typically
  +set for a container's main process. The `supplementalGroups` IDs are typically
   used for controlling access to shared storage, such as NFS and GlusterFS,
   whereas xref:fsgroup[fsGroup] is used for controlling access to block storage,
   such as Ceph RBD and iSCSI.
  
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: [TIP]
  ====
  It is generally preferable to use group IDs
  (xref:supplemental-groups[supplemental] or `fsGroup`) to gain access to
  persistent storage versus using xref:user-id[user IDs].
  ====
  
  `fsGroup` defines a pod's "file system group" ID, which is added to the
  container's supplemental groups. The `supplementalGroups` ID applies to shared
  storage, whereas the `fsGroup` ID is used for block storage.
  
  Block storage, such as Ceph RBD, iSCSI, and various cloud storage, is typically
  dedicated to a single pod which has requested the block storage volume, either
  