Best Practices für GKE RBAC

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Auf dieser Seite finden Sie Best Practices für die Planung Ihrer rollenbasierten Zugriffssteuerungsrichtlinien (Role-Based Access Control, RBAC). Informationen zum Implementieren von RBAC in Google Kubernetes Engine (GKE) finden Sie unter Rollenbasierte Zugriffssteuerung konfigurieren.

RBAC ist ein zentrales Sicherheitsfeature in Kubernetes, mit dem Sie detaillierte Berechtigungen erstellen können, um zu verwalten, welche Aktionen Nutzer und Arbeitslasten für Ressourcen in Ihren Clustern ausführen können. Als Plattformadministrator erstellen Sie RBAC-Rollen und binden diese Rollen an Subjekte, die authentifizierte Nutzer wie Dienstkonten oder Gruppen sind.

Vorbereitung

Machen Sie sich mit den folgenden Konzepten vertraut:

Eine Checkliste dieser Anleitung finden Sie unter Zusammenfassung der Checkliste.

Funktionsweise von RBAC

RBAC unterstützt die folgenden Typen von Rollen und Bindungen:

  • ClusterRole: Eine Reihe von Berechtigungen, die auf einen beliebigen Namespace oder auf den gesamten Cluster angewendet werden können.
  • Role: Eine Reihe von Berechtigungen, die auf einen einzelnen Namespace beschränkt sind.
  • ClusterRoleBinding: Binden Sie eine ClusterRole an einen Nutzer oder eine Gruppe für alle Namespaces im Cluster.
  • RoleBinding: Binden Sie eine Role oder eine ClusterRole an einen Nutzer oder eine Gruppe in einem bestimmten Namespace.

Sie definieren Berechtigungen als rules in einer Role oder einer ClusterRole. Jedes rules-Feld in einer Rolle besteht aus einer API-Gruppe, den API-Ressourcen innerhalb dieser API-Gruppe und den für diese Ressourcen zulässigen Verben (Aktionen). Optional können Sie Verben mithilfe des Felds resourceNames auf benannte Instanzen von API-Ressourcen beschränken. Ein Beispiel finden Sie unter Zugriff auf bestimmte Ressourceninstanzen beschränken.

Nachdem Sie eine Rolle definiert haben, verwenden Sie ein RoleBinding oder ein ClusterRoleBinding, um die Rolle an ein Subjekt zu binden. Wählen Sie den Bindungstyp aus, je nachdem, ob Sie Berechtigungen in einem einzelnen Namespace oder in mehreren Namespaces gewähren möchten.

RBAC-Rollendesign

Prinzip der geringsten Berechtigung anwenden

Verwenden Sie beim Zuweisen von Berechtigungen in einer RBAC-Rolle das Prinzip der geringsten Berechtigung und gewähren Sie die Mindestberechtigungen, die zum Ausführen einer Aufgabe erforderlich sind. Das Prinzip der geringsten Berechtigung reduziert das Risiko einer Rechteausweitung, wenn Ihr Cluster manipuliert wurde, und verringert die Wahrscheinlichkeit, dass übermäßiger Zugriff zu einem Sicherheitsvorfall führt.

Berücksichtigen Sie beim Entwerfen Ihrer Rollen sorgfältig die gängigen Risiken der Rechteausweitung, z. B. bei escalate- oder bind-Verben, create-Zugriff für PersistentVolumes oder create-Zugriff für Anfragen für Zertifikatsignaturen. Eine Liste der Risiken finden Sie unter Kubernetes RBAC – Risiken der Rechteausweitung.

Standardrollen und -gruppen vermeiden

