Consider using Admission Webhooks to validate crds #2
Description
Admission controllers sound pretty awesome,
ex blog post:
Admission controllers are used for intercepting the requests to Kubernetes API, such as creating a Deployment, a new ConfigMap, etc. In other words, any Kubernetes object can be caught with admission controllers and modified before persisting them in the database. They can also be used to reject the objects, and many admission controllers might be chained to perform a set of checks. In short, admission controllers can be categorized as “validating” which accepts or rejects an object, and they can also be “mutating” which modifies the object before persistence.
The ability to intercept the objects before saving them allows enforcing some rules. For instance, you might want to let only a single domain of Docker images to pull, or you might enforce a naming scheme for objects, prevent some labels from being used, or add sidecar containers to each of your containers. The main reason why admission controllers are useful is that you can continue interacting with API server with proper credentials, and you do not have to create an additional proxy layer or a handler, and you maintain a fewer number of and smaller components, and it becomes easier to modify and swap them.
Link to official docs, Using Admission Controllers
The problem is that to create our own plugin admission controllers we need to
- Compile them into the kube-apiserver
- They are only configurable when the apiserver starts up
So a no-go when it comes to managed k8s.
This is where ValidatingAdmissionWebhook and MutatingAdmissionWebhook comes into play.
Two features, Admission Webhooks (beta in 1.9) and Initializers (alpha), address these limitations. They allow admission controllers to be developed out-of-tree and configured at runtime.
See official docs, https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/