Lesson 4.2: Kubernetes RBAC and service accounts
Every pod in Kubernetes runs as a service account, and the cluster's API decides what that account may do through role-based access control (RBAC): Roles and ClusterRoles list permissions, RoleBindings and ClusterRoleBindings give them to users, groups and service accounts. If the web pod's account is a cluster administrator, a single vulnerability in the website hands over the whole cluster. In the lab you find exactly that, a 'temporary' debugging binding, prove what it allows with kubectl auth can-i, remove it, and replace it with a narrow Role.
17 min
You will learn to
- Explain service accounts and RBAC objects
- Read ClusterRoleBindings
- Test permissions with kubectl auth can-i
- Find which pod uses a service account
- Replace a broad binding with a narrow Role
Key terms
- Service account
- The identity a pod uses to talk to the Kubernetes API; its token is mounted into the pod.
- Role / ClusterRole
- A list of allowed verbs on resources, in one namespace / cluster-wide.
- RoleBinding / ClusterRoleBinding
- Gives a Role or ClusterRole to users, groups or service accounts, in a namespace / everywhere.
- cluster-admin
- The built-in ClusterRole with every permission on every resource.
- kubectl auth can-i
- Asks the API whether an identity may perform an action.
← False positives and tuning · All lessons · Encrypting files with AES →