Cheat notes · Module 05 · Share the cluster

Two teams, one cluster: namespaces and RBAC

A five-minute review for when you have done this module and want it back in your head. Open the full module for the steps and the lab, or the full text to print.

The idea

RBAC is additive: a subject may do whatever any of its bindings allows. A RoleBinding grants a role inside its own namespace, even a ClusterRole; a ClusterRoleBinding grants it everywhere. Prove the boundary by asking the API server with kubectl auth can-i --as, especially the questions that must say no.

Remember

Subjects: users and groups come from the login and are not objects; ServiceAccounts are objects, for programs.
The binding sets the scope, not the role. view bound with a RoleBinding stops at the namespace.
No deny rules. Remove access by removing a binding.
The kit per team: RoleBinding team-view (group, ClusterRole view), ServiceAccount deployer with a Role, workload ServiceAccount with automountServiceAccountToken: false.
view leaves out Secrets on purpose.
The deployer may not touch Secrets, roles, bindings, quotas, limits or network policies.
kubectl apply does not delete: removing a binding from Git leaves it in the cluster until you delete it.

Pitfalls

"ClusterRole, so ClusterRoleBinding": the team can now read every namespace. Nothing warns.
Testing only that the right people get in. Over-permission never produces an error; ask the no questions too.
Testing a ServiceAccount with --token on kind: the client certificate wins, so you test yourself. Use --as.

Commands

`kubectl auth whoami`	Who the API server thinks you are
`kubectl auth can-i list pods -n NS --as=alice --as-group=team-checkout`	Ask as someone else
`kubectl auth can-i create deployments -n NS --as=system:serviceaccount:NS:deployer`	Ask as a ServiceAccount
`kubectl auth can-i --list -n NS --as=SUBJECT`	Everything a subject may do
`kubectl get clusterrolebindings -o wide`	Cluster-wide grants and their subjects

tenants/checkout/rbac.yaml (first object)

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-view
  namespace: checkout-dev
subjects:
  - kind: Group
    name: team-checkout
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

Test yourself

Answer in your head first, then open the answer.

A RoleBinding in checkout-dev refers to ClusterRole view. Where does it grant access?

In checkout-dev only.

How do you take a permission away?

Remove the binding or the rule that grants it; RBAC has no deny.

Why automountServiceAccountToken: false on the workload?

So the container holds no API credential an attacker could use.

You deleted a ClusterRoleBinding's file and the access is still there. Why?

kubectl apply never deletes; delete the object too.

Where module 05 leaves you: Two tenants, checkout-dev and catalog-dev, each with a quota, defaults, a running app and an rbac.yaml. Members of team-checkout can read checkout-dev and nothing in catalog-dev, and the reverse. Neither team can read Secrets. The checkout and catalog pods carry no API token.