Topic outline

  • About RBAC (Role Based Access Control)

    RBAC in K8s is activated by default and helps to provide access to resources (objects) like namespaces, pods, services, etc. to those Subjects or Entities like users, group or service accounts who need access to some resources and deny access to other resources who do not need access to them. RBAC increases security in K8s projects and shall be defined through a governance model in each organisation (but in the Theorie, you know we are all admins ;-)).

    RBAC is implemented through Role, ClusterRole, RoleBinding, and ClusterRoleBinding.


    A Role defines what you or a subject can do to a set of resources, like get, set, delete, etc.A Role contains a set of rules which define a set of permissions. Roles are used to assigning permissions to resources on the namespace level.


    Similar to Role, ClusterRole can grant permissions on the Cluster Level such as giving resource permissions across all namespaces in the cluster.

    RoleBinding and ClusterRoleBinding

    RoleBinding and ClusterRoleBinding are used to grant permissions and privileges to Subjects or Entities on the namespace (project RoleBinding) level or on the cluster level (ClusterRoleBinding).

    • Create Service Accounts, Roles and Role Bindings

      We create a new namespace myapp and a new custom ServiceAccount mysa, create a new role podreader with the permission to get and list pods and create a rolebinding mypodviewer  to bind the ServiceAccount to the role podreader in the namespace myapp.

      k get clusterroles | wc -l
      # 62
      k get clusterroles
      k describe clusterrole view
      k describe clusterrole view | grep pods
      # the view role allows your application access to many other resources such as deployments and services.
      k create namespace myapp
      k -n=myapp create serviceaccount mysa
      k -n myapp create role podreader --verb=get --verb=list --resource=pods
      k -n myapp describe role/podreader
      # nice, the role podreader can only view now, but we need to attach the role podreader to our application, represented by the service account myapp.
      k -n myapp create rolebinding mypodviewer --role=podreader --serviceaccount=myapp:mysa
      k -n myapp describe rolebindings mypodviewer
      k -n myapp auth can-i --as=system:serviceaccount:myapp:mysa list pods
      # yes :-)
      k -n myapp auth can-i --as=system:serviceaccount:myapp:mysa list services
      # no :-)

      We extend now our alpine pod with the key serviceAccountName and the value mysa, apply the change and run a shell in the alpine-pod, get the toke belonging to the mysa ServiceAccountand use it to list the pods in the default namespace and the myapp namespace to see the differences:
      kn myapp
      cat alpine-pod-service-account.yaml
      k apply -f alpine-pod-service-account.yaml
      k describe pod alpine-sa
      k get sa
      k get secrets
      k exec -it alpine-sa -- sh
      apk add curl
      TOKEN=$(cat /run/secrets/
      curl -H "Authorization: Bearer $TOKEN" https://node1:6443/api/v1/namespaces/default/pods/ --insecure
      curl -H "Authorization: Bearer $TOKEN" https://node1:6443/api/v1/namespaces/myapp/pods/ --insecure
      # what works, what doesn't work?