In diesem Dokument werden die Unterschiede zwischen Identity and Access Management (IAM) und der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes in Google Kubernetes Engine beschrieben, um Ihnen die Verwaltung des Zugriffs auf Ressourcen in Ihrem Projekt zu erleichtern. In diesem Dokument wird davon ausgegangen, dass Sie mit Folgendem vertraut sind:
Dieses Dokument richtet sich an Sicherheitsexperten, die den Zugriff auf Berechtigungen steuern und die Unterschiede und Überschneidungen zwischen IAM und RBAC verstehen möchten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir inGoogle Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.
Zugriff auf GKE-Ressourcen verwalten
Wenn Sie ein Google Cloud -Projekt erstellen, sind Sie der einzige Nutzer des Projekts. Andere Nutzer können standardmäßig weder auf Ihr Projekt noch auf dessen Ressourcen zugreifen. Dies gilt auch für Google Kubernetes Engine-Ressourcen (GKE). GKE unterstützt mehrere Optionen zum Verwalten des Zugriffs auf Ressourcen in Ihrem Projekt und dessen Clustern mithilfe der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC).
Die Mechanismen haben teilweise dieselben Funktionen, gelten jedoch für unterschiedliche Ressourcentypen. Jede Option wird in einem eigenen Abschnitt auf dieser Seite erläutert. Hier eine kurze Zusammenfassung:
Kubernetes RBAC ist in Kubernetes eingebunden und gewährt Objekten in Kubernetes-Clustern detaillierte Berechtigungen. Berechtigungen sind im Cluster als ClusterRole- oder Role-Objekte vorhanden. Mit RoleBinding-Objekten werden Rollen Kubernetes-Nutzer, föderierte Nutzerkonten oder IAM-Dienstkonten.
Wenn Sie überwiegend GKE verwenden und für jedes Objekt und jeden Vorgang innerhalb des Clusters detaillierte Berechtigungen benötigen, ist Kubernetes RBAC die beste Wahl.
IAM verwaltet Google Cloud -Ressourcen, einschließlich Clustern und Objekttypen innerhalb von Clustern. Berechtigungen werden IAM-Hauptkonten zugewiesen.
Zum Erteilen von Berechtigungen für bestimmte Kubernetes-Objekte in IAM gibt es keinen Mechanismus. Sie können beispielsweise einen Nutzer allgemein zum Erstellen von CustomResourceDefinitions (CRDs) berechtigen, aber die Berechtigung nicht auf die Erstellung einer bestimmten CustomResourceDefinition oder eines speziellen Namespace oder Clusters im Projekt begrenzen. Eine IAM-Rolle gewährt Berechtigungen für alle Cluster im Projekt bzw. bei Anwendung der Rolle auf Ordnerebene für alle Cluster in allen untergeordneten Projekten.
Wenn Sie mehrere Google Cloud -Komponenten verwenden und keine detaillierten Kubernetes-spezifischen Berechtigungen verwalten müssen, ist IAM eine gute Wahl.
Kubernetes RBAC
Kubernetes bietet integrierte Unterstützung für RBAC, mit der Sie detaillierte Rollen erstellen können, die im Kubernetes-Cluster vorhanden sind. Eine Rolle kann für ein bestimmtes Kubernetes-Objekt oder einen Kubernetes-Objekttyp festgelegt werden. Sie definiert, welche Aktionen bzw. "Verben" der Rolle in Bezug auf dieses Objekt erteilt werden. RoleBinding-Objekte sind ebenfalls Kubernetes-Objekte. Damit werden Nutzern Rollen zugewiesen. Ein GKE-Nutzer kann Folgendes sein:
- Föderiertes Nutzerkonto
- IAM-Dienstkonto
- Kubernetes-Dienstkonto
- Nutzer, die mit X509-Clientzertifikaten authentifiziert wurden
Weitere Informationen erhalten Sie unter Rollenbasierte Zugriffssteuerung.
IAM
Mit IAM können Sie Hauptkonten Rollen zuweisen. Eine Rolle ist eine Sammlung von Berechtigungen. Sie steuert den Zugriff des jeweiligen Hauptkontos auf eine oder mehrere Google Cloud-Ressourcen. Weitere Informationen zu Hauptkonten, Rollen und anderer IAM-Terminologie finden Sie in der IAM-Übersicht.
In GKE kann ein Hauptkonto Folgendes sein:
- Nutzerkonto
- Dienstkonto
Weitere Informationen zur Verwendung von IAM für die Zugriffssteuerung in GKE finden Sie unter IAM-Zulassungsrichtlinien erstellen.
IAM-Richtlinientypen
IAM unterstützt die folgenden Richtlinientypen:
- Richtlinien zulassen: Weisen Sie Hauptkonten Rollen zu. Weitere Informationen finden Sie unter Zulassungsrichtlinie.
- Ablehnungsrichtlinien: Verhindern, dass Hauptkonten bestimmte IAM-Berechtigungen verwenden, unabhängig von den Rollen, die diesen Hauptkonten gewährt wurden. Weitere Informationen finden Sie unter Ablehnungsrichtlinien.
Verwenden Sie Ablehnungsrichtlinien, um bestimmte Hauptkonten daran zu hindern, bestimmte Aktionen in Ihrem Projekt, Ordner oder Ihrer Organisation auszuführen, auch wenn eine IAM-Zulassungsrichtlinie diesen Hauptkonten eine Rolle mit den entsprechenden Berechtigungen zuweist.
IAM-Empfehlungen
Erwägen Sie die Verwendung der folgenden vordefinierten IAM-Rollen für gängige Szenarien:
- Kubernetes Engine-Clusterbetrachter (
roles/container.clusterViewer): DevOps, Entwickler und Anwendungsentwickler, die nur eine Verbindung zum Cluster herstellen müssen. - Kubernetes Engine-Clusteradministrator (
roles/container.clusterAdmin): Plattformadministratoren und Clusteroperatoren, die einen oder mehrere Cluster in einem Google Cloud -Projekt verwalten müssen.
Eine Liste der verfügbaren vordefinierten IAM-Rollen finden Sie unter Vordefinierte GKE-Rollen.
Die GKE verwendet IAM-Dienstkonten, die an Ihre Knoten angehängt sind, um Systemaufgaben wie Logging und Monitoring auszuführen. Diese Knotendienstkonten müssen mindestens die Rolle Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) für Ihr Projekt haben. Standardmäßig verwendet die GKE das Compute Engine-Standarddienstkonto, das automatisch in Ihrem Projekt erstellt wird, als Knotendienstkonto.
IAM-Interaktion mit Kubernetes RBAC
IAM und Kubernetes RBAC unterstützen gemeinsam den Zugriff auf Ihren Cluster. RBAC steuert den Zugriff auf der Cluster- und Namespace-Ebene, während IAM auf Projektebene arbeitet. Eine Entität muss auf beiden Ebenen ausreichende Berechtigungen haben, um mit Ressourcen in Ihrem Cluster arbeiten zu können.
Nächste Schritte
- GKE-Sicherheitsübersicht
- Kubernetes RBAC verwenden
- IAM-Richtlinien für GKE erstellen
- Weitere Informationen zur Verwendung von IAM-Bedingungen für Load Balancer