Kubernetes erstellt automatisch eine Reihe von ClusterRole- und ClusterRoleBinding-Objekten, die Sie für die API-Erkennung und die Aktivierung der Funktionalität für verwaltete Komponenten verwenden können. Die durch diese Standardrollen gewährten Berechtigungen können umfassend sein. Beispiel: Die ClusterRole cluster-admin gewährt einem Subjekt die Berechtigung, beliebige Aktionen mit einer beliebigen Ressource auszuführen. Wenn Sie die ClusterRole cluster-admin mit einem ClusterRoleBinding an ein Nutzer- oder Dienstkonto binden, hat dieses Subjekt unbegrenzte Befugnisse innerhalb des Clusters.

Bevor Sie eine Standardrolle an ein Subjekt binden, bewerten Sie die durch diese Rolle gewährten Berechtigungen für Ihren Anwendungsfall. Sie sollten sich der Risiken bewusst sein. Eine vollständige Liste der von Kubernetes erstellten Standardrollen und -bindungen finden Sie unter Standardrollen und -rollenbindungen.

Kubernetes erstellt auch Standardgruppen, die an die Standardrollen gebunden sind. Die ClusterRole cluster-admin ist beispielsweise an die Gruppe system:masters gebunden, um verwaltete Komponenten uneingeschränkten Zugriff auf den API-Server zu gewähren. Fügen Sie system:masters keine eigenen Subjekte hinzu.

Beachten Sie dabei nach Möglichkeit die folgenden Richtlinien:

  • Fügen Sie der Gruppe system:masters keine eigenen Subjekte hinzu.
  • Binden Sie die Gruppe system:unauthenticated nicht an RBAC-Rollen.
  • Binden Sie die ClusterRole cluster-admin nicht an Ihre eigenen Subjekte.
  • Bewerten Sie die Berechtigungen anderer Standardrollen, bevor Sie Subjekte binden.
  • Prüfen Sie die Rollen, die an Standardgruppen gebunden sind, bevor Sie die Mitglieder dieser Gruppen ändern.

Berechtigungen auf die Namespace-Ebene beschränken

Verwenden Sie Bindungen und Rollen je nach den Anforderungen Ihrer Arbeitslast oder Ihres Nutzers:

  • Um Zugriff auf Ressourcen in einem Namespace zu gewähren, verwenden Sie eine Role mit einem RoleBinding.
  • Um Zugriff auf Ressourcen in mehr als einem Namespace zu gewähren, verwenden Sie eine ClusterRole mit einem RoleBinding für jeden Namespace.
  • Wenn Sie Zugriff auf Ressourcen in jedem Namespace gewähren möchten, verwenden Sie eine ClusterRole mit einem ClusterRoleBinding.

Gewähren Sie Berechtigungen in so wenigen Namespaces wie möglich.

Keine Platzhalter verwenden

Das Zeichen * ist ein Platzhalter, der für alles gilt. Vermeiden Sie Platzhalter in den Regeln. Geben Sie in API-Regeln explizit API-Gruppen, Ressourcen und Verben an. Wenn Sie beispielsweise * im Feld verbs angeben, werden die Berechtigungen get, list, watch, patch, update, deletecollection und delete für die Ressourcen gewährt. Die folgende Tabelle zeigt Beispiele für die Vermeidung von Platzhaltern in Ihren Regeln:

Empfohlen Nicht empfohlen

- rules:
    apiGroups: ["apps","extensions"]
    resources: ["deployments"]
    verbs: ["get","list","watch"]

Gewährt die Verben get, list und watch speziell für die API-Gruppen apps und extensions.


- rules:
    apiGroups: ["*"]
    resources: ["deployments"]
    verbs: ["get","list","watch"]

Gewährt deployments die Verben in beliebigen API-Gruppen.


- rules:
    apiGroups: ["apps", "extensions"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]

Gewährt nur die Verben get, list und watch für Bereitstellungen in den API-Gruppen apps und extensions.


- rules:
    apiGroups: ["apps", "extensions"]
    resources: ["deployments"]
    verbs: ["*"]

Gewährt alle Verben, einschließlich patch oder delete.

Separate Regeln verwenden, um Zugriff mit den geringstmöglichen Berechtigungen auf bestimmte Ressourcen zu gewähren

Führen Sie bei der Planung Ihrer Regeln die folgenden allgemeinen Schritte aus, um in jeder Rolle ein effizienteres Regeldesign mit den geringstmöglichen Berechtigungen zu erhalten:

  1. Entwerfen Sie separate RBAC-Regeln für jedes Verb für jede Ressource, auf die ein Subjekt zugreifen muss.
  2. Nachdem Sie die Regeln erstellt haben, analysieren Sie die Regeln, um zu prüfen, ob mehrere Regeln dieselbe verbs-Liste haben. Kombinieren Sie diese Regeln zu einer einzigen Regel.
  3. Halten Sie alle übrigen Regeln voneinander getrennt.

Dieser Ansatz führt zu einem organisierteren Regeldesign, bei dem Regeln, die mehreren Ressourcen dieselben Verben zuweisen, kombiniert werden und Regeln, die Ressourcen verschiedene Verben zuweisen, getrennt werden.

Wenn Ihre Arbeitslast beispielsweise Berechtigungen für die Ressource deployments benötigt, aber list und watch für die daemonsets-Ressourcen benötigt, sollten Sie beim Erstellen einer Rolle separate Regeln verwenden. Wenn Sie die RBAC-Rolle an Ihre Arbeitslast binden, kann watch nicht für deployments verwendet werden.

Ein weiteres Beispiel: Wenn Ihre Arbeitslast get und watch für die Ressource pods und die Ressource daemonsets benötigt, können Sie diese in einer einzigen Regel kombinieren, da die Arbeitslast für beide Ressourcen die gleichen Verben benötigt.

In der folgenden Tabelle funktionieren beide Regeldesigns, aber die aufgeteilten Regeln beschränken den Ressourcenzugriff genauer entsprechend Ihren Anforderungen:

Empfohlen Nicht empfohlen

- rules:
    apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get"]
- rules:
    apiGroups: ["apps"]
    resources: ["daemonsets"]
    verbs: ["list", "watch"]

Gewährt get-Zugriff für Deployments sowie watch- und list-Zugriff für DaemonSets. Subjekte können keine Deployments auflisten.


- rules:
    apiGroups: ["apps"]
    resources: ["deployments", "daemonsets"]
    verbs: ["get","list","watch"]

Gewährt die Verben sowohl für Deployments als auch für DaemonSets. Ein Subjekt, das möglicherweise keinen list-Zugriff auf deployments-Objekte benötigt, erhält diesen Zugriff trotzdem.


- rules:
    apiGroups: ["apps"]
    resources: ["daemonsets", "deployments"]
    verbs: ["list", "watch"]

Kombiniert zwei Regeln, da das Subjekt dieselben Verben für die Ressourcen daemonsets und deployments benötigt.


- rules:
    apiGroups: ["apps"]
    resources: ["daemonsets"]
    verbs: ["list", "watch"]
- rules:
    apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["list", "watch"]

Diese aufgeteilten Regeln haben dasselbe Ergebnis wie die kombinierte Regel, machen Ihr Rollenmanifest aber unnötig umständlich.

Zugriff auf bestimmte Ressourceninstanzen beschränken

Mit RBAC können Sie das Feld resourceNames in Ihren Regeln verwenden, um den Zugriff auf eine bestimmte benannte Instanz einer Ressource zu beschränken. Wenn Sie beispielsweise eine RBAC-Rolle schreiben, die ein update für die ConfigMap seccomp-high durchführen muss und nichts anderes benötigt, können Sie resourceNames verwenden, um nur diese ConfigMap anzugeben. Verwenden Sie nach Möglichkeit immer resourceNames.

Empfohlen Nicht empfohlen

- rules:
    apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["seccomp-high"]
    verbs: ["update"]

Schränkt das Subjekt ein, sodass nur die ConfigMap seccomp-high aktualisiert wird. Der Subjekt kann keine anderen ConfigMaps im Namespace aktualisieren.


- rules:
    apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["update"]

Das Subjekt kann die ConfigMap seccomp-high und jede andere ConfigMap im Namespace aktualisieren.


- rules:
    apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["list"]
- rules:
    apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["seccomp-high"]
    verbs: ["update"]

Gewährt list-Zugriff auf alle ConfigMaps im Namespace, einschließlich seccomp-high. Beschränkt den update-Zugriff auf die ConfigMap seccomp-high. Die Regeln werden aufgeteilt, da Sie nicht list für benannte Ressourcen zuweisen können.


- rules:
    apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["update", "list"]

Gewährt update-Zugriff für alle ConfigMaps, zusammen mit list-Zugriff.

Nicht zulassen, dass Dienstkonten RBAC-Ressourcen ändern

Binden Sie keine Role- oder ClusterRole-Ressourcen mit den Berechtigungen bind, escalate, create, update oder patch für die API-Gruppe rbac.authorization.k8s.io an Dienstkonten in einem beliebigen Namespace. Insbesondere escalate und bind können es einem Angreifer ermöglichen, die in RBAC integrierten Methoden zur Eskalationsverhinderung zu umgehen.

Kubernetes-Dienstkonten

Kubernetes-Dienstkonto für jede Arbeitslast erstellen

Erstellen Sie ein separates Kubernetes-Dienstkonto für jede Arbeitslast. Binden Sie eine Role oder ClusterRole mit geringstmöglichen Berechtigungen an dieses Dienstkonto.

Nicht das Standarddienstkonto verwenden

Kubernetes erstellt in jedem Namespace ein Dienstkonto mit dem Namen default. Das Dienstkonto default wird automatisch Pods zugewiesen, die im Manifest nicht explizit ein Dienstkonto angeben. Vermeiden Sie die Bindung einer Role oder ClusterRole an das Dienstkonto default. Kubernetes weist das Dienstkonto default möglicherweise einem Pod zu, der den Zugriff in diesen Rollen nicht benötigt.

Dienstkonto-Tokens nicht automatisch bereitstellen

Das Feld automountServiceAccountToken in der Pod-Spezifikation weist Kubernetes an, ein Anmeldedatentoken für ein Kubernetes-Dienstkonto in den Pod einzufügen. Der Pod kann mit diesem Token authentifizierte Anfragen an den Kubernetes API-Server senden. Der Standardwert für dieses Feld ist true.

Legen Sie in allen GKE-Versionen automountServiceAccountToken=false in der Pod-Spezifikation fest, wenn Ihre Pods nicht mit dem API-Server kommunizieren müssen.

Sitzungsspezifische Tokens gegenüber secret-basierten Tokens bevorzugen

Vermeiden Sie beim Erstellen und Verwenden von Dienstkonto-Tokens die Verwendung von Kubernetes-Secrets zum Speichern des Tokens. Secret-basierte Dienstkonto-Tokens sind Legacy-Anmeldedaten, die nicht ablaufen und nicht automatisch rotiert werden. Wenn Sie Anmeldedaten für Dienstkonten benötigen, verwenden Sie die TokenRequest API, um kurzlebige Tokens abzurufen, die automatisch rotiert werden.

RBAC-Berechtigungen kontinuierlich prüfen

Prüfen Sie Ihre RBAC-Rollen und den Zugriff regelmäßig, um potenzielle Eskalationspfade und redundante Regeln zu identifizieren. Beispiel: Sie löschen nicht das RoleBinding, das eine Role mit speziellen Berechtigungen an einen gelöschten Nutzer bindet. Wenn ein Angreifer nun in diesem Namespace ein Nutzerkonto mit dem Namen des gelöschten Nutzers erstellt, ist er an diese Role gebunden und übernimmt ihren Zugriff. Regelmäßige Überprüfungen minimieren dieses Risiko.

Zusammenfassung der Checkliste

Nächste Schritte