Home • Explore • Blog • CI
☰



kubernetes
4th chunk of `content/en/blog/_posts/2018-01-00-Extensible-Admission-Is-Beta.md`
8d32d406317fa13d0f39ddcbea58896b9e5950cd129167290000000100000924
- How the webhook admission server authenticates precisely which API server is contacting it
- Whether that particular API server has authorization to make the request
There are three major categories of connection:  

1. From kube-apiserver or extension-apiservers to externally hosted admission webhooks (webhooks not hosted in the cluster)
2. From kube-apiserver to self-hosted admission webhooks
3. From extension-apiservers to self-hosted admission webhooks
To support these categories, the webhook admission plugins accept a kubeconfig file which describes how to connect to individual servers. For interacting with externally hosted admission webhooks, there is really no alternative to configuring that file manually since the authentication/authorization and access paths are owned by the server you’re hooking to.  

For the self-hosted category, a cleverly built webhook admission server and topology can take advantage of the safe defaulting built into the admission plugin and have a secure, portable, zero-config topology that works from any API server.



### Simple, secure, portable, zero-config topology
If you build your webhook admission server to also be an extension API server, it becomes possible to aggregate it as a normal API server. This has a number of advantages:  

- Your webhook becomes available like any other API under default kube-apiserver service `kubernetes.default.svc` (e.g. [https://kubernetes.default.svc/apis/admission.example.com/v1/mymutatingadmissionreviews](https://kubernetes.default.svc/apis/admission.example.com/v1/mymutatingadmissionreviews)). Among other benefits, you can test using `kubectl`.
- Your webhook automatically (without any config) makes use of the in-cluster authentication and authorization provided by kube-apiserver. You can restrict access to your webhook with normal RBAC rules.
- Your extension API servers and kube-apiserver automatically (without any config) make use of their in-cluster credentials to communicate with the webhook.
- Extension API servers do not leak their service account token to your webhook because they go through kube-apiserver, which is a secure front proxy.

 ![](https://lh6.googleusercontent.com/FeXoJLmbhf5exSBQu6Wxd2sIEqzkKPbRA_iv6T2QmJbhRsO4FyPtgAAbHdAmuTrE0jVEUzftfxcPndN8ACzstfsX9XTFdQFrioS1srvYgVP3l99R6x-vvd3RfBA4eWttaKRWj6iA)
Title: Webhook Admission Server Authentication, Connection Categories, and Secure Topology
Summary
The text discusses webhook admission server authentication, categorizing connections as external or self-hosted. For external webhooks, manual kubeconfig configuration is necessary. A secure, portable, zero-config topology is achievable for self-hosted webhooks by integrating the webhook admission server as an extension API server, allowing it to leverage kube-apiserver's service and in-cluster authentication, authorization, and RBAC rules. This setup prevents service account token leaks from extension API servers to the webhook.