Kubernetes RBAC & Service Accounts

The scenario#

Every workload in the cluster runs as the default ServiceAccount, and its token is mounted into every Pod. Anything that reaches a container reaches the Kubernetes API with it.

NetworkPolicies control what a Pod can talk to. RBAC controls what it can do, and you need both.

1. Four objects, two questions#

Permissions and subjects are deliberately separate, which is what lets one ClusterRole be bound differently in twenty namespaces.

2. A Role, which names nobody#

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-a
  name: pod-reader
rules:
  - apiGroups: [""]                 # "" is the core API group
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]

pods/log is a subresource and a separate grant — get pods does not include reading their logs, which surprises people.

3. A RoleBinding, which names the subject#

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: team-a
  name: team-a-read
subjects:
  - kind: ServiceAccount
    name: viewer
    namespace: team-a
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

4. Verify against the cluster#

kubectl auth can-i list pods -n team-a --as system:serviceaccount:team-a:viewer   # yes
kubectl auth can-i list pods -n team-b --as system:serviceaccount:team-a:viewer   # no
kubectl auth can-i delete pods -n team-a --as system:serviceaccount:team-a:viewer # no
kubectl auth can-i --list -n team-a --as system:serviceaccount:team-a:viewer

--as asks the API server to evaluate the real policy. Reading YAML tells you what you meant; this tells you what the cluster will actually do, and they differ more often than anyone expects.

5. A workload with its own identity#

apiVersion: v1
kind: ServiceAccount
metadata:
  name: api
  namespace: team-a
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  template:
    spec:
      serviceAccountName: api
      automountServiceAccountToken: false    # it never calls the API

That last line matters more than it looks. Kubernetes mounts an API token into every Pod by default. An application that never talks to the API has no use for one — but an attacker who reaches the container does.

kubectl exec deploy/api -- ls /var/run/secrets/kubernetes.io/serviceaccount 2>&1
# No such file — correct

6. Two properties that surprise people#

RBAC is purely additive; there is no deny rule. A subject can do the union of everything its bindings grant. You restrict by not granting — so when someone has too much access, the fix is finding the extra binding, never adding a denial.

A namespaced RoleBinding may reference a ClusterRole. This is the common pattern: define view or edit once cluster-wide, bind it per namespace, and the permissions apply only inside the binding's namespace.

kubectl get clusterrole view edit admin
kubectl create rolebinding team-a-view --clusterrole=view \
  --serviceaccount=team-a:viewer -n team-a --dry-run=client -o yaml

7. Audit what you already have#

kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") | .metadata.name'

Run that on any cluster you inherit. A ServiceAccount bound to cluster-admin is the most common over-grant in existence, and it is usually there because something did not work once.

When it goes wrong#

auth can-i says no when the YAML looks right

Check the ServiceAccount namespace in subjects — a RoleBinding can reference a subject from another namespace, and a mismatch fails silently.

Permissions work in one namespace only

That is a RoleBinding doing its job. Cluster-wide needs a ClusterRoleBinding.

Forbidden reading logs despite get pods

pods/log is a separate resource. Add it to the rule.

Removing a binding does not revoke access

Another binding still grants it. RBAC is additive — search all bindings for the subject.

Clean up#

Run this even if you did not finish.

kubectl delete namespace <ns> --ignore-not-found
kubectl get all -A | grep -v kube-system

Cost of this lab: Free — kind or minikube.