Provide a consistent appearance to bullets

windsonsea · windsonsea · commit ca08498f331a · 2023-07-25T09:23:22.000+08:00
diff --git a/content/en/docs/concepts/security/rbac-good-practices.md b/content/en/docs/concepts/security/rbac-good-practices.md
@@ -9,10 +9,10 @@ weight: 60
 
 <!-- overview -->
 
-Kubernetes {{< glossary_tooltip text="RBAC" term_id="rbac" >}} is a key security control 
-to ensure that cluster users and workloads have only the access to resources required to 
+Kubernetes {{< glossary_tooltip text="RBAC" term_id="rbac" >}} is a key security control
+to ensure that cluster users and workloads have only the access to resources required to
 execute their roles. It is important to ensure that, when designing permissions for cluster
-users, the cluster administrator understands the areas where privilege escalation could occur, 
+users, the cluster administrator understands the areas where privilege escalation could occur,
 to reduce the risk of excessive access leading to security incidents.
 
 The good practices laid out here should be read in conjunction with the general
@@ -24,46 +24,46 @@ The good practices laid out here should be read in conjunction with the general
 
 ### Least privilege
 
-Ideally, minimal RBAC rights should be assigned to users and service accounts. Only permissions 
-explicitly required for their operation should be used. While each cluster will be different, 
+Ideally, minimal RBAC rights should be assigned to users and service accounts. Only permissions
+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 
-   ClusterRoleBindings to give users rights only within a specific namespace.
- - 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. 
-   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 
-   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 
-   from users who are members of that group are never sent to the webhook)
+- 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.
+  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.
+  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
+  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
+  from users who are members of that group are never sent to the webhook)
 
 ### Minimize distribution of privileged tokens
 
 Ideally, pods shouldn't be assigned service accounts that have been granted powerful permissions
