In an event-driven system like Kubernetes, access to a resource can be restricted with RBAC. RBAC is not designed to execute a mandatory or exclusive lock on a particular resource. It is not impossible, but I found it complicated and error-prone.
Sometimes I want:
- The CronJob named
daily-reportis constant. No one can DELETE or UPDATE it.
- A workload
payrollcan be modified only by the actor with UID
aa-dd-f445-d-55-dand no one else.
- All resources with the label
site: for-funcan be updated, but not deleted.
Using RBAC is possible to partially meet requirements, but still when working in teams messing with operators, different automation tools, etc... Always something can go wrong.
Another option is ValidatingAdmissionWebhook. It can be used to say who can and can not access a certain resource. It is not about authentication or authorization, that part is done by Kubernetes. It is about access,
Klock as solution
Klock is simple implementation in effort to match above problems. It adds CRD that allows mandatory and exclusive locking. Matching which resource will be protected is done by matching labels. As well as which operation should be restricted.
For which resource ValidatingAdmissionWebhook(VAW) is applied is done in VAW configuration:
apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingWebhookConfiguration metadata: annotations: cert-manager.io/inject-ca-from: klock-system/klock-serving-cert name: klock-validating-webhook-configuration webhooks: - admissionReviewVersions: - v1 clientConfig: service: name: klock-webhook-service namespace: klock-system path: /validate-all failurePolicy: Fail name: klocks.rnemet.dev rules: - apiGroups: - '*' apiVersions: - '*' operations: - DELETE - UPDATE resources: - pods - deployments - secrets - configmaps sideEffects: None
Above configuration, you can read as for any api group and any version, whenever UPDATE or DELETE is about to be executed on a pod, a deployment, a secret, or a config map, ask VAW to validate it first.
apiVersion: klock.rnemet.dev/v1 kind: Lock metadata: name: lock-red-blue namespace: yellow spec: operations: - DELETE matcher: aura: blue
Now, if VAW has config as above
Lock is effective for every pod, deployment, secret, and configmap in the same namespace. It will deny deletion of any pod, deployment, secret, or configmap with the label
apiVersion: klock.rnemet.dev/v1 kind: Lock metadata: name: lockred spec: operations: - UPDATE - DELETE matcher: aura: red exclusive: name: johny
With exclusive locking
operations are forbidden for all except an actor named
johny, in this example. So, same as above just ignore
You can check out Klock and explore it more. See
/tests/ for more examples.