RBAC: Role and RoleBinding

Once requests are authenticated, you need a precise, auditable way to grant least-privilege permissions within a namespace instead of all-or-nothing access. Roles and RoleBindings define exactly who can do what.

Solution: Grant least-privilege access with a namespaced Role (verbs x resources) bound to a user or group via a RoleBinding.

Think of an office worker handed a keycard that opens only a few specific doors, and only inside one building on a large campus. A Role is the list of doors that card is allowed to open, the exact verbs and resources, while a RoleBinding is the moment security links that card to your name. Swipe the same card at another building and nothing happens, because both the card and the doors it opens live inside a single namespace.

The same cluster entities appear in every day's notes; the <== marks what this day touches.

RBAC answers "what can this identity do?" with two halves:

   ROLE         -> a set of PERMISSIONS (verbs on resources)  [namespaced]
   ROLEBINDING  -> ATTACHES a Role to a user / group / SA

A Role grants nothing by itself until a RoleBinding connects it to someone. Both are namespaced (cluster-wide equivalents = Day 24).

A single rule is the combination of which verbs are allowed on which resources in which apiGroups.

   verbs:      get list watch create update patch delete
   resources:  pods deployments services configmaps ...
   apiGroups:  "" (core: pods, svc), "apps" (deployments), etc.

Before binding permissions you need an identity, so generate the user's cert via the CSR flow from Day 21.

openssl genrsa -out krishna.key 2048
openssl req -new -key krishna.key -out krishna.csr -subj "/CN=krishna"
# submit CSR -> approve -> pull signed cert:
kubectl get csr krishna -o jsonpath='{.status.certificate}' | base64 -d > krishna.crt

The Role defines what may be done, here allowing read-only access to pods in the default namespace.

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

The RoleBinding is what actually grants the permissions, connecting the Role to a specific subject such as our user.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
  - kind: User
    name: krishna             # case-sensitive; must match CN
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role                  # Role or ClusterRole
  name: pod-reader            # must match the Role name above
  apiGroup: rbac.authorization.k8s.io

The same Role and RoleBinding can be created in one command each, without writing YAML.

kubectl create role pod-reader \
  --verb=get,list,watch --resource=pods -n default

kubectl create rolebinding read-pods \
  --role=pod-reader --user=krishna -n default

Confirm the binding works by impersonating the user and checking both an allowed and a denied action.

kubectl auth whoami
kubectl auth can-i list pods                    # as yourself (admin -> yes)
kubectl auth can-i list pods --as krishna       # -> yes (in default)
kubectl auth can-i delete pods --as krishna     # -> no (not granted)
kubectl auth can-i list pods --as krishna -n kube-system   # -> no (other ns)

A namespaced Role + RoleBinding lets amy work in dev but nowhere else.

A namespaced Role plus RoleBinding grants access in one namespace and nowhere else.

• Role = permissions, RoleBinding = who gets them. Both namespaced.
• A rule is verbs x resources x apiGroups; core group is "".
• Subject name must match the cert CN exactly (case-sensitive).
• Test with kubectl auth can-i <verb> <resource> --as <user>.

• [ ] Created the krishna user cert via CSR
• [ ] Created a pod-reader Role and a read-pods RoleBinding
• [ ] Verified access with --as krishna (allowed verb + denied verb)
• [ ] Confirmed the binding is scoped to its namespace only