anchor.diff:  
   [NOTE]
   ====
  -Setting `privileged: true` in the pod specification does not select the `privileged` SCC. Setting `privileged: true` in the pod specification matches on the `allowPrivilegedContainer` field of an SCC.
  +Setting `privileged: true` in the pod specification does not necessarily select the `privileged` SCC. The SCC that has `allowPrivilegedContainer: true` and has the highest prioritization will be chosen if the user has the permissions to use it.
   ====
   endif::[]
   
   |`restricted`
  -|Denies access to all host features and requires pods to be run with a UID, and SELinux context that are allocated to the namespace.  This is the most restrictive SCC and it is used by default for authenticated users.
  +|Denies access to all host features and requires pods to be run with a UID, and SELinux context that are allocated to the namespace. This is the most restrictive SCC provided by a new installation and will be used by default for authenticated users.
   
   The `restricted` SCC:
   
  
positive.code: 
  Security context constraints allow an administrator to control:
  
  * Whether a pod can run privileged containers
  * The capabilities that a container can request
  * The use of host directories as volumes
  * The SELinux context of the container
  
negative.code: 
  [NOTE]
  ====
  You can drop all capabilites from containers by setting the `requiredDropCapabilities` parameter to `ALL`.
  ====
  
  [id="authorization-SCC-strategies_{context}"]
  