Merge pull request #42187 from windsonsea/seracc

Provide a consistent appearance to bullets in service-accounts and rbac

content/en/docs/concepts/security/rbac-good-practices.md

@@ -28,17 +28,17 @@ Ideally, minimal RBAC rights should be assigned to users and service accounts. O
 explicitly required for their operation should be used. While each cluster will be different,
 some general rules that can be applied are :
 
- - Assign permissions at the namespace level where possible. Use RoleBindings as opposed to 
+- Assign permissions at the namespace level where possible. Use RoleBindings as opposed to
   ClusterRoleBindings to give users rights only within a specific namespace.
- - Avoid providing wildcard permissions when possible, especially to all resources.
+- Avoid providing wildcard permissions when possible, especially to all resources.
   As Kubernetes is an extensible system, providing wildcard access gives rights
   not just to all object types that currently exist in the cluster, but also to all object types
   which are created in the future.
- - Administrators should not use `cluster-admin` accounts except where specifically needed. 
+- Administrators should not use `cluster-admin` accounts except where specifically needed.
   Providing a low privileged account with
   [impersonation rights](/docs/reference/access-authn-authz/authentication/#user-impersonation)
   can avoid accidental modification of cluster resources.
- - Avoid adding users to the `system:masters` group. Any user who is a member of this group 
+- Avoid adding users to the `system:masters` group. Any user who is a member of this group
   bypasses all RBAC rights checks and will always have unrestricted superuser access, which cannot be
   revoked by removing RoleBindings or ClusterRoleBindings. As an aside, if a cluster is
   using an authorization webhook, membership of this group also bypasses that webhook (requests
@@ -50,9 +50,9 @@ Ideally, pods shouldn't be assigned service accounts that have been granted powe
 (for example, any of the rights listed under [privilege escalation risks](#privilege-escalation-risks)).
 In cases where a workload requires powerful permissions, consider the following practices:
 
- - Limit the number of nodes running powerful pods. Ensure that any DaemonSets you run
+- Limit the number of nodes running powerful pods. Ensure that any DaemonSets you run
   are necessary and are run with least privilege to limit the blast radius of container escapes.
- - Avoid running powerful pods alongside untrusted or publicly-exposed ones. Consider using 
+- Avoid running powerful pods alongside untrusted or publicly-exposed ones. Consider using
   [Taints and Toleration](/docs/concepts/scheduling-eviction/taint-and-toleration/),
   [NodeAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity), or
   [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
@@ -181,10 +181,10 @@ Users with control over `validatingwebhookconfigurations` or `mutatingwebhookcon
 can control webhooks that can read any object admitted to the cluster, and in the case of
 mutating webhooks, also mutate admitted objects.
 
-
 ## Kubernetes RBAC - denial of service risks {#denial-of-service-risks}
 
 ### Object creation denial-of-service {#object-creation-dos}
+
 Users who have rights to create objects in a cluster may be able to create sufficient large 
 objects to create a denial of service condition either based on the size or number of objects, as discussed in
 [etcd used by Kubernetes is vulnerable to OOM attack](https://github.com/kubernetes/kubernetes/issues/107325). This may be

content/en/docs/concepts/security/service-accounts.md

@@ -92,7 +92,6 @@ the following scenarios:
   ServiceAccount identity of different Pods to group those Pods into different
   contexts.
 
-
 ## How to use service accounts {#how-to-use}
 
 To use a Kubernetes service account, you do the following:
@@ -101,7 +100,7 @@ To use a Kubernetes service account, you do the following:
    client like `kubectl` or a manifest that defines the object.
 1. Grant permissions to the ServiceAccount object using an authorization
    mechanism such as
-   [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/).
+   [RBAC](/docs/reference/access-authn-authz/rbac/).
 1. Assign the ServiceAccount object to Pods during Pod creation.
    
    If you're using the identity from an external service,
@@ -210,11 +209,11 @@ acting as a ServiceAccount tries to communicate with the Kubernetes API server,
 the client includes an `Authorization: Bearer <token>` header with the HTTP
 request. The API server checks the validity of that bearer token as follows:
 
-1. Check the token signature.
+1. Checks the token signature.
-1. Check whether the token has expired.
+1. Checks whether the token has expired.
-1. Check whether object references in the token claims are currently valid.
+1. Checks whether object references in the token claims are currently valid.
-1. Check whether the token is currently valid.
+1. Checks whether the token is currently valid.
-1. Check the audience claims.
+1. Checks the audience claims.
 
 The TokenRequest API produces _bound tokens_ for a ServiceAccount. This
 binding is linked to the lifetime of the client, such as a Pod, that is acting