-(for example, any of the rights listed under [privilege escalation risks](#privilege-escalation-risks)). 
+(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 
-   [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)
-   to ensure pods don't run alongside untrusted or less-trusted Pods. Pay especial attention to
-   situations where less-trustworthy Pods are not meeting the **Restricted** Pod Security Standard.
+- 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)
+  to ensure pods don't run alongside untrusted or less-trusted Pods. Pay especial attention to
+  situations where less-trustworthy Pods are not meeting the **Restricted** Pod Security Standard.
 
 ### Hardening
 
-Kubernetes defaults to providing access which may not be required in every cluster. Reviewing 
+Kubernetes defaults to providing access which may not be required in every cluster. Reviewing
 the RBAC rights provided by default can provide opportunities for security hardening.
-In general, changes should not be made to rights provided to `system:` accounts some options 
+In general, changes should not be made to rights provided to `system:` accounts some options
 to harden cluster rights exist:
 
 - Review bindings for the `system:unauthenticated` group and remove them where possible, as this gives 
@@ -76,7 +76,7 @@ to harden cluster rights exist:
 
 ### Periodic review
 
-It is vital to periodically review the Kubernetes RBAC settings for redundant entries and 
+It is vital to periodically review the Kubernetes RBAC settings for redundant entries and
 possible privilege escalations.
 If an attacker is able to create a user account with the same name as a deleted user,
 they can automatically inherit all the rights of the deleted user, especially the
@@ -87,7 +87,7 @@ rights assigned to that user.
 Within Kubernetes RBAC there are a number of privileges which, if granted, can allow a user or a service account
 to escalate their privileges in the cluster or affect systems outside the cluster.
 
-This section is intended to provide visibility of the areas where cluster operators 
+This section is intended to provide visibility of the areas where cluster operators
 should take care, to ensure that they do not inadvertently allow for more access to clusters than intended.
 
 ### Listing secrets
@@ -125,7 +125,7 @@ If someone - or some application - is allowed to create arbitrary PersistentVolu
 includes the creation of `hostPath` volumes, which then means that a Pod would get access
 to the underlying host filesystem(s) on the associated node. Granting that ability is a security risk.
 
-There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including 
+There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including
 reading data from other containers, and abusing the credentials of system services, such as Kubelet.
 
 You should only allow access to create PersistentVolume objects for:
@@ -135,56 +135,56 @@ You should only allow access to create PersistentVolume objects for:
   that are configured for automatic provisioning.
   This is usually setup by the Kubernetes provider or by the operator when installing a CSI driver.
 
-Where access to persistent storage is required trusted administrators should create 
+Where access to persistent storage is required trusted administrators should create
 PersistentVolumes, and constrained users should use PersistentVolumeClaims to access that storage.
 
 ### Access to `proxy` subresource of Nodes
 
-Users with access to the proxy sub-resource of node objects have rights to the Kubelet API, 
-which allows for command execution on every pod on the node(s) to which they have rights. 
-This access bypasses audit logging and admission control, so care should be taken before 
+Users with access to the proxy sub-resource of node objects have rights to the Kubelet API,
+which allows for command execution on every pod on the node(s) to which they have rights.
+This access bypasses audit logging and admission control, so care should be taken before
 granting rights to this resource.
 
 ### Escalate verb
 
-Generally, the RBAC system prevents users from creating clusterroles with more rights than the user possesses. 
+Generally, the RBAC system prevents users from creating clusterroles with more rights than the user possesses.
 The exception to this is the `escalate` verb. As noted in the [RBAC documentation](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update),
 users with this right can effectively escalate their privileges.
 
 ### Bind verb
 
-Similar to the `escalate` verb, granting users this right allows for the bypass of Kubernetes 
-in-built protections against privilege escalation, allowing users to create bindings to 
+Similar to the `escalate` verb, granting users this right allows for the bypass of Kubernetes
+in-built protections against privilege escalation, allowing users to create bindings to
 roles with rights they do not already have.
 
 ### Impersonate verb
 
-This verb allows users to impersonate and gain the rights of other users in the cluster. 
-Care should be taken when granting it, to ensure that excessive permissions cannot be gained 
+This verb allows users to impersonate and gain the rights of other users in the cluster.
+Care should be taken when granting it, to ensure that excessive permissions cannot be gained
 via one of the impersonated accounts.
 
 ### CSRs and certificate issuing
 
-The CSR API allows for users with `create` rights to CSRs and `update` rights on `certificatesigningrequests/approval` 
-where the signer is `kubernetes.io/kube-apiserver-client` to create new client certificates 
-which allow users to authenticate to the cluster. Those client certificates can have arbitrary 
+The CSR API allows for users with `create` rights to CSRs and `update` rights on `certificatesigningrequests/approval`
+where the signer is `kubernetes.io/kube-apiserver-client` to create new client certificates
+which allow users to authenticate to the cluster. Those client certificates can have arbitrary
 names including duplicates of Kubernetes system components. This will effectively allow for privilege escalation.
 
 ### Token request
 
-Users with `create` rights on `serviceaccounts/token` can create TokenRequests to issue 
-tokens for existing service accounts. 
+Users with `create` rights on `serviceaccounts/token` can create TokenRequests to issue
+tokens for existing service accounts.
 
 ### Control admission webhooks
 
-Users with control over `validatingwebhookconfigurations` or `mutatingwebhookconfigurations` 
-can control webhooks that can read any object admitted to the cluster, and in the case of 
+Users with control over `validatingwebhookconfigurations` or `mutatingwebhookconfigurations`
+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
diff --git a/content/en/docs/concepts/security/service-accounts.md b/content/en/docs/concepts/security/service-accounts.md
@@ -26,18 +26,18 @@ implementing identity-based security policies.
 Service accounts exist as ServiceAccount objects in the API server. Service
 accounts have the following properties:
 
-*  **Namespaced:** Each service account is bound to a Kubernetes
-   {{<glossary_tooltip text="namespace" term_id="namespace">}}. Every namespace
-   gets a [`default` ServiceAccount](#default-service-accounts) upon creation.
+* **Namespaced:** Each service account is bound to a Kubernetes
+  {{<glossary_tooltip text="namespace" term_id="namespace">}}. Every namespace
+  gets a [`default` ServiceAccount](#default-service-accounts) upon creation.
 
-*  **Lightweight:** Service accounts exist in the cluster and are
-   defined in the Kubernetes API. You can quickly create service accounts to
-   enable specific tasks.
+* **Lightweight:** Service accounts exist in the cluster and are
+  defined in the Kubernetes API. You can quickly create service accounts to
+  enable specific tasks.
 
-*  **Portable:** A configuration bundle for a complex containerized workload
-   might include service account definitions for the system's components. The
-   lightweight nature of service accounts and the namespaced identities make
-   the configurations portable.
+* **Portable:** A configuration bundle for a complex containerized workload
+  might include service account definitions for the system's components. The
+  lightweight nature of service accounts and the namespaced identities make
+  the configurations portable.
 
 Service accounts are different from user accounts, which are authenticated
 human users in the cluster. By default, user accounts don't exist in the Kubernetes
@@ -78,10 +78,10 @@ the following scenarios:
 
 * Your Pods need to communicate with the Kubernetes API server, for example in
   situations such as the following:
-  *  Providing read-only access to sensitive information stored in Secrets.
-  *  Granting [cross-namespace access](#cross-namespace), such as allowing a
-     Pod in namespace `example` to read, list, and watch for Lease objects in
-     the `kube-node-lease` namespace.
+  * Providing read-only access to sensitive information stored in Secrets.
+  * Granting [cross-namespace access](#cross-namespace), such as allowing a
+    Pod in namespace `example` to read, list, and watch for Lease objects in
+    the `kube-node-lease` namespace.
 * Your Pods need to communicate with an external service. For example, a
   workload Pod requires an identity for a commercially available cloud API,
   and the commercial provider allows configuring a suitable trust relationship.
@@ -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,
@@ -147,7 +146,7 @@ API and mounts the token as a
 
 By default, Kubernetes provides the Pod
 with the credentials for an assigned ServiceAccount, whether that is the
-`default` ServiceAccount or a custom ServiceAccount that you specify. 
+`default` ServiceAccount or a custom ServiceAccount that you specify.
 
 To prevent Kubernetes from automatically injecting
 credentials for a specified ServiceAccount or the `default` ServiceAccount, set the
@@ -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. Check whether the token has expired.
-1. Check whether object references in the token claims are currently valid.
-1. Check whether the token is currently valid.
-1. Check the audience claims.
+1. Checks the token signature.
+1. Checks whether the token has expired.
+1. Checks whether object references in the token claims are currently valid.
+1. Checks whether the token is currently valid.
+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
@@ -257,15 +256,15 @@ used in your application and nowhere else.
   [Webhook Token Authentication](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
   to validate bearer tokens using your own validation service.
 * Provide your own identities to Pods.
-    * [Use the SPIFFE CSI driver plugin to provide SPIFFE SVIDs as X.509 certificate pairs to Pods](https://cert-manager.io/docs/projects/csi-driver-spiffe/).
+  * [Use the SPIFFE CSI driver plugin to provide SPIFFE SVIDs as X.509 certificate pairs to Pods](https://cert-manager.io/docs/projects/csi-driver-spiffe/).
     {{% thirdparty-content single="true" %}}
-    * [Use a service mesh such as Istio to provide certificates to Pods](https://istio.io/latest/docs/tasks/security/cert-management/plugin-ca-cert/).
+  * [Use a service mesh such as Istio to provide certificates to Pods](https://istio.io/latest/docs/tasks/security/cert-management/plugin-ca-cert/).
 * Authenticate from outside the cluster to the API server without using service account tokens:
-    * [Configure the API server to accept OpenID Connect (OIDC) tokens from your identity provider](/docs/reference/access-authn-authz/authentication/#openid-connect-tokens).
-    * Use service accounts or user accounts created using an external Identity
-      and Access Management (IAM) service, such as from a cloud provider, to
-      authenticate to your cluster.
-    * [Use the CertificateSigningRequest API with client certificates](/docs/tasks/tls/managing-tls-in-a-cluster/).
+  * [Configure the API server to accept OpenID Connect (OIDC) tokens from your identity provider](/docs/reference/access-authn-authz/authentication/#openid-connect-tokens).
+  * Use service accounts or user accounts created using an external Identity
+    and Access Management (IAM) service, such as from a cloud provider, to
+    authenticate to your cluster.
+  * [Use the CertificateSigningRequest API with client certificates](/docs/tasks/tls/managing-tls-in-a-cluster/).
 * [Configure the kubelet to retrieve credentials from an image registry](/docs/tasks/administer-cluster/kubelet-credential-provider/).
 * Use a Device Plugin to access a virtual Trusted Platform Module (TPM), which
   then allows authentication using a private key.
