
_Source: [https://drive.google.com/a/redhat.com/file/d/12nC9S2fWCbeX\_P8nrmL6NgOSIha4HDNp](https://drive.google.com/a/redhat.com/file/d/12nC9S2fWCbeX_P8nrmL6NgOSIha4HDNp)_
In short: a secure topology makes use of all security mechanisms of API server aggregation and additionally requires no additional configuration.
Other topologies are possible but require additional manual configuration as well as a lot of effort to create a secure setup, especially when extension API servers like service catalog come into play. The topology above is zero-config and portable to every Kubernetes cluster.
### How do I write a webhook admission server?
Writing a full server complete with authentication and authorization can be intimidating. To make it easier, there are projects based on Kubernetes 1.9 that provide a library for building your webhook admission server in 200 lines or less. Take a look at the [generic-admission-apiserver](https://github.com/openshift/generic-admission-server) and the [kubernetes-namespace-reservation](https://github.com/openshift/kubernetes-namespace-reservation) projects for the library and an example of how to build your own secure and portable webhook admission server.
With the admission webhooks introduced in 1.9 we’ve made Kubernetes even more adaptable to your needs. We hope this work, driven by both Red Hat and Google, will enable many more workloads and support ecosystem components. (Istio is one example.) Now is a good time to give it a try!
If you’re interested in giving feedback or contributing to this area, join us in the [SIG API machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).