RBAC staat voor Role-Based Access Control. In Kubernetes gebruik je RBAC om vast te leggen welke gebruiker of ServiceAccount welke acties op welke resources mag uitvoeren.
RBAC is vooral belangrijk zodra meerdere applicaties, pipelines of beheerders hetzelfde cluster gebruiken. Zonder RBAC geef je al snel te veel rechten weg, bijvoorbeeld aan een CI-pipeline of een applicatie die alleen pods hoeft te lezen maar ook Secrets zou kunnen ophalen.
- Gebruik een Role voor rechten binnen één namespace.
- Gebruik een ClusterRole alleen voor clusterbrede rechten of voor resources die niet namespaced zijn.
- Koppel rechten altijd via een aparte ServiceAccount of gebruiker, niet aan `default`.
- Begin met de kleinst mogelijke set rechten en breid alleen uit wanneer dat echt nodig is.
Wanneer gebruik je RBAC / een ClusterRole?
RBAC gebruik je zodra meerdere identiteiten in je cluster verschillende taken hebben. Door Roles, bindings en ServiceAccounts klein en expliciet te houden, voorkom je dat applicaties of automatisering meer rechten krijgen dan nodig is.
Gebruik een ClusterRole alleen als je rechten nodig hebt op niet-namespaced resources of op meerdere namespaces tegelijk. Voorbeelden zijn:
- Nodes lezen: een cluster observer of auditor moet mogelijk alle nodes kunnen uitlezen.
- Ingress- of gatewaycontrollers: controllers die resources in meerdere namespaces verwerken, hebben vaak bredere rechten nodig.
- Platformbeheer: beheerders of operators die clusterbrede componenten beheren.
Gebruik ClusterRoleBindings spaarzaam. Een fout daarin heeft direct clusterbrede impact.
Bepaal eerst wat je nodig hebt
- Role + RoleBinding: gebruik dit als een applicatie alleen in één namespace hoeft te werken.
- ClusterRole + RoleBinding: gebruik dit als je een bestaande ClusterRole wilt hergebruiken, maar de rechten toch tot één namespace wilt beperken.
- ClusterRole + ClusterRoleBinding: gebruik dit alleen als de rechten echt clusterbreed nodig zijn.
Veel workloads hebben aan een gewone Role genoeg. Dat is meestal ook de veiligste keuze.
Een eenvoudig RBAC-voorbeeld
Stap 1
Maak een manifestbestand aan op je server/computer, bijvoorbeeld:
nano rbac-demo.yamlPlaats de volgende inhoud in het bestand:
apiVersion: v1
kind: Namespace
metadata:
name: kb-rbac-test
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: pod-reader
namespace: kb-rbac-test
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: kb-rbac-test
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: pod-reader
namespace: kb-rbac-test
subjects:
- kind: ServiceAccount
name: pod-reader
namespace: kb-rbac-test
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pod-readerSla de wijzigingen op en sluit het bestand (ctrl + x > y > enter).
Stap 2
Maak de namespace, ServiceAccount en RBAC-resources aan:
kubectl apply -f rbac-demo.yamlDeze ServiceAccount krijgt nu alleen leesrechten op pods binnen de namespace `kb-rbac-test`.
Controleer de rechten van een ServiceAccount expliciet
Stap 1
Controleer of de ServiceAccount pods in de eigen namespace mag lezen:
kubectl auth can-i list pods \
--as=system:serviceaccount:kb-rbac-test:pod-reader \
-n kb-rbac-testDe verwachte uitkomst is `yes`.
Stap 2
Controleer daarna of dezelfde ServiceAccount géén Secrets mag lezen:
kubectl auth can-i list secrets \
--as=system:serviceaccount:kb-rbac-test:pod-reader \
-n kb-rbac-testDe verwachte uitkomst is `no`.
Stap 3
Controleer ook of dezelfde ServiceAccount niet zomaar pods uit een andere namespace mag lezen:
kubectl auth can-i list pods \
--as=system:serviceaccount:kb-rbac-test:pod-reader \
-n defaultOok hier verwacht je `no`. Daarmee is zichtbaar dat een namespaced Role niet automatisch buiten de eigen namespace geldt.