Kubernetes Role-Based Access Control(RBAC)

Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

• Wenn Sie Ihr Unternehmen in HackTricks beworben sehen möchten oder HackTricks im PDF-Format herunterladen möchten, überprüfen Sie die ABONNEMENTPLÄNE!

• Holen Sie sich das offizielle PEASS & HackTricks-Merchandise

• Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs

• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie mir auf Twitter 🐦 @carlospolopm.

• Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud Github-Repositorys einreichen.

Rollenbasierte Zugriffskontrolle (RBAC)

Kubernetes verfügt über ein Autorisierungsmodul namens Rollenbasierte Zugriffskontrolle (RBAC), das dabei hilft, Nutzungsrechte für den API-Server festzulegen.

Das Berechtigungsmodell von RBAC setzt sich aus drei einzelnen Teilen zusammen:

1. Rolle/ClusterRolle – Die tatsächliche Berechtigung. Sie enthält Regeln, die eine Reihe 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 erhalten wird.

3. RolleBinding/ClusterRolleBinding – Die Verbindung zwischen Rolle/ClusterRolle und dem Subjekt.

Der Unterschied zwischen "Rollen" und "ClusterRollen" liegt nur darin, wo die Rolle angewendet wird – eine "Rolle" gewährt Zugriff nur auf einen bestimmten spezifischen Namespace, während eine "ClusterRolle" in allen Namespaces im Cluster verwendet werden kann. Darüber hinaus können ClusterRollen auch Zugriff gewähren auf:

• Cluster-weit gültige Ressourcen (wie Knoten).

• Nicht-Ressourcen-Endpunkte (wie /healthz).

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

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

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

Vorlagen

In der Vorlage eines Rolle oder eines ClusterRole müssen Sie den Namen der Rolle, den Namespace (in Rollen) und dann die apiGroups, Ressourcen und Verben der Rolle angeben:

• Die apiGroups ist ein Array, das die verschiedenen API-Namensräume 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 finden: kubectl api-resources --namespaced=true

• Die Verben ist ein Array, das die erlaubten Verben enthält. Das Verb in Kubernetes definiert den Typ der Aktion, die auf die Ressource angewendet werden muss. Zum Beispiel wird das Verb "list" gegen Sammlungen verwendet, während "get" gegen eine einzelne Ressource verwendet wird.

Verbenregeln

(Diese Informationen stammen aus den Dokumenten)

HTTP-Verb	Anforderungsverb
POST	erstellen
GET, HEAD	get (für einzelne Ressourcen), list (für Sammlungen, einschließlich des vollständigen Objektinhalts), watch (zum Beobachten einer einzelnen Ressource oder einer Sammlung von Ressourcen)
PUT	aktualisieren
PATCH	patch
DELETE	löschen (für einzelne Ressourcen), deletecollection (für Sammlungen)

Manchmal überprüft Kubernetes die Autorisierung für zusätzliche Berechtigungen unter Verwendung spezialisierter 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 Benutzer, Gruppen und Servicekonten 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, finden, indem Sie kubectl api-resources --sort-by name -o wide ausführen

Beispiele

Rolle

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 einen ClusterRole verwenden, um einem bestimmten Benutzer das Ausführen zu ermöglichen:

kubectl get pods --all-namespaces

RoleBinding und ClusterRoleBinding

Aus den Dokumenten: Ein RoleBinding gewährt die in einer Rolle definierten Berechtigungen einem Benutzer oder einer Benutzergruppe. Es enthält eine Liste von Subjekten (Benutzer, Gruppen oder Servicekonten) 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, daher können Sie, wenn Sie einen ClusterRole mit "list" und "delete" Secrets haben, diesen mit einem Role mit "get" hinzufügen. Seien Sie also vorsichtig und testen Sie immer Ihre Rollen und Berechtigungen und geben Sie an, was ERLAUBT ist, da standardmäßig alles VERWEIGERT wird.

RBAC aufzählen

# 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 für Privilege Escalation

pageAbusing Roles/ClusterRoles in Kubernetes

Erlernen Sie AWS-Hacking von Null auf Heldenniveau mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

• Wenn Sie Ihr Unternehmen in HackTricks beworben sehen möchten oder HackTricks im PDF-Format herunterladen möchten, überprüfen Sie die ABONNEMENTPLÄNE!

• Holen Sie sich das offizielle PEASS & HackTricks-Merch

• Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs

• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie mir auf Twitter 🐦 @carlospolopm.

• Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repositories einreichen.