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. Diese werden in den weiteren Abschnitten im Einzelnen erläutert. Vorab eine kurze Übersicht:
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 RollenKubernetes-Nutzer, Google Cloud-Nutzer, IAM-Dienstkonten oderGoogle-Gruppen.
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 Cluster, und Objekttypen in Clustern. Berechtigungen werden den 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 speziellen Berechtigungen für Kubernetes verwalten müssen, ist IAM eine gute Wahl.
Kubernetes RBAC
Kubernetes unterstützt die rollenbasierte Zugriffssteuerung (RBAC). Sie können dadurch innerhalb des Kubernetes-Clusters Rollen mit detaillierten Berechtigungen erstellen. 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:
Mit IAM können Sie HauptkontenRollen zuweisen. Eine Rolle ist eine Sammlung von Berechtigungen. Sie steuert den Zugriff des jeweiligen Hauptkontos auf eine oder mehrere Google Cloud-Ressourcen. Sie können die folgenden Arten von Rollen verwenden:
Einfache Rollen bieten grobe Berechtigungen für den Inhaber, Mitbearbeiter und Betrachter.
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.
Erwägen Sie außerdem, ein benutzerdefiniertes IAM-Dienstkonto zu erstellen, das Ihre Knoten anstelle des Compute Engine-Standarddienstkontos verwenden sollen.
Gewähren Sie dem benutzerdefinierten Dienstkonto die Mindestberechtigungen, die für das Funktionieren von GKE erforderlich sind. Eine Anleitung finden Sie unter IAM-Dienstkonten mit geringsten Berechtigungen verwenden.
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.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2024-11-22 (UTC)."],[],[],null,["# Access control\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page explains the differences between Identity and Access Management (IAM) and\nKubernetes role-based access control (RBAC) in Google Kubernetes Engine to help you manage\naccess to resources within your project.\n\nThis page is for\nSecurity specialists who control access to permissions and want to understand\nthe differences and overlap between IAM and RBAC. To learn more about\ncommon roles and example tasks that we reference in Google Cloud content, see\n[Common GKE user roles and tasks](/kubernetes-engine/enterprise/docs/concepts/roles-tasks).\n\nWhen you create a Google Cloud project, you are the only user on the project. By\ndefault, no other users have access to your project or its resources, including\nGoogle Kubernetes Engine (GKE) resources. GKE supports multiple\noptions for managing access to resources within your project and its clusters\nusing role-based access control (RBAC).\n\nBefore reading this page, ensure that you're familiar with the following:\n\n- [General overview of IAM in GKE](/kubernetes-engine/docs/how-to/iam)\n- [General overview of Kubernetes RBAC](/kubernetes-engine/docs/how-to/role-based-access-control)\n\nThese mechanisms have some functional overlap, but are targeted to different\ntypes of resources. Each is explained in a dedicated section on this page, but in brief:\n\n- [Kubernetes RBAC](#rbac) is built into Kubernetes, and grants granular\n permissions to objects within Kubernetes clusters. Permissions exist as\n ClusterRole or Role objects within the cluster. RoleBinding objects grant\n Roles to\n\n Kubernetes users, Google Cloud users, IAM\n service accounts, or\n [Google Groups](/kubernetes-engine/docs/how-to/role-based-access-control#google-groups-for-gke).\n\n If you primarily use GKE, and need fine-grained permissions\n for every object and operation within your cluster, Kubernetes RBAC is the\n best choice.\n- [IAM](#iam) manages Google Cloud resources, including\n clusters, and types of objects within clusters. Permissions are assigned to\n IAM *principals*.\n\n There is no mechanism for granting permissions for specific Kubernetes objects\n within IAM. For instance, you can grant a user permission to\n create CustomResourceDefinitions (CRDs), but you can't grant the user\n permission to create only one specific CustomResourceDefinition, or limit\n creation to a specific Namespace or to a specific cluster in the project.\n An IAM role grants privileges across all clusters in the\n project, or all clusters in all child projects if the role is applied at the\n folder level.\n\n If you use multiple Google Cloud components and you don't need to manage\n granular Kubernetes-specific permissions, IAM is a good choice.\n\nKubernetes RBAC\n---------------\n\nKubernetes has built-in support for RBAC that allows you to create fine-grained\nRoles, which exist within the Kubernetes cluster. A Role can be scoped to a\nspecific Kubernetes object or a type of Kubernetes object, and defines which\nactions (called verbs) the Role grants in relation to that object. A RoleBinding\nis also a Kubernetes object, and grants Roles to users. A\nGKE user can be any of:\n\n- Google Cloud user\n- IAM service account\n- Kubernetes ServiceAccount\n- Google Workspace user\n- Google Workspace Google Group\n- Users authenticated using [X509 client certificates](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs)\n\nTo learn more, refer to\n[Role-Based Access Control](/kubernetes-engine/docs/how-to/role-based-access-control).\n\nIAM\n---\n\nIAM lets you grant *roles* to *principals* . A role is a\ncollection of permissions, and when granted to a principal, allows that\nprincipal to access one or more Google Cloud\n*resources* . For more information about principals, roles, and other\nIAM terminology, see\n[IAM overview](/iam/docs/overview).\n\nIn GKE, a principal can be any of the following:\n\n- User account\n- Service account\n- Google Workspace Google Group\n- Google Workspace domain\n- Cloud Identity domain\n\nFor more information about using IAM to control access in\nGKE, see\n[Create IAM allow policies](/kubernetes-engine/docs/how-to/iam).\n\n### IAM policy types\n\nIAM supports the following policy types:\n\n- **Allow policies** : grant roles to principals. For details, see [Allow policy](/iam/docs/overview#cloud-iam-policy).\n- **Deny policies** : prevent principals from using specific IAM permissions regardless of the roles that those principals are granted. For details, see [Deny policies](/iam/docs/deny-overview).\n\nUse deny policies to restrict specific principals from performing specific\nactions in your project, folder, or organization even if an IAM\nallow policy grants those principals a role that contains the relevant\npermissions.\n\n### IAM recommendations\n\nConsider using the following IAM predefined roles to facilitate\ncommon scenarios:\n\n- [Kubernetes Engine Cluster Viewer](/iam/docs/understanding-roles#container.clusterViewer) (`roles/container.clusterViewer`): DevOps, engineers, and application developers who only need to connect to the cluster.\n- [Kubernetes Engine Cluster Admin](/iam/docs/understanding-roles#container.clusterAdmin) (`roles/container.clusterAdmin`): Platform administrators and cluster operators who need to manage one or more clusters in a Google Cloud project.\n\nFor a list of the available predefined IAM roles, refer\nto [Predefined GKE roles](/kubernetes-engine/docs/how-to/iam#predefined).\n\n\nGKE uses IAM service accounts that are attached to your nodes to\nrun system tasks like logging and monitoring. At a minimum, these *node service accounts*\nmust have the\n[Kubernetes Engine Default Node Service Account](/iam/docs/understanding-roles#container.defaultNodeServiceAccount)\n(`roles/container.defaultNodeServiceAccount`) role on your project. By default,\nGKE uses the\n[Compute Engine default service account](/compute/docs/access/service-accounts#default_service_account),\nwhich is automatically created in your project, as the node service account.\n| **Best practice:** Instead of using the Compute Engine default service account, create a *custom service account* for your nodes to use and give it only the permissions that GKE needs to run system tasks. For more information, see [Use a least\n| privileged service account](/kubernetes-engine/docs/how-to/hardening-your-cluster#use_least_privilege_sa).\n\nIAM interaction with Kubernetes RBAC\n------------------------------------\n\nIAM and Kubernetes RBAC work together to help manage access to\nyour cluster. RBAC controls access on a cluster and namespace level, while\nIAM works on the project level. An entity must have sufficient\npermissions at either level to work with resources in your cluster.\n\nWhat's next\n-----------\n\n- [Read the GKE security overview](/kubernetes-engine/docs/concepts/security-overview).\n- [Learn how to use Kubernetes RBAC](/kubernetes-engine/docs/how-to/role-based-access-control).\n- [Learn how to create IAM policies for GKE](/kubernetes-engine/docs/how-to/iam).\n- [Learn how to use IAM Conditions for load balancers](/load-balancing/docs/access-control/iam-conditions)."]]
