RBAC (CKA)
Roles, bindings and subjects: who may do what, and how to prove it.
An interactive Kubernetes lesson: 21 steps, about 32 minutes, on a live simulation in your browser.
The shop runs in the shop namespace: three api pods behind a Service, called by web. It is healthy, and it will stay healthy for this whole lesson unless somebody is allowed to break it.
Right now anybody is. The team shares one kubeconfig, the admin one that came with the cluster. Its identity, kubernetes-admin, belongs to the group system:masters, and the API server lets that group through without checking any rule.
What you will learn
Everyone is admin
- One kubeconfig, shared by everyone: Every request to the API server carries an identity. Access control is only as fine-grained as the identities you hand out.
- Jane gets her own identity: Authentication says who you are. Authorization says what you may do. A new identity may do nothing.
Role and RoleBinding
- A Role: a list of what is allowed: A Role is a list of allowed verb-and-resource pairs in one namespace. It names no people.
- A RoleBinding: who gets it: A RoleBinding connects subjects to one role: who gets what, in the namespace where the binding lives.
- Only what is listed: RBAC is an allow-list. Anything not explicitly granted is denied, and there is no such thing as a deny rule.
- Logs are a separate resource: A subresource such as pods/log or pods/exec is a separate resource in RBAC. Access to pods does not include it.
- The same request, next door: A RoleBinding grants only inside its own namespace, whatever it points at.
Beyond one namespace
- ClusterRole and ClusterRoleBinding: ClusterRole plus ClusterRoleBinding means everywhere: cluster-scoped resources, and every namespace at once.
- A ClusterRole inside a RoleBinding: The role says what. The binding says who and where. Define a ClusterRole once and bind it namespace by namespace.
- Four roles you get for free
ServiceAccounts as subjects
- The third subject: a ServiceAccount: Three kinds of subject: User and Group come from the credential. A ServiceAccount is an object, and its identity includes its namespace.
- Break it: right name, wrong namespace
- resourceNames: one object, not all: resourceNames narrows a rule to named objects. It works for requests that name one object, not for listing.
Prove it, break it
- Prove it with auth can-i: RBAC is not done until you have asked the API server: kubectl auth can-i VERB RESOURCE --as WHO -n WHERE.
- Break it: one binding too many: RBAC only adds. Your access is the union of every binding that names you, and the only way to remove access is to remove a binding.
- Where users come from
- Drill: create a Role
- Drill: bind it to a ServiceAccount
- Drill: verify as someone else
Recap & playground
- Cheat sheet
- Playground