Kubernetes Admission Controller Concepts: Difference between revisions
No edit summary |
|||
| (6 intermediate revisions by the same user not shown) | |||
| Line 8: | Line 8: | ||
=Overview= | =Overview= | ||
An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the metadata, but after the request is authenticated and authorized. There is a fixed set of admission controller that include [[#AlwaysPullImages| AlwaysPullImages]], [[#PodSecurityPolicy|PodSecurityPolicy]], etc. The controllers are compiled into the [[Kubernetes_Control_Plane_and_Data_Plane_Concepts#API_Server|kube-apiserver binary]], and may only be configured by the [[Kubernetes_Security_Concepts#Cluster_Administrator|cluster administrator]]. Of these, two controllers ([[#MutatingAdmissionWebhook|MutatingAdmissionWebhook]] and [[#ValidatingAdmissionWebhook|ValidatingAdmissionWebhook]]) are | An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the metadata, but after the request is authenticated and authorized. There is a fixed set of admission controller that include [[#AlwaysPullImages| AlwaysPullImages]], [[#PodSecurityPolicy|PodSecurityPolicy]], etc. The controllers are compiled into the [[Kubernetes_Control_Plane_and_Data_Plane_Concepts#API_Server|kube-apiserver binary]], and may only be configured by the [[Kubernetes_Security_Concepts#Cluster_Administrator|cluster administrator]]. Of these, two controllers ([[#MutatingAdmissionWebhook|MutatingAdmissionWebhook]] and [[#ValidatingAdmissionWebhook|ValidatingAdmissionWebhook]]) are special, in that they allow for [[#Dynamic_Admission_Control|dynamic admission control]]. | ||
<font color=orange>OpenShift content</font><font color=darkgray>: the admission controller validates requests by processing these requests relative to all applicable [[OpenShift Security Context Constraints|Security Context Constraints]]s. The admission controller first identifies all applicable [[OpenShift Security Context Constraints|SCC]]s based on the user identity and groups the user belongs to. If the pod specifies a service account, the constraints accessible to the [[OpenShift_Security_Context_Constraints#Security_Context_Constraints_and_Service_Accounts|service account]] will be added to the applicable [[OpenShift Security Context Constraints|SCC]] set. It then sorts the SCCs by their [[#priority|priority]] field, highest priority SCCs being placed in front of the list. Nil is considered 0 priority. If the priorities are equal, the SCCs will be sorted from most restrictive to least restrictive. All else being equal, the SCCs will be sorted by name. The field values for the security context settings that were not specified on the request are generated. The final settings are validated against the available constraints. Each field of the security context must be validated against SCCs in order for a request to be successful.</font> | <font color=orange>OpenShift content</font><font color=darkgray>: the admission controller validates requests by processing these requests relative to all applicable [[OpenShift Security Context Constraints|Security Context Constraints]]s. The admission controller first identifies all applicable [[OpenShift Security Context Constraints|SCC]]s based on the user identity and groups the user belongs to. If the pod specifies a service account, the constraints accessible to the [[OpenShift_Security_Context_Constraints#Security_Context_Constraints_and_Service_Accounts|service account]] will be added to the applicable [[OpenShift Security Context Constraints|SCC]] set. It then sorts the SCCs by their [[#priority|priority]] field, highest priority SCCs being placed in front of the list. Nil is considered 0 priority. If the priorities are equal, the SCCs will be sorted from most restrictive to least restrictive. All else being equal, the SCCs will be sorted by name. The field values for the security context settings that were not specified on the request are generated. The final settings are validated against the available constraints. Each field of the security context must be validated against SCCs in order for a request to be successful.</font> | ||
| Line 30: | Line 30: | ||
{{External|https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook}} | {{External|https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook}} | ||
=== ValidatingAdmissionWebhook=== | ===ValidatingAdmissionWebhook=== | ||
{{External|https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook}} | |||
====ValidatingWebhookConfiguration==== | |||
It is a [[Kubernetes API Resources Concepts#ValidatingWebhookConfiguration|Kubernetes API resource]]. | |||
=Admission Controller Operations= | =Admission Controller Operations= | ||
{{Internal|Admission Controller Operations|Admission Controller Operations}} | {{Internal|Admission Controller Operations|Admission Controller Operations}} | ||
Latest revision as of 00:35, 16 November 2021
External
- https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
- https://docs.openshift.org/latest/architecture/additional_concepts/authorization.html#admission
Internal
Overview
An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the metadata, but after the request is authenticated and authorized. There is a fixed set of admission controller that include AlwaysPullImages, PodSecurityPolicy, etc. The controllers are compiled into the kube-apiserver binary, and may only be configured by the cluster administrator. Of these, two controllers (MutatingAdmissionWebhook and ValidatingAdmissionWebhook) are special, in that they allow for dynamic admission control.
OpenShift content: the admission controller validates requests by processing these requests relative to all applicable Security Context Constraintss. The admission controller first identifies all applicable SCCs based on the user identity and groups the user belongs to. If the pod specifies a service account, the constraints accessible to the service account will be added to the applicable SCC set. It then sorts the SCCs by their priority field, highest priority SCCs being placed in front of the list. Nil is considered 0 priority. If the priorities are equal, the SCCs will be sorted from most restrictive to least restrictive. All else being equal, the SCCs will be sorted by name. The field values for the security context settings that were not specified on the request are generated. The final settings are validated against the available constraints. Each field of the security context must be validated against SCCs in order for a request to be successful.
Admission Controller Types
AlwaysPullImages
PodSecurityPolicy
DefaultStorageClass
The DefaultStorageClass is relevant in Persistent Volume Claims and Storage Class conversation.
Dynamic Admission Control
In addition to compiled-in admission controller, admission plugins can be developed as extensions and run as webhooks configured at runtime.
MutatingAdmissionWebhook
ValidatingAdmissionWebhook
ValidatingWebhookConfiguration
It is a Kubernetes API resource.