update AllowHostUsers field to be HostUsers

Signed-off-by: Peter Hunt <pehunt@redhat.com>

enhancements/kubelet/user-namespaces-support.md

@@ -64,16 +64,16 @@ within an Openshift pod without being in a privileged namespace.
 
 There are two pieces to this proposal:
 - Extend SCC to be aware of the hostUsers field:
-    - Add a new field AllowHostUser to SCC, which will be Allowed by default
+    - Add a new field HostUsers to SCC, which will be Allowed by default
     - Add a new SCC to the default list: restricted-v3
-        - This SCC will be identical to restricted-v2, but have AllowHostUsers set to Disallowed
+        - This SCC will be identical to restricted-v2, but have HostUsers set to Disallowed
     - Add a new SCC to the default list: nonroot-v3
-        - This SCC will be identical to nonroot-v2, but have AllowHostUsers set to Disallowed
+        - This SCC will be identical to nonroot-v2, but have HostUsers set to Disallowed
     - Add a new SCC to the default list: nested-container. It will have:
         - SELinux context set to MustRunAs.Type: container_engine_t
         - RunAsUserStrategy: RunAsAny
         - RequiredDropCapabilities: None
-        - AllowHostUser: Disallowed
+        - HostUsers: Disallowed
         - And otherwise mirror the restricted-v2 profile
 - Add the features UserNamespacesPodSecurityStandards and ProcMountType to the list that qualify a cluster as TechPreviewNoUpgrade
     - UserNamespacesSupport will be on by default, as the feature is beta in 1.30.
@@ -84,7 +84,7 @@ N/A
 
 ### API Extensions
 
-- Add AllowHostUser to SCC. This relies on approval from the apiserver team.
+- Add HostUsers to SCC. This relies on approval from the apiserver team.
 
 ### Topology Considerations
 
@@ -104,24 +104,24 @@ N/A
 
 #### SecurityContextConstraint Updates
 
-##### `AllowHostUsers` field
+##### `HostUsers` field
 
 Add the following to the [Openshift API](https://github.com/openshift/api/blob/76a71dac36a08eab1b240c6c8d4e39c813b1b12b/security/v1/types.go):
 
 ```
-       // allowHostUsers determines if the policy allows host users in containers.
+       // hostUsers determines if the policy allows host users in containers.
        // Valid values are "Allowed", "Disallowed" and omitted.
        // When omitted, this means no opinion and the platform is left to choose a reasonable default.
        // The current default is "Allowed".
        // +openshift:enable:FeatureGate=UserNamespacesPodSecurityPolicy
        // +kubebuilder:validation:Enum="Allowed";"Disallowed";""
        // +kubebuilder:validation:Optional
-       AllowHostUsers HostUsersStrategyType `json:"allowHostUsers" protobuf:"bytes,26,opt,name=allowHostUsers"`
+       HostUsers HostUsersStrategyType `json:"hostUsers" protobuf:"bytes,26,opt,name=hostUsers"`
 ...
-// AllowHostUsersStrategyType shows the allowable values for AllowHostUsers
+// HostUsers shows the allowable values for HostUsers
 // While it's an enum, it's practically a boolean, as it is mirroring the other AllowHost*
 // fields, while maintaining current API conventions.
-type AllowHostUsersStrategyType string
+type HostUsersStrategyType string
 ...
 const (
        // HostUsersStrategyAllowed allows the use of HostUsers in a pod.
@@ -141,7 +141,7 @@ This is to follow current API conventions, which maintain boolean fields are not
 
 ##### restricted-v3
 
-This SCC profile will be identical to the existing restricted-v2, except it will set the `AllowHostUser` to `Disallowed`,
+This SCC profile will be identical to the existing restricted-v2, except it will set the `HostUser` to `Disallowed`,
 thus forcing pods to be in a user namespace. This will make it a more restrictive profile, as the user on the host will not be
 the same as the one inside the container.
 
@@ -150,7 +150,7 @@ of SCC utilizes defense-in-depth. `restricted-v3` will be the most restrictive p
 
 ##### nonroot-v3
 
-This SCC profile will be identical to `nonroot-v2`, except it will set `AllowHostUser` to `Disallowed`, thus forcing pods to be in a
+This SCC profile will be identical to `nonroot-v2`, except it will set `HostUser` to `Disallowed`, thus forcing pods to be in a
 user namespace. It differs from `restricted-v3` because it allows the fields `runAsUser`/`runAsGroup`/`fsGroup`.
 
 Note: a user can actually request `runAsUser: 0` in this profile, despite its name being `nonroot`. This is because root inside
@@ -171,7 +171,7 @@ This SCC will largely mirror the `restricted-v2` SCC, but have a couple of chang
 - RequiredDropCapabilities: None
     - Inside of a user namespace, the capabilities a pod requests are only present in the user namespace,
       not on the host. Thus, even for a less trusted user, the capabilities should be safe to access.
-- AllowHostUser set to Disallowed
+- HostUser set to Disallowed
 
 Note: to use this SCC, the namespace must be labeled as `privileged` in Pod Security Standards. This is in part because
 PSS doesn't recognized `container_engine_t` [in 1.30](https://github.com/kubernetes/kubernetes/pull/126165), and in part because