Apply suggestions from code review

Co-authored-by: Tim Bannister <tim@scalefactory.com>

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

@@ -1337,11 +1337,11 @@ status:
 {{< /tabs >}}
 
 This feature is extremely useful when a complicated authentication flow is used in a Kubernetes cluster, 
-for example, if you use [webhook token authentication](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) or [authenticating proxy](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#authenticating-proxy).
+for example, if you use [webhook token authentication](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) or [authenticating proxy](/docs/reference/access-authn-authz/authentication/#authenticating-proxy).
 
 {{< note >}}
 The Kubernetes API server fills the `userInfo` after all authentication mechanisms are applied,
-including [impersonation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation).
+including [impersonation](/docs/reference/access-authn-authz/authentication/#user-impersonation).
 If you, or an authentication proxy, make a SelfSubjectReview using impersonation,
 you see the user details and properties for the user that was impersonated.
 {{< /note >}}
@@ -1353,7 +1353,7 @@ You can only make `SelfSubjectReview` requests if:
 * the `APISelfSubjectReview`
   [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
   is enabled for your cluster
-* the API server for your cluster has `authentication.k8s.io/v1alpha1`
+* the API server for your cluster has the `authentication.k8s.io/v1alpha1`
   {{< glossary_tooltip term_id="api-group" text="API group" >}}
   enabled.
 {{< /note >}}

content/en/docs/reference/command-line-tools-reference/feature-gates.md

@@ -378,7 +378,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `APIServerIdentity`: Assign each API server an ID in a cluster.
 - `APIServerTracing`: Add support for distributed tracing in the API server.
   See [Traces for Kubernetes System Components](/docs/concepts/cluster-administration/system-traces) for more details.
-- `APISelfSubjectAttributesReview`: Enable the authentication API to see the requesting subject's authentication information. Required to use the `kubectl alpha auth whoami` command.
+- `APISelfSubjectAttributesReview`: Activate the `SelfSubjectReview` API which allows users
 - `AdvancedAuditing`: Enable [advanced auditing](/docs/tasks/debug/debug-cluster/audit/#advanced-audit)
 - `AllowInsecureBackendProxy`: Enable the users to skip TLS verification of
   kubelets on Pod log requests.

content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md

@@ -403,7 +403,8 @@ $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
 It is not always obvious what attributes (username, groups) you will get after authenticating to the cluster. 
 It can be even more challenging if you are managing more than one cluster at the same time.
 
-There is a notable command to check subject attributes represented by contexts of your kubeconfig file - `kubectl alpha auth whoami`.
+There is a `kubectl` alpha subcommand command to check subject attributes, such as username,
+for your selected Kubernetes client context: `kubectl alpha auth whoami`.
 
 Read [API access to authentication information for a client](/docs/reference/access-authn-authz/authentication/#self-subject-review)
 to learn about this in more detail.