World map

 

BM

World K6: Guards

RBAC: roles and bindings

You will learn: how to give a person or a bot a job card for one zone, and nothing more.

Checked with Kubernetes 1.37 on 31 Oct 2026

The problem

Your CI bot only updates one thing: the shop Deployment. Today it holds a master key to the whole cluster. Which key should it carry?

Exactly what it needs, nothing more. That is least privilege: Give each worker only the keys their station needs. Nothing extra..

Watch

Kubernetes knows two kinds of “who”. People bring their own ID. Robots get a staff badge: a ServiceAccount: A staff badge for a robot: the identity a pod or a CI bot uses with the API.. Sort them.

Drag a card into a box. Or tap the card, then tap the box.

      Watch

      You are here: cluster kind-dev namespace default

      A Role: A job card: which verbs on which things, in one zone. A ClusterRole works in every zone. is a job card. It lists verbs, like patch, on things, like deployments. It works in one zone only.

      Try it

      A card does nothing alone. A RoleBinding: Pins a job card to a person or bot, in one zone. A ClusterRoleBinding pins it everywhere. pins it to a badge, in one zone. Wire the CI bot to deployer, in shop only.

      Connect wires until every answer matches. Give only what is needed.

      Who (plugs)

      • ci-bot (ServiceAccount · ci)
      • mei (user)

      Roles (sockets)

      • Role deployer · shop
        • get, list, patch · deployments
      • ClusterRole cluster-admin · whole cluster
        • * · *

      Wires (bindings)

      No wires yet. Nobody can do anything.

      Can they? (kubectl auth can-i)

      1. kubectl auth can-i patch deployments -n shop --as=system:serviceaccount:ci:ci-botnoshould be yes No wire gives this right.
      2. kubectl auth can-i patch deployments -n default --as=system:serviceaccount:ci:ci-botnoshould be no No wire gives this right.
      3. kubectl auth can-i get secrets -n shop --as=system:serviceaccount:ci:ci-botnoshould be no No wire gives this right.
      Ask your own question
      kubectl auth can-i get pods -n shop --as=system:serviceaccount:ci:ci-botno

      Watch

      A Role works in one zone. A ClusterRole works in every zone, and for things with no zone, like nodes. Sort these.

      Drag a card into a box. Or tap the card, then tap the box.

          Try it

          Now in the terminal. Apply the job card. Then pin it to ci-bot with a RoleBinding.

          You are here: cluster kind-dev namespace default
          Time: +0s (sped up)

          Predict

          RBAC has no “deny” rule. The bot has two RoleBindings. One allows deleting pods. One does not. Can it delete pods?

          You did it!

          You can now give a bot a job card for one zone.

          Go deeper (optional)

          A RoleBinding may point at a ClusterRole. Then that card works only in the binding’s zone. Built-in ClusterRoles: view, edit, admin, cluster-admin. Pods get a short-lived ServiceAccount token. Set automountServiceAccountToken: false when the app never calls the API.

          Real mission

          1. kubectl create serviceaccount ci-bot
          2. kubectl create role deployer --verb=get,list,patch --resource=deployments
          3. kubectl create rolebinding ci-bot-deployer --role=deployer --serviceaccount=default:ci-bot
          4. kubectl describe rolebinding ci-bot-deployer

          0 of 4 steps done · Your ticks are saved.