RBAC model for Kubernetes assumes existing of:
- service accounts
when you define
ClusterRoleBinding you are pointing them into Subject.
I'm fine with existing service accounts but what about users and groups, I cannot figure out how you define them in k8s. After some research I found that concept of users and groups is defined in k8s apiserver, it extract them from different authentication methods. Let's find out how k3d cluster use them to authenticate and grant permission for worker nodes. Authentication model is based on SSL x509 certificates.
ClusterRoleBinding rule which covers permission for worker node can be:
$ kubectl get clusterrolebindings system:node NAME ROLE AGE system:node ClusterRole/system:node 6m5s
to get certificate from worker node just copy it locally from docker container:
$ docker cp k3d-sample-agent-0:/var/lib/rancher/k3s/agent/client-kubelet.crt .
and try to extract
system:node from it:
$ openssl x509 -in client-kubelet.crt -noout -text | grep "system:node" Subject: O=system:nodes, CN=system:node:k3d-sample-agent-0$
ok, but it didn't match
system:nodes, this is somekind of exception mention in Using Node Authorization:
Kubelets outside the system:nodes group would not be authorized by the Node authorization mode...
client-k3s-controller.crt copied from docker, which should match:
$ kubectl get clusterrolebindings system:k3s-controller -o yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding ... subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: system:k3s-controller $ openssl x509 -in client-k3s-controller.crt -noout -text | grep system:k3s-controller Subject: CN=system:k3s-controller
matched, user is taken from CN (common name), diggin a little bit deeper you can find how user/group is mapped x509.go:
- user from: CN
- group from: OU