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

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}
{{< 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
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`):
```
POST /apis/authentication.k8s.io/v1alpha1/selfsubjectreviews
POST /apis/authentication.k8s.io/v1beta1/selfsubjectreviews
```
```json
{
"apiVersion": "authentication.k8s.io/v1alpha1",
"apiVersion": "authentication.k8s.io/v1beta1",
"kind": "SelfSubjectReview"
}
```
@ -1243,7 +1243,7 @@ Response example:
```json
{
"apiVersion": "authentication.k8s.io/v1alpha1",
"apiVersion": "authentication.k8s.io/v1beta1",
"kind": "SelfSubjectReview",
"status": {
"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
```
@ -1352,8 +1352,8 @@ By default, all authenticated users can create `SelfSubjectReview` objects when
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 the `authentication.k8s.io/v1alpha1`
is enabled for your cluster (enabled by default after reaching Beta)
* 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" >}}
enabled.
{{< /note >}}

View File

@ -62,7 +62,8 @@ For a reference to old feature gates that are removed, please refer to
| `APIPriorityAndFairness` | `true` | Beta | 1.20 | |
| `APIResponseCompression` | `false` | Alpha | 1.7 | 1.15 |
| `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` | `true` | Beta | 1.26 | |
| `APIServerTracing` | `false` | Alpha | 1.22 | |

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.
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)
to learn about this in more detail.