Resource name constraints (5) (#19122)

xref: #17969, #19099, #18746

content/en/docs/concepts/configuration/pod-priority-preemption.md

@@ -117,6 +117,9 @@ priority class name to the integer value of the priority. The name is specified
 in the `name` field of the PriorityClass object's metadata. The value is
 specified in the required `value` field. The higher the value, the higher the
 priority.
+The name of a PriorityClass object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names),
+and it cannot be prefixed with `system-`.
 
 A PriorityClass object can have any 32-bit integer value smaller than or equal
 to 1 billion. Larger numbers are reserved for critical system Pods that should

content/en/docs/concepts/containers/runtime-class.md

@@ -82,6 +82,9 @@ metadata:
 handler: myconfiguration  # The name of the corresponding CRI configuration
 ```
 
+The name of a RuntimeClass object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
 {{< note >}}
 It is recommended that RuntimeClass write operations (create/update/patch/delete) be
 restricted to the cluster administrator. This is typically the default. See [Authorization

content/en/docs/concepts/policy/pod-security-policy.md

@@ -197,6 +197,8 @@ alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n
 
 Define the example PodSecurityPolicy object in a file. This is a policy that
 simply prevents the creation of privileged pods.
+The name of a PodSecurityPolicy object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 {{< codenew file="policy/example-psp.yaml" >}}
 

content/en/docs/concepts/storage/dynamic-provisioning.md

@@ -46,6 +46,9 @@ To enable dynamic provisioning, a cluster administrator needs to pre-create
 one or more StorageClass objects for users.
 StorageClass objects define which provisioner should be used and what parameters
 should be passed to that provisioner when dynamic provisioning is invoked.
+The name of a StorageClass object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
 The following manifest creates a storage class "slow" which provisions standard
 disk-like persistent disks.
 

content/en/docs/reference/access-authn-authz/rbac.md

@@ -74,6 +74,9 @@ rules:
   verbs: ["get", "watch", "list"]
 ```
 
+The name of a Role or a ClusterRole object must be a valid
+[path segment name](/docs/concepts/overview/working-with-objects/names#path-segment-names).
+
 ### RoleBinding and ClusterRoleBinding
 
 A role binding grants the permissions defined in a role to a user or set of users.
@@ -81,6 +84,9 @@ It holds a list of subjects (users, groups, or service accounts), and a referenc
 Permissions can be granted within a namespace with a `RoleBinding`, or cluster-wide with a `ClusterRoleBinding`.
 
 A `RoleBinding` may reference a `Role` in the same namespace.
+The name of a `RoleBinding` object must be a valid
+[path segment name](/docs/concepts/overview/working-with-objects/names#path-segment-names).
+
 The following `RoleBinding` grants the "pod-reader" role to the user "jane" within the "default" namespace.
 This allows "jane" to read pods in the "default" namespace.
 
@@ -129,8 +135,10 @@ roleRef:
   apiGroup: rbac.authorization.k8s.io
 ```
 
-Finally, a `ClusterRoleBinding` may be used to grant permission at the cluster level and in all
-namespaces. The following `ClusterRoleBinding` allows any user in the group "manager" to read 
+Finally, a `ClusterRoleBinding` may be used to grant permission at the cluster level and in all namespaces.
+ The name of a `ClusterRoleBinding` object must be a valid
+[path segment name](/docs/concepts/overview/working-with-objects/names#path-segment-names).
+The following `ClusterRoleBinding` allows any user in the group "manager" to read
 secrets in any namespace.
 
 ```yaml

content/en/docs/tasks/inject-data-application/podpreset.md

@@ -29,6 +29,9 @@ Here is the manifest for the PodPreset:
 
 {{< codenew file="podpreset/preset.yaml" >}}
 
+The name of a PodPreset object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
 In the manifest, you can see that the preset has an environment variable definition called `DB_PORT`
 and a volume mount definition called `cache-volume` which is mounted under `/cache`. The {{< glossary_tooltip text="selector" term_id="selector" >}} specifies that
 the preset will act upon any Pod that is labeled `role:frontend`.