06 · KubernetesLab 39 / 59

Guided labkubernetes

Kubernetes RBAC & Service Accounts

Grant a namespace read-only access, give a workload its own identity, and verify with the cluster rather than by hoping.

Time: 50 min
Level: Intermediate
Objectives: 4 objectives
Cost: Free

Start the lab Challenge

Where this fits in the platform

Already built

Amazon EKS Cluster & Managed Node Group Provisioning

This lab adds

Workload identities that can do only what they need

Which lets you

Kubernetes Security Hardening (NetworkPolicies) & HPA

Before you start

You will need

kind or minikube
kubectl 1.28+

You do not need these already — the lab environment below provides them.

You will be able to

Assemble Role, RoleBinding, ClusterRole and ClusterRoleBinding correctly
Give a Pod an identity that is not the default ServiceAccount
Verify permissions with `auth can-i` instead of by trial

Cost — Free

— kind or minikube.

Nothing to pay in the browser. Open the terminal runs this against a simulated cloud — the same API calls and the same commands, with no account and no bill. The figure above applies only if you build it in your own.

How to clean up →

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.

Hands-on environment

Run this lab in a real terminal, free and in your browser. The environment is temporary and yours alone — break it as much as you like.

Open the terminal

Opens in Killercoda, in a new tab — keep this page open for the steps.

Run it on your own machine

Run this lab on your own machine. One command starts the environment, with everything the lab needs already installed:

You will need:

docker
kubectl
kind

git clone https://github.com/EgyKode/EgyKode-lab.git
cd EgyKode-lab
./egykode start k8s
./egykode shell

You need Docker and Git installed. Everything else runs inside the environment. The first start downloads it and takes a few minutes; later starts are seconds.

Not sure what you already have? Run: npm run doctor — it checks and changes nothing.

Anything you tick here is your own record. EgyKode cannot see inside that terminal, so the success criteria stay self-assessed even when the environment checks your work for you.

Four objects, two questions

Step 1 of 7

What you are proving: You can name the four RBAC objects and the two questions they answer between them

This step settles no success criterion on its own.

Object	Answers	Scope
`Role`	What may be done?	One namespace
`ClusterRole`	The same, cluster-wide	Whole cluster
`RoleBinding`	Who gets it?	One namespace
`ClusterRoleBinding`	Who gets it everywhere?	Whole cluster

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

What you are proving: You can write a Role that grants verbs on resources without naming any subject

Marking this settles success criterion 1.

yaml

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.

What you are proving: You can bind a Role to a subject, and see the binding as the thing that grants access

Marking this settles success criterion 1.

yaml

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

What you are proving: You can prove a subject is allowed in one namespace and refused in another, and check it against can-i

Marking this settles success criteria 1 and 3.

Terminal

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.

What you are proving: You can give a workload its own ServiceAccount instead of leaving it on default

Marking this settles success criterion 2.

yaml

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.

Terminal

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

What you are proving: You can explain why RBAC has no deny rule

Marking this settles success criterion 4.

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.

Terminal

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

What you are proving: You can audit the permissions a cluster already grants

This step settles no success criterion on its own.

Terminal

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.

Clean up#

Run this even if you did not finish.

Destructive — This removes real resources. Check which environment you are in first.

Terminal

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

Cost of this lab: Free — kind or minikube.

Success criteria

0 of 4

The concept behind it

Ready to try it without help?Do the challenge

Next up

Lab 39 of 59 on the project path

Kubernetes Security Hardening (NetworkPolicies) & HPADeny traffic between Pods by default, then allow only what the application needs — and scale it under load.Why next: Workload identities that can do only what they need47 minIntermediate

Previous: From Ingress to Gateway API