Webhooks in Kubernetes

There are two types of control. One is to control which user(token, group) is allowed to access, the other one is to control which resource a user could access. The kube-apiserver has two arguments to allow users to define that.

• Authentication: –authentication-token-webhook-config-file
• Authorization: –authorization-webhook-config-file

Here is the definition about what admission webhook could do.

Admission webhooks are HTTP callbacks that receive admission requests and do something with them. You can define two types of admission webhooks, validating admission webhook and mutating admission webhook. Mutating admission webhooks are invoked first, and can modify objects sent to the API server to enforce custom defaults. After all object modifications are complete, and after the incoming object is validated by the API server, validating admission webhooks are invoked and can reject requests to enforce custom policies.

So, basically there are two types of admission webhook you could use

• Validating admission webhook
• Mutating admission webhook

Sometimes multiple versions of CRD will be supported at the same time. However, we usually will only allow one version to be stored in ETCD. Because we don't want to maintain the consistency between different versions. Kubernetes allows us to define a webhook to convert between versions on the fly.