kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Promote SelfSubjectReview to Beta 

Signed-off-by: m.nabokikh <maksim.nabokikh@flant.com>
pull/39794/head
m.nabokikh 2023-03-05 22:28:04 +01:00
parent bd456cf518
commit bb14c6db8d
3 changed files with 10 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1221,7 +1221,7 @@ The following `ExecCredential` manifest describes a cluster information sample.
## API access to authentication information for a client {#self-subject-review} ## API access to authentication information for a client {#self-subject-review}
{{< feature-state for_k8s_version="v1.26" state="alpha" >}} {{< feature-state for_k8s_version="v1.27" state="beta" >}}
If your cluster has the API enabled, you can use the `SelfSubjectReview` API to find out how your Kubernetes cluster maps your authentication If your cluster has the API enabled, you can use the `SelfSubjectReview` API to find out how your Kubernetes cluster maps your authentication
information to identify you as a client. This works whether you are authenticating as a user (typically representing information to identify you as a client. This works whether you are authenticating as a user (typically representing
@ -1231,11 +1231,11 @@ a real person) or as a ServiceAccount.
Request example (the body would be a `SelfSubjectReview`): Request example (the body would be a `SelfSubjectReview`):
``` ```
POST /apis/authentication.k8s.io/v1alpha1/selfsubjectreviews POST /apis/authentication.k8s.io/v1beta1/selfsubjectreviews
``` ```
```json ```json
{ {
"apiVersion": "authentication.k8s.io/v1alpha1", "apiVersion": "authentication.k8s.io/v1beta1",
"kind": "SelfSubjectReview" "kind": "SelfSubjectReview"
} }
``` ```
@ -1243,7 +1243,7 @@ Response example:
```json ```json
{ {
"apiVersion": "authentication.k8s.io/v1alpha1", "apiVersion": "authentication.k8s.io/v1beta1",
"kind": "SelfSubjectReview", "kind": "SelfSubjectReview",
"status": { "status": {
"userInfo": { "userInfo": {
@ -1262,7 +1262,7 @@ Response example:
} }
``` ```
For convenience, the `kubectl alpha auth whoami` command is present. Executing this command will produce the following output (yet different user attributes will be shown): For convenience, the `kubectl auth whoami` command is present. Executing this command will produce the following output (yet different user attributes will be shown):
* Simple output example * Simple output example
``` ```
@ -1352,8 +1352,8 @@ By default, all authenticated users can create `SelfSubjectReview` objects when
You can only make `SelfSubjectReview` requests if: You can only make `SelfSubjectReview` requests if:
* the `APISelfSubjectReview` * the `APISelfSubjectReview`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
is enabled for your cluster is enabled for your cluster (enabled by default after reaching Beta)
* the API server for your cluster has the `authentication.k8s.io/v1alpha1` * the API server for your cluster has the `authentication.k8s.io/v1alpha1` or `authentication.k8s.io/v1beta1`
{{< glossary_tooltip term_id="api-group" text="API group" >}} {{< glossary_tooltip term_id="api-group" text="API group" >}}
enabled. enabled.
{{< /note >}} {{< /note >}}

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

@ -62,7 +62,8 @@ For a reference to old feature gates that are removed, please refer to
| `APIPriorityAndFairness` | `true` | Beta | 1.20 | | | `APIPriorityAndFairness` | `true` | Beta | 1.20 | |
| `APIResponseCompression` | `false` | Alpha | 1.7 | 1.15 | | `APIResponseCompression` | `false` | Alpha | 1.7 | 1.15 |
| `APIResponseCompression` | `true` | Beta | 1.16 | | | `APIResponseCompression` | `true` | Beta | 1.16 | |
| `APISelfSubjectReview` | `false` | Alpha | 1.26 | | | `APISelfSubjectReview` | `false` | Alpha | 1.26 | 1.26 |
| `APISelfSubjectReview` | `true` | Beta | 1.27 | |
| `APIServerIdentity` | `false` | Alpha | 1.20 | 1.25 | | `APIServerIdentity` | `false` | Alpha | 1.20 | 1.25 |
| `APIServerIdentity` | `true` | Beta | 1.26 | | | `APIServerIdentity` | `true` | Beta | 1.26 | |
| `APIServerTracing` | `false` | Alpha | 1.22 | | | `APIServerTracing` | `false` | Alpha | 1.22 | |

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

@ -404,7 +404,7 @@ It is not always obvious what attributes (username, groups) you will get after a
It can be even more challenging if you are managing more than one cluster at the same time. It can be even more challenging if you are managing more than one cluster at the same time.
There is a `kubectl` alpha subcommand command to check subject attributes, such as username, There is a `kubectl` alpha subcommand command to check subject attributes, such as username,
for your selected Kubernetes client context: `kubectl alpha auth whoami`. for your selected Kubernetes client context: `kubectl auth whoami`.
Read [API access to authentication information for a client](/docs/reference/access-authn-authz/authentication/#self-subject-review) 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. to learn about this in more detail.