Certificates, kubeconfig Contexts and RBAC from Scratch

Why this matters

Half of all "cannot do X" errors in the exam are RBAC, and the other half are pointing at the wrong cluster. Both are five-minute fixes once you see the layers separately. The exam loves this topic because it rewards precision: exactly the needed verbs, exactly the needed resources, nothing borrowed from cluster-admin.

Concepts

Identity starts with a key and a certificate signing request. Generate a private key, build a CSR with the username in CN and the groups in O, sign it against the cluster CA (or have the cluster sign it), and you have an identity the API server trusts. The kubeconfig file then bundles three things per context: the cluster (server plus CA), the user (certificate plus key), and the namespace. kubectl config use-context switches the live triple; kubectl config get-contexts shows the table. Never hand-edit these files when a command exists.

RBAC grants verbs on resources inside rules, binds rules to subjects, and stops at namespace boundaries unless you use the cluster-scoped kinds. A Role holds rules for one namespace; a RoleBinding attaches them to users, groups or service accounts in that namespace. ClusterRole plus ClusterRoleBinding is the cluster-wide pair. The API server denies by default, so every denial means no bound rule matched: read the resource, the verb and the namespace from the error, then write exactly that rule.

Worked example

A read-only auditor for one namespace, no cluster-admin anywhere near it:

# identity
openssl genrsa -out auditor.key 2048
openssl req -new -key auditor.key -out auditor.csr -subj "/CN=auditor"
# sign with the cluster CA, then build the context
kubectl config set-credentials auditor \
  --client-certificate=auditor.crt --client-key=auditor.key
kubectl config set-context auditor-ctx \
  --cluster=kubernetes --user=auditor --namespace=demo
# least privilege: get and list pods in demo only
kubectl create role pod-reader \
  --verb=get,list --resource=pods -n demo
kubectl create rolebinding auditor-read \
  --role=pod-reader --user=auditor -n demo
kubectl auth can-i list pods -n demo --as=auditor
# yes
kubectl auth can-i delete pods -n demo --as=auditor
# no

kubectl auth can-i --as is the exam superpower: it tests any subject's rights without switching identity.

Exam notes

Forgetting the namespace binds the rule in default while the workload lives elsewhere: namespace mismatch is the top RBAC trap. --as checks rights but does not authenticate as that user for real calls, which is exactly what you want for testing. And service accounts need the same treatment: bind roles to them explicitly instead of widening defaults.