Kubernetes Role-Based Access Control(RBAC)

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Role-Based Access Control (RBAC)

Kubernetes hat ein Autorisierungsmodul namens Role-Based Access Control (RBAC), das hilft, Berechtigungen für den API-Server festzulegen.

Das Berechtigungsmodell von RBAC besteht aus drei einzelnen Teilen:

1. Role\ClusterRole ­– Die tatsächliche Berechtigung. Sie enthält Regeln, die eine Menge von Berechtigungen darstellen. Jede Regel enthält Ressourcen und Verben. Das Verb ist die Aktion, die auf die Ressource angewendet wird.

2. Subjekt (Benutzer, Gruppe oder ServiceAccount) – Das Objekt, das die Berechtigungen erhält.

3. RoleBinding\ClusterRoleBinding – Die Verbindung zwischen Role\ClusterRole und dem Subjekt.

Der Unterschied zwischen “Roles” und “ClusterRoles” besteht lediglich darin, wo die Rolle angewendet wird – eine “Role” gewährt Zugriff auf nur ein bestimmtes Namespace, während eine “ClusterRole” in allen Namespaces im Cluster verwendet werden kann. Darüber hinaus können ClusterRoles auch Zugriff auf gewähren:

• cluster-scoped Ressourcen (wie Knoten).

• non-resource Endpunkte (wie /healthz).

• namespaced Ressourcen (wie Pods), über alle Namespaces hinweg.

Seit Kubernetes 1.6 sind RBAC-Richtlinien standardmäßig aktiviert. Um RBAC zu aktivieren, können Sie etwas wie verwenden:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

Vorlagen

Im Template eines Role oder ClusterRole müssen Sie den Namen der Rolle, den Namespace (bei Rollen) und dann die apiGroups, Ressourcen und Verben der Rolle angeben:

• Die apiGroups ist ein Array, das die verschiedenen API-Namespaces enthält, auf die diese Regel zutrifft. Zum Beispiel verwendet eine Pod-Definition apiVersion: v1. Es kann Werte wie rbac.authorization.k8s.io oder [*] haben.

• Die Ressourcen ist ein Array, das definiert, auf welche Ressourcen diese Regel zutrifft. Sie können alle Ressourcen mit: kubectl api-resources --namespaced=true finden.

• Die Verben ist ein Array, das die erlaubten Verben enthält. Das Verb in Kubernetes definiert die Art der Aktion, die Sie auf die Ressource anwenden müssen. Zum Beispiel wird das List-Verben gegen Sammlungen verwendet, während "get" gegen eine einzelne Ressource verwendet wird.

Regeln Verben

(Diese Informationen stammen aus den Docs)

HTTP-Verb	Anfrageverb
POST	erstellen
GET, HEAD	abrufen (für einzelne Ressourcen), auflisten (für Sammlungen, einschließlich des vollständigen Objektinhalts), beobachten (für das Beobachten einer einzelnen Ressource oder Sammlung von Ressourcen)
PUT	aktualisieren
PATCH	patchen
DELETE	löschen (für einzelne Ressourcen), sammlunglöschen (für Sammlungen)

Kubernetes überprüft manchmal die Autorisierung für zusätzliche Berechtigungen mit spezialisierten Verben. Zum Beispiel:

• PodSecurityPolicy

• use Verb auf podsecuritypolicies Ressourcen in der policy API-Gruppe.

• RBAC

• bind und escalate Verben auf roles und clusterroles Ressourcen in der rbac.authorization.k8s.io API-Gruppe.

• Authentifizierung

• impersonate Verb auf users, groups und serviceaccounts in der Kern-API-Gruppe und die userextras in der authentication.k8s.io API-Gruppe.

Sie können alle Verben, die jede Ressource unterstützt, ausführen, indem Sie kubectl api-resources --sort-by name -o wide ausführen.

Beispiele

Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: defaultGreen
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]

ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]

Zum Beispiel können Sie ein ClusterRole verwenden, um einem bestimmten Benutzer zu erlauben, Folgendes auszuführen:

kubectl get pods --all-namespaces

RoleBinding und ClusterRoleBinding

Aus den Dokumenten: Ein Role Binding gewährt die in einer Rolle definierten Berechtigungen an einen Benutzer oder eine Gruppe von Benutzern. Es enthält eine Liste von Subjekten (Benutzern, Gruppen oder Dienstkonten) und einen Verweis auf die gewährte Rolle. Ein RoleBinding gewährt Berechtigungen innerhalb eines bestimmten Namespaces, während ein ClusterRoleBinding diesen Zugriff clusterweit gewährt.

piVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io

Berechtigungen sind additiv, sodass Sie ein clusterRole mit „list“ und „delete“ Secrets haben können, das Sie mit einer Rolle mit „get“ hinzufügen können. Seien Sie sich dessen bewusst und testen Sie immer Ihre Rollen und Berechtigungen und geben Sie an, was ERLAUBT ist, denn alles ist standardmäßig VERWEIGERT.

Auflisten von RBAC

# Get current privileges
kubectl auth can-i --list
# use `--as=system:serviceaccount:<namespace>:<sa_name>` to impersonate a service account

# List Cluster Roles
kubectl get clusterroles
kubectl describe clusterroles

# List Cluster Roles Bindings
kubectl get clusterrolebindings
kubectl describe clusterrolebindings

# List Roles
kubectl get roles
kubectl describe roles

# List Roles Bindings
kubectl get rolebindings
kubectl describe rolebindings

Missbrauch von Rollen/ClusterRoles zur Privilegieneskalation

Abusing Roles/ClusterRoles in Kubernetes

Unterstütze HackTricks

• Überprüfe die Abonnementpläne!

• Tritt der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folge uns auf Twitter 🐦 @hacktricks_live.

• Teile Hacking-Tricks, indem du PRs zu den HackTricks und HackTricks Cloud GitHub-Repos einreichst.