From 5d61921a1174ae686e45dab51a7a03399c099c40 Mon Sep 17 00:00:00 2001 From: Maksim Nabokikh Date: Sun, 30 Oct 2022 01:43:46 +0400 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Tim Bannister --- .../en/docs/reference/access-authn-authz/authentication.md | 6 +++--- .../reference/command-line-tools-reference/feature-gates.md | 2 +- .../configure-access-multiple-clusters.md | 3 ++- 3 files changed, 6 insertions(+), 5 deletions(-) diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index dc2291f45c..c014f375b6 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/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 >}} diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 514aae9120..c0e14055b3 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/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. diff --git a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 27354f4a52..03dc6b4dc0 100644 --- a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/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.