Cyber Security Academy · Les

RBAC en serviceaccounts

Toegang tot clusters vergrendelen

Les 2 van 413 stappen

RBAC en serviceaccounts is een gratis Cyber Security Academy-les op CoddyKit. Dit is les 2 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Cyber Security Academy. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Cyber Security Academy bevat in totaal 4 lessen.

RBAC bepaalt alles

Rolgebaseerde toegangscontrole (RBAC) bepaalt welke identiteiten welke acties op welke resources in een cluster mogen uitvoeren. Elke API-aanroep wordt op basis van RBAC geautoriseerd. Verkeerd geconfigureerde RBAC is de belangrijkste oorzaak van escalatie van rechten binnen een cluster.

Onderwerpen: gebruikers, groepen, serviceaccounts.
Rollen koppelen acties aan resources.
Bindings koppelen onderwerpen aan rollen.

Rollen tegenover ClusterRoles

Er zijn twee reikwijdtes.

Role + RoleBinding: rechten binnen een namespace.
ClusterRole + ClusterRoleBinding: rechten voor het hele cluster.

Een ClusterRoleBinding naar cluster-admin geeft volledige controle. Deze aan een serviceaccount toekennen is een veelgemaakte, gevaarlijke fout.

Tokens van serviceaccounts

Elke pod draait onder een serviceaccount en koppelt standaard het token daarvan. Dat token is een bearer-referentie die de RBAC-rechten van het account bevat. Als de pod wordt gecompromitteerd, is het token dat ook.

Moderne clusters geven kortlevende, aan een doelgroep gebonden geprojecteerde tokens uit, maar oude langlevende tokens uit Secrets zijn nog steeds aanwezig.

# Inspect which service account a pod uses
kubectl get pod web -o jsonpath='{.spec.serviceAccountName}'

Je rechten inventariseren

Nadat je een token hebt buitgemaakt, is de eerste stap te bepalen wat je ermee kunt doen. Kubernetes biedt hiervoor een API voor zelfcontrole.

# What can this token do?
kubectl auth can-i --list

# Specific checks
kubectl auth can-i create pods
kubectl auth can-i create clusterrolebindings

Gevaarlijke combinaties van rechten

Bepaalde werkwoorden zijn primitieve middelen voor escalatie, zelfs zonder cluster-admin.

create pods: plan een geprivilegieerde pod of hostPath-pod in om te ontsnappen.
create pods/exec: voer opdrachten uit in bestaande pods.
get/list secrets: lees referenties in het hele cluster.
create rolebindings/clusterrolebindings: koppel jezelf aan de beheerder.
escalate / bind-werkwoorden: verleen rechten die je zelf niet hebt.
impersonate: handel als een ander, meer geprivilegieerd onderwerp.

Escalatie via het aanmaken van pods

Als een serviceaccount pods kan maken, kan het vaak de node overnemen. De aanvaller plant een pod in die het hostbestandssysteem koppelt of geprivilegieerd draait, en leest vervolgens node-referenties of ontsnapt.

# Pod spec snippet that mounts the host root
# volumes: hostPath path: /  ;  container mounts it at /host
kubectl apply -f evil-pod.yaml
kubectl exec -it evil -- chroot /host bash

Escalatie via binding

Als je (cluster)rolebindings kunt maken, kun je je serviceaccount rechtstreeks aan cluster-admin koppelen. Kubernetes beschermt dit met de werkwoorden bind/escalate, maar verkeerd geconfigureerde rollen staan dit soms toe.

# Bind a service account to cluster-admin (if permitted)
kubectl create clusterrolebinding pwn \
  --clusterrole=cluster-admin \
  --serviceaccount=default:web

Misbruik van impersonatie

Met het werkwoord impersonate kan een onderwerp handelen als elke gebruiker, groep of serviceaccount. Een identiteit met ruime impersonatierechten beschikt in feite over elke machtiging in het cluster.

# Act as a privileged user via impersonation
kubectl get secrets --as=admin-user --as-group=system:masters

RBAC controleren

Verdedigers moeten RBAC voortdurend controleren op risicovolle toekenningen.

Zoek onderwerpen die aan cluster-admin zijn gekoppeld.
Markeer jokertekens voor werkwoorden en resources (*).
Detecteer rechten om Secrets te lezen en pods te maken op accounts die geen beheerder zijn.

# Tools to audit RBAC
kubectl-who-can create pods
rbac-tool analysis
rakkess --as=system:serviceaccount:default:web

Serviceaccounts verharden

Pas het principe van minimale rechten toe op identiteiten.

Stel automountServiceAccountToken: false in wanneer de pod geen API-toegang nodig heeft.
Geef elke workload een speciaal daarvoor bestemd serviceaccount met minimaal bereik.
Gebruik het default-serviceaccount niet voor echte workloads.
Gebruik kortlevende geprojecteerde tokens met doelgroepen; roteer en koppel ze.
Koppel workloads nooit aan cluster-admin.

RBAC ethisch testen

Gebruik bij het beoordelen van RBAC bij voorkeur niet-destructieve controles (auth can-i, dry-run) in plaats van daadwerkelijk cluster-admin-bindings te maken in productie. Als je escalatie moet aantonen, beperk dit dan tot een testnamespace en verwijder alle bindings of pods die je hebt aangemaakt.

Rapporteer de exacte rollen en bindings die de escalatie mogelijk maakten, zodat ze verder kunnen worden beperkt.

Korte controle

Controleer je begrip van RBAC.

Beantwoord dit in de interactieve les

Samenvatting

Je hebt geleerd hoe RBAC en serviceaccounts de toegang tot clusters regelen en in gevaar kunnen brengen.

RBAC koppelt onderwerpen aan werkwoorden op resources; cluster-admin geeft volledige controle.
Pods koppelen SA-tokens; auth can-i maakt hun bereik zichtbaar.
create-pods, binding, secret-read en impersonate zijn primitieve middelen voor escalatie.
Accounts met minimale rechten en uitgeschakelde automatische koppeling verharden het cluster.

Volgende onderwerp: podbeveiliging en netwerkbeleid.

Gratis beginnen

Leer Cyber Security Academy met een AI-tutor — gratis

Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.

Cursussen: 76
Lessen: 303

Gratis beginnen met leren Bekijk de volledige cursus

Veelgestelde vragen

Is de les “RBAC en serviceaccounts” gratis?

Ja — je kunt hier op het web alle 3 lessen van het leerpad Cyber Security Academy, waaronder “RBAC en serviceaccounts”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus Cyber Security Academy bevat in totaal 4 lessen.

Wat leer ik in “RBAC en serviceaccounts”?

Toegang tot clusters vergrendelen Je oefent met Cyber Security Academy door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.

Heb ik ervaring nodig om met Cyber Security Academy te beginnen?

Ervaring vooraf is niet nodig. Cyber Security Academy op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 2 van 4.

Hoe lang duurt de les “RBAC en serviceaccounts”?

De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.

Kan ik code schrijven en uitvoeren in deze les over Cyber Security Academy?

Ja. Elke les over Cyber Security Academy bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.

Alle lessen in deze cursus

← Terug naar Cyber Security Academy