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:
 
@@ -44,7 +44,7 @@ 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.
 - 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.
 
@@ -102,7 +102,7 @@ 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
@@ -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)