From d41800c42a5cc22b78ef5051a484d18809a03ac7 Mon Sep 17 00:00:00 2001 From: Jordan Liggitt Date: Fri, 12 Jan 2018 00:39:11 -0500 Subject: [PATCH] Clarify the token webhook posts the TokenReview object --- docs/admin/admission-controllers.md | 2 +- docs/admin/authentication.md | 7 +++---- docs/admin/authorization/webhook.md | 4 ++-- 3 files changed, 6 insertions(+), 7 deletions(-) diff --git a/docs/admin/admission-controllers.md b/docs/admin/admission-controllers.md index ca063be2c6..240cfd7558 100644 --- a/docs/admin/admission-controllers.md +++ b/docs/admin/admission-controllers.md @@ -222,7 +222,7 @@ For additional HTTP configuration, refer to the [kubeconfig](/docs/concepts/clus #### Request Payloads -When faced with an admission decision, the API Server POSTs a JSON serialized api.imagepolicy.v1alpha1.ImageReview object describing the action. This object contains fields describing the containers being admitted, as well as any pod annotations that match `*.image-policy.k8s.io/*`. +When faced with an admission decision, the API Server POSTs a JSON serialized `imagepolicy.k8s.io/v1alpha1` `ImageReview` object describing the action. This object contains fields describing the containers being admitted, as well as any pod annotations that match `*.image-policy.k8s.io/*`. Note that webhook API objects are subject to the same versioning compatibility rules as other Kubernetes API objects. Implementers should be aware of looser compatibility promises for alpha objects and check the "apiVersion" field of the request to ensure correct deserialization. Additionally, the API Server must enable the imagepolicy.k8s.io/v1alpha1 API extensions group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`). diff --git a/docs/admin/authentication.md b/docs/admin/authentication.md index 8d3bd1885f..979e5ff3d3 100644 --- a/docs/admin/authentication.md +++ b/docs/admin/authentication.md @@ -422,9 +422,8 @@ contexts: When a client attempts to authenticate with the API server using a bearer token as discussed [above](#putting-a-bearer-token-in-a-request), -the authentication webhook -queries the remote service with a review object containing the token. Kubernetes -will not challenge a request that lacks such a header. +the authentication webhook POSTs a JSON-serialized `authentication.k8s.io/v1beta1` `TokenReview` object containing the token +to the remote service. Kubernetes will not challenge a request that lacks such a header. Note that webhook API objects are subject to the same [versioning compatibility rules](/docs/concepts/overview/kubernetes-api/) as other Kubernetes API objects. Implementers should be aware of looser @@ -432,7 +431,7 @@ compatibility promises for beta objects and check the "apiVersion" field of the request to ensure correct deserialization. Additionally, the API server must enable the `authentication.k8s.io/v1beta1` API extensions group (`--runtime-config=authentication.k8s.io/v1beta1=true`). -The request body will be of the following format: +The POST body will be of the following format: ```json { diff --git a/docs/admin/authorization/webhook.md b/docs/admin/authorization/webhook.md index f451a0d569..390aeef079 100644 --- a/docs/admin/authorization/webhook.md +++ b/docs/admin/authorization/webhook.md @@ -54,8 +54,8 @@ contexts: ## Request Payloads -When faced with an authorization decision, the API Server POSTs a JSON -serialized api.authorization.v1beta1.SubjectAccessReview object describing the +When faced with an authorization decision, the API Server POSTs a JSON- +serialized `authorization.k8s.io/v1beta1` `SubjectAccessReview` object describing the action. This object contains fields describing the user attempting to make the request, and either details about the resource being accessed or requests attributes.