This is a Validating Admission Webhook for k8s. It is validating namespaces create/delete operations, checking name prefixes. The intent is to let the user1 ServiceAccount be able to create/delete any namespace with names starting with user1-
To deploy the validating admission webhook, just run this one-liner:
kubectl apply -f https://raw.githubusercontent.com/lalyos/k8s-ns-admission/master/deploy-webhook-job.yaml
Most admission webhook examples requires you to do a lot of manual steps regarding certificate creation. That is all taken care by the job:
- creates a service account to give certificate relatades access to the job
- creates a certificate req for the webhook's https endpoint
- let api-server sign the csr
- save the cert/key into a secret
- create a svc/deployment for the webhook (using the generated cert as mounted volume)
- creates the ValidatingWebhookConfiguration
- tests the webhook by creating and deleteing a ns "delme"
For k8s workshops you might want to provide isolated workspace for each participant. Let's say you create a separate namespace for each of them. To restrict them to only that specific namespace, we can use RBAC. You can create a ServiceAccount with an appropriate Role to give full access to namespaced resources (pod,deployment,svc,job ...)
But how can they learn to work with namespaces? We might want to give access to user1 to create/delete any namespace with names starting with user1-. Unfortunately RBAC Roles doesnt support pattern based roles. For details see: k8s#56582
Then you might think, lets just give them 1 single predefined ns to create, like user1-play. Therefoe lets create a ClusterRole which gives access to namespaces resources restricted by resourceNames: ["user1-play"]. Unfortunately its not possible, as there is a sidenote in RBAC docs
Notably, if resourceNames are set, then the verb must not be list, watch, create, or delete
code is proudly stolen from:
relevant docs: