RBAC model for Kubernetes assumes existing of:

  • service accounts
  • users
  • groups

when you define RoleBinding and 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:node vs 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...

some maybe 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
- 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