Merge pull request #48701 from windsonsea/autmec

Add reference to and clean up authentication-mechanisms.md

content/en/docs/concepts/security/hardening-guide/authentication-mechanisms.md

@@ -23,14 +23,14 @@ configured authentication source.
 For production clusters with multiple users directly accessing the Kubernetes API, it is
 recommended to use external authentication sources such as OIDC. The internal authentication
 mechanisms, such as client certificates and service account tokens, described below, are not
-suitable for this use-case.
+suitable for this use case.
 
 <!-- body -->
 
 ## X.509 client certificate authentication {#x509-client-certificate-authentication}
 
 Kubernetes leverages [X.509 client certificate](/docs/reference/access-authn-authz/authentication/#x509-client-certificates)
-authentication for system components, such as when the Kubelet authenticates to the API Server. 
+authentication for system components, such as when the kubelet authenticates to the API Server.
 While this mechanism can also be used for user authentication, it might not be suitable for
 production use due to several restrictions:
 
@@ -38,15 +38,15 @@ production use due to several restrictions:
   by an attacker until it expires. To mitigate this risk, it is recommended to configure short
   lifetimes for user authentication credentials created using client certificates.
 - If a certificate needs to be invalidated, the certificate authority must be re-keyed, which
-can introduce availability risks to the cluster.
+  can introduce availability risks to the cluster.
 - There is no permanent record of client certificates created in the cluster. Therefore, all
-issued certificates must be recorded if you need to keep track of them.
+  issued certificates must be recorded if you need to keep track of them.
 - Private keys used for client certificate authentication cannot be password-protected. Anyone
-who can read the file containing the key will be able to make use of it.
+  who can read the file containing the key will be able to make use of it.
 - Using client certificate authentication requires a direct connection from the client to the
-API server with no intervening TLS termination points, which can complicate network architectures.
+  API server without any intervening TLS termination points, which can complicate network architectures.
 - Group data is embedded in the `O` value of the client certificate, which means the user's group
-memberships cannot be changed for the lifetime of the certificate.
+  memberships cannot be changed for the lifetime of the certificate.
 
 ## Static token file {#static-token-file}
 
@@ -57,9 +57,9 @@ several reasons:
 
 - Credentials are stored in clear text on control plane node disks, which can be a security risk.
 - Changing any credential requires a restart of the API server process to take effect, which can
-impact availability.
+  impact availability.
 - There is no mechanism available to allow users to rotate their credentials. To rotate a
-credential, a cluster administrator must modify the token on disk and distribute it to the users.
+  credential, a cluster administrator must modify the token on disk and distribute it to the users.
 - There is no lockout mechanism available to prevent brute-force attacks.
 
 ## Bootstrap tokens {#bootstrap-tokens}
@@ -68,11 +68,11 @@ credential, a cluster administrator must modify the token on disk and distribute
 nodes to clusters and are not recommended for user authentication due to several reasons:
 
 - They have hard-coded group memberships that are not suitable for general use, making them
-unsuitable for authentication purposes.
+  unsuitable for authentication purposes.
 - Manually generating bootstrap tokens can lead to weak tokens that can be guessed by an attacker,
-which can be a security risk.
+  which can be a security risk.
 - There is no lockout mechanism available to prevent brute-force attacks, making it easier for
-attackers to guess or crack the token.
+  attackers to guess or crack the token.
 
 ## ServiceAccount secret tokens {#serviceaccount-secret-tokens}
 
@@ -84,7 +84,7 @@ generally unsuitable for a number of reasons:
 
 - They cannot be set with an expiry and will remain valid until the associated service account is deleted.
 - The authentication tokens are visible to any cluster user who can read secrets in the namespace
-that they are defined in.
+  that they are defined in.
 - Service accounts cannot be added to arbitrary groups complicating RBAC management where they are used.
 
 ## TokenRequest API tokens {#tokenrequest-api-tokens}
@@ -102,14 +102,14 @@ lifespan to reduce the impact of compromised tokens.
 Kubernetes supports integrating external authentication services with the Kubernetes API using
 [OpenID Connect (OIDC)](/docs/reference/access-authn-authz/authentication/#openid-connect-tokens).
 There is a wide variety of software that can be used to integrate Kubernetes with an identity
-provider. However, when using OIDC authentication for Kubernetes, it is important to consider the 
+provider. However, when using OIDC authentication in Kubernetes, it is important to consider the
 following hardening measures:
 
 - The software installed in the cluster to support OIDC authentication should be isolated from
-general workloads as it will run with high privileges.
+  general workloads as it will run with high privileges.
 - Some Kubernetes managed services are limited in the OIDC providers that can be used.
 - As with TokenRequest tokens, OIDC tokens should have a short lifespan to reduce the impact of
-compromised tokens.
+  compromised tokens.
 
 ## Webhook token authentication {#webhook-token-authentication}
 
@@ -141,3 +141,10 @@ between the proxy and Kubernetes API server is secure.
 Secondly, it is important to be aware that an attacker who is able to modify the headers of the
 request may be able to gain unauthorized access to Kubernetes resources. As such, it is important
 to ensure that the headers are properly secured and cannot be tampered with.
+
+## {{% heading "whatsnext" %}}
+
+- [User Authentication](/docs/reference/access-authn-authz/authentication/)
+- [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/)
+- [kubelet Authentication](/docs/reference/access-authn-authz/kubelet-authn-authz/#kubelet-authentication)
+- [Authenticating with Service Account Tokens](/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens)