Merge pull request #40527 from Zhuzhenghao/rbac

Cleanup page rbac

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

@@ -214,14 +214,14 @@ a replacement.
 There are two reasons for this restriction:
 
 1. Making `roleRef` immutable allows granting someone `update` permission on an existing binding
-object, so that they can manage the list of subjects, without being able to change
+   object, so that they can manage the list of subjects, without being able to change
-the role that is granted to those subjects.
+   the role that is granted to those subjects.
 1. A binding to a different role is a fundamentally different binding.
-Requiring a binding to be deleted/recreated in order to change the `roleRef`
+   Requiring a binding to be deleted/recreated in order to change the `roleRef`
-ensures the full list of subjects in the binding is intended to be granted
+   ensures the full list of subjects in the binding is intended to be granted
-the new role (as opposed to enabling or accidentally modifying only the roleRef
+   the new role (as opposed to enabling or accidentally modifying only the roleRef
-without verifying all of the existing subjects should be given the new role's
+   without verifying all of the existing subjects should be given the new role's
-permissions).
+   permissions).
 
 The `kubectl auth reconcile` command-line utility creates or updates a manifest file containing RBAC objects,
 and handles deleting and recreating binding objects if required to change the role they refer to.
@@ -261,7 +261,6 @@ When specified, requests can be restricted to individual instances of a resource
 Here is an example that restricts its subject to only `get` or `update` a
 {{< glossary_tooltip term_id="ConfigMap" >}} named `my-configmap`:
 
-
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: Role
@@ -306,12 +305,15 @@ rules:
 ```
 
 {{< caution >}}
-Using wildcards in resource and verb entries could result in overly permissive access being granted to sensitive resources.
+Using wildcards in resource and verb entries could result in overly permissive access being granted
-For instance, if a new resource type is added, or a new subresource is added, or a new custom verb is checked, the wildcard entry automatically grants access, which may be undesirable.
+to sensitive resources.
-The [principle of least privilege](/docs/concepts/security/rbac-good-practices/#least-privilege) should be employed, using specific resources and verbs to ensure only the permissions required for the workload to function correctly are applied. 
+For instance, if a new resource type is added, or a new subresource is added,
+or a new custom verb is checked, the wildcard entry automatically grants access, which may be undesirable.
+The [principle of least privilege](/docs/concepts/security/rbac-good-practices/#least-privilege)
+should be employed, using specific resources and verbs to ensure only the permissions required for the
+workload to function correctly are applied.
 {{< /caution >}}
 
-
 ### Aggregated ClusterRoles
 
 You can _aggregate_ several ClusterRoles into one combined ClusterRole.
@@ -625,7 +627,10 @@ Auto-reconciliation is enabled by default if the RBAC authorizer is active.
 
 ### API discovery roles {#discovery-roles}
 
-Default role bindings authorize unauthenticated and authenticated users to read API information that is deemed safe to be publicly accessible (including CustomResourceDefinitions). To disable anonymous unauthenticated access, add `--anonymous-auth=false` to the API server configuration.
+Default role bindings authorize unauthenticated and authenticated users to read API information
+that is deemed safe to be publicly accessible (including CustomResourceDefinitions).
+To disable anonymous unauthenticated access, add `--anonymous-auth=false` to
+the API server configuration.
 
 To view the configuration of these roles via `kubectl` run:
 
@@ -900,16 +905,20 @@ Because this is enforced at the API level, it applies even when the RBAC authori
 You can only create/update a role if at least one of the following things is true:
 
 1. You already have all the permissions contained in the role, at the same scope as the object being modified
-(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role).
+   (cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role).
-2. You are granted explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group.
+2. You are granted explicit permission to perform the `escalate` verb on the `roles` or
+   `clusterroles` resource in the `rbac.authorization.k8s.io` API group.
 
 For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRole
 containing that permission. To allow a user to create/update roles:
 
 1. Grant them a role that allows them to create/update Role or ClusterRole objects, as desired.
 2. Grant them permission to include specific permissions in the roles they create/update:
-    * implicitly, by giving them those permissions (if they attempt to create or modify a Role or ClusterRole with permissions they themselves have not been granted, the API request will be forbidden)
+   * implicitly, by giving them those permissions (if they attempt to create or modify a Role or
-    * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group
+     ClusterRole with permissions they themselves have not been granted, the API request will be forbidden)
+   * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them
+     permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the
+     `rbac.authorization.k8s.io` API group
 
 ### Restrictions on role binding creation or update