Cyber Security Academy · Lektion

RBAC und Servicekonten

Clusterzugriff absichern

RBAC und Servicekonten ist eine kostenlose Cyber Security Academy-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Cyber Security Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Cyber Security Academy-Kurs umfasst insgesamt 4 Lektionen.

RBAC steuert alles

Die rollenbasierte Zugriffskontrolle (RBAC) entscheidet, welche Identitäten welche Aktionen auf welchen Ressourcen in einem Cluster ausführen dürfen. Jeder API-Aufruf wird anhand von RBAC autorisiert. Fehlkonfiguriertes RBAC ist die häufigste Ursache für eine Rechteausweitung innerhalb des Clusters.

Subjekte: Benutzer, Gruppen, Service Accounts.
Rollen verknüpfen Verben mit Ressourcen.
Bindings verbinden Subjekte mit Rollen.

Roles vs ClusterRoles

Es gibt zwei Geltungsbereiche.

Role + RoleBinding: auf den Namespace beschränkte Berechtigungen.
ClusterRole + ClusterRoleBinding: clusterweite Berechtigungen.

Eine ClusterRoleBinding auf cluster-admin gewährt vollständige Kontrolle. Eine solche Bindung an einen Service Account ist ein häufiger, gefährlicher Fehler.

Service-Account-Token

Jeder Pod wird unter einem Service Account ausgeführt und bindet standardmäßig dessen Token ein. Dieses Token ist ein Bearer-Credential und repräsentiert die RBAC-Berechtigungen des Kontos. Ist der Pod kompromittiert, ist es auch das Token.

Moderne Cluster stellen kurzlebige, an eine Audience gebundene projizierte Token aus, aber alte, langlebige Secret-Token sind weiterhin vorhanden.

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

Berechtigungen auflisten

Nach dem Erfassen eines Tokens besteht der erste Schritt darin, herauszufinden, was damit möglich ist. Kubernetes stellt dafür eine API zur Selbstprüfung bereit.

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

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

Gefährliche Berechtigungskombinationen

Bestimmte Verben ermöglichen auch ohne cluster-admin eine Rechteausweitung.

create pods: einen privilegierten oder hostPath-Pod planen, um auszubrechen.
create pods/exec: Befehle in bestehenden Pods ausführen.
get/list secrets: clusterweit Secrets lesen.
create rolebindings/clusterrolebindings: sich selbst an Admin-Rechte binden.
escalate / bind-Verben: Rechte gewähren, die Sie nicht besitzen.
impersonate: als ein anderes, privilegierteres Subjekt handeln.

Rechteausweitung durch Pod-Erstellung

Wenn ein Service Account Pods erstellen kann, kann er häufig den Node übernehmen. Der Angreifer plant einen Pod ein, der das Host-Dateisystem einbindet oder privilegiert ausgeführt wird, und liest anschließend Node-Anmeldedaten aus oder bricht aus.

# 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

Rechteausweitung durch Bindings

Wenn Sie (cluster)rolebindings erstellen können, können Sie Ihren Service Account möglicherweise direkt an cluster-admin binden. Kubernetes schützt dies mit den Verben bind/escalate, aber fehlkonfigurierte Rollen erlauben dies manchmal.

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

Missbrauch von Impersonation

Das Verb impersonate ermöglicht einem Subjekt, als beliebiger Benutzer, als beliebige Gruppe oder als beliebiger Service Account zu handeln. Ein Principal mit weitreichenden Impersonation-Berechtigungen verfügt faktisch über jede Berechtigung im Cluster.

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

RBAC prüfen

Verteidiger sollten RBAC kontinuierlich auf riskante Berechtigungsvergabe prüfen.

Ermitteln Sie Subjekte, die an cluster-admin gebunden sind.
Markieren Sie Wildcards bei Verben/Ressourcen (*).
Erkennen Sie Berechtigungen zum Lesen von Secrets und Erstellen von Pods bei Nicht-Admin-Konten.

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

Service Accounts härten

Wenden Sie das Prinzip der geringsten Rechte auf Identitäten an.

Setzen Sie automountServiceAccountToken: false, wenn der Pod keinen API-Zugriff benötigt.
Geben Sie jeder Workload einen dedizierten Service Account mit minimalem Geltungsbereich.
Vermeiden Sie den default-Service-Account für echte Workloads.
Verwenden Sie kurzlebige projizierte Token mit Audiences; rotieren und binden Sie sie.
Binden Sie Workloads niemals an cluster-admin.

RBAC ethisch testen

Bevorzugen Sie bei der Bewertung von RBAC nicht-destruktive Prüfungen (auth can-i, dry-run), statt in der Produktion tatsächlich Cluster-Admin-Bindings zu erstellen. Wenn Sie eine Rechteausweitung nachweisen müssen, beschränken Sie den Test auf einen Test-Namespace und entfernen Sie alle von Ihnen erstellten Bindings oder Pods.

Melden Sie die genauen Rollen und Bindings, die die Rechteausweitung ermöglicht haben, damit sie restriktiver konfiguriert werden können.

Schnelltest

Überprüfen Sie Ihr Verständnis von RBAC.

Zusammenfassung

Sie haben gelernt, wie RBAC und Service Accounts den Clusterzugriff steuern und gefährden können.

RBAC bindet Subjekte an Verben für Ressourcen; cluster-admin bedeutet vollständige Kontrolle.
Pods binden SA-Token ein; auth can-i zeigt deren Zugriffsbereich.
create-pods, Bindings, das Lesen von Secrets und impersonate sind Grundlagen für eine Rechteausweitung.
Konten mit geringsten Rechten und deaktiviertes automatisches Einbinden härten den Cluster.

Als Nächstes: Pod-Sicherheit und Netzwerkrichtlinien.

Häufig gestellte Fragen

Ist die Lektion „RBAC und Servicekonten“ kostenlos?

Ja — der vollständige Text von „RBAC und Servicekonten“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Cyber Security Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Cyber Security Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „RBAC und Servicekonten“?

Clusterzugriff absichern Du übst Cyber Security Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Cyber Security Academy zu starten?

Keine Vorkenntnisse erforderlich. Cyber Security Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.

Wie lange dauert die Lektion „RBAC und Servicekonten“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Cyber Security Academy-Lektion Code schreiben und ausführen?

Ja. Jede Cyber Security Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

← Zurück zu Cyber Security Academy