Minimizing an Over-Broad RBAC Role
The most likely RBAC task you will be handed is not writing a Role from nothing - it is taking one that says * and leaving it saying as little as possible. This guide does exactly that, and proves the result by testing what is still allowed and what is now refused.
Cluster Hardening Guide 9 of 40 Intermediate
- Kubernetesapiserver v1.36.4, kubelet v1.36.3
- Runtimecontainerd 2.2.6
- CNICilium 1.18.1
- Built withkubeadm v1.36.3
- TimeAbout 18 min
kubectl create role --resource='*' writes apiGroups: [""], so its wildcard covers the core API group only. That is demonstrated here rather than assumed.
- Host kernel7.0.0-29
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA6001 | 192.168.0.46 | Ubuntu 26.04 LTS | Control Plane Node (tainted NoSchedule) | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE01 | 192.168.0.47 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE02 | 192.168.0.48 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this because the RBAC task you are likely to get is not writing a Role from nothing - it is cutting one down. This matters because a wildcard rule grants more than it appears to, and replacing it means deleting something rather than only adding.
- starting from a grant with three wildcards in a single rule
- asking what it can actually do, and getting one answer you would not have expected
- writing down what the workload needs before changing anything at all
- replacing it with two narrow Roles, and noticing what had to be deleted
- proving it in both directions, including the refusal itself
Before you start
- guide 4 - the other half of exposure.
-
The grant you have been handed
-
What it can actually do
-
Decide what the workload needs, before writing anything
-
Replace it, and notice what had to be deleted
-
Prove it, in both directions