Problem
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-report
is constant. No one can DELETE or UPDATE it. - A workload
payroll
can be modified only by the actor with UIDaa-dd-f445-d-55-d
and no one else. - All resources with the label
site: for-fun
can be updated, but not deleted.
Solution
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,
granular 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.
Configuring ValidatingAdmissionWebhook
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.
Mandatory locking
See example:
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 aura: red
.
Exclusive locking
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 Lock
for johny
.
Conclusion
You can check out Klock and explore it more. See /tests/
for more examples.
Top comments (0)