Challengekubernetes
Kubernetes RBAC & Service Accounts — Challenge
Grant a namespace read-only access, give a workload its own identity, and verify with the cluster rather than by hoping.
- Time
- 25 min
- Level
- Intermediate
- Objectives
- 4 objectives
- Cost
- Free
Before you start
You will need
- kind or minikube
- kubectl 1.28+
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
You are done when
0 of 4
The goal#
Achieve the same outcome as Kubernetes RBAC & Service Accounts, from an empty starting point, without the steps.
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.
What must be true when you are done#
- A subject can list Pods in one namespace and is refused in another.
- A workload runs as a dedicated ServiceAccount, not
default. kubectl auth can-i --listoutput matches what you intended.- You can explain why RBAC has no deny rule.
Rules#
- Do not open the guided lab until you are finished, or until the same problem has held you up for 20 minutes.
- Documentation is allowed and encouraged.
- Verify every criterion with a command whose output you can read.
If you get stuck#
- What did you expect, exactly?
- What happened instead — the error text, not a paraphrase?
- Which layer is that error from?
- What is the smallest command that proves the layer below is fine?
The concept behind it
Next up
Lab 39 of 58 on the project path