[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-04。"],[],[],null,["# Create IAM allow policies\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page explains how to create Identity and Access Management (IAM)\nallow policies for authorization in Google Kubernetes Engine (GKE).\n\nEvery Google Cloud, GKE, and Kubernetes API call requires that\nthe account making the request has the necessary permissions. By default, no one\nexcept you can access your project or its resources. You can use\nIAM to manage who can access your project and what they are\nallowed to do. IAM permissions work alongside\n[Kubernetes RBAC](/kubernetes-engine/docs/role-based-access-control), which\nprovides granular access controls for specific objects inside a cluster or\nnamespace. IAM has a stronger focus on permissions at the project\nand organization level, though it does provide several predefined roles specific\nto GKE.\n\nTo grant users and service accounts access to your Google Cloud project,\nyou [add them as project team members](/iam/docs/granting-changing-revoking-access),\nthen [assign roles](#managing) to the team members. Roles define which\nGoogle Cloud resources an account can access and which operations they can\nperform.\n\nIn GKE, you can also use IAM to manage which users\nand service accounts can access, and perform operations in, your clusters.\n\nThis page is for\nSecurity specialists and Operators who use IAM\nallow policies to manage authorization in GKE clusters. 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\nBefore reading this page, ensure that you're familiar with the following concepts:\n\n- [General overview of IAM](/iam/docs/overview)\n- [General overview of IAM and role-based access control (RBAC) in GKE](/kubernetes-engine/docs/concepts/access-control)\n\nBefore you begin\n----------------\n\nBefore you start, make sure that you have performed the following tasks:\n\n- Enable the Google Kubernetes Engine API.\n[Enable Google Kubernetes Engine API](https://console.cloud.google.com/flows/enableapi?apiid=container.googleapis.com)\n- If you want to use the Google Cloud CLI for this task, [install](/sdk/docs/install) and then [initialize](/sdk/docs/initializing) the gcloud CLI. If you previously installed the gcloud CLI, get the latest version by running `gcloud components update`. **Note:** For existing gcloud CLI installations, make sure to set the `compute/region` [property](/sdk/docs/properties#setting_properties). If you use primarily zonal clusters, set the `compute/zone` instead. By setting a default location, you can avoid errors in the gcloud CLI like the following: `One of [--zone, --region] must be supplied: Please specify location`. You might need to specify the location in certain commands if the location of your cluster differs from the default that you set.\n\nUse IAM with Kubernetes RBAC\n----------------------------\n\nKubernetes has a built-in access control mechanism,\n[role-based access control (RBAC)](/kubernetes-engine/docs/role-based-access-control).\nRBAC controls access on a cluster and namespace level, while IAM\nworks on the project level.\n\nIAM and RBAC can work together. An entity must have sufficient\nRBAC and IAM permissions to work with resources in your cluster.\n\nUnderstand IAM roles\n--------------------\n\nThe following sections describe the types of IAM roles that you\ncan use to control access to your Google Cloud resources. For more\ninformation about each of these types of roles and when to use them, see\n[Choose which type of role to use](/iam/docs/choose-role-type).\n\n### Predefined GKE roles\n\nIAM provides [predefined roles](/iam/docs/understanding-roles#predefined_roles)\nthat grant access to specific Google Cloud resources and prevent\nunauthorized access to other resources.\n\nIAM offers the following predefined roles for GKE. \n\nFor more information about the individual permissions in each predefined role,\nsee\n[Google Kubernetes Engine roles and permissions](/iam/docs/roles-permissions/container).\nYou can also view the permissions in each IAM role using the\ngcloud CLI or the Google Cloud console. For instructions, refer to\n[View permissions granted by IAM roles](#permissions).\n\n### Basic IAM roles\n\nBasic IAM Roles grant users global, project-level access to all\nGoogle Cloud resources. To keep your project and clusters secure, use\n[predefined Roles](#predefined) whenever possible.\n\nTo learn more about basic roles, refer to\n[Basic roles](/iam/docs/understanding-roles#basic) in the IAM\ndocumentation.\n\n### Custom roles\n\nIf [predefined roles](#predefined) don't meet your needs, you can create\n[custom roles](/iam/docs/understanding-custom-roles) with permissions that you\ndefine.\n\nTo learn how to create and assign custom roles, refer to\n[Creating and managing custom roles](/iam/docs/creating-custom-roles).\n\nChoose roles and permissions for your principals\n------------------------------------------------\n\nThe principals in your Google Cloud environment, such as users and\nworkloads, might need access to various Google Cloud resources to perform\nspecific tasks. For example, consider a Kubernetes workload that uses\nWorkload Identity Federation for GKE to store data in a Cloud Storage bucket. To give the\nworkload the permissions that it needs, you grant a role that contains those\npermissions to the principal identifier for that workload.\n\nThe permissions that a principal needs depends on the following factors:\n\n- The resources that the principal needs to access, such as Cloud Storage buckets.\n- The task that the principal needs to perform, such as writing to a bucket or reading metadata.\n\nYou can give permissions to a principal by using a predefined role that contains\nthose permissions, or by creating a custom role. Unless you require a custom\nrole, we recommend that you use a predefined role. For more information about\nidentifying the permissions that your principals need and giving those\npermissions to the principals, see\n[Find the right predefined role](/iam/docs/choose-predefined-roles).\n\nView permissions granted by IAM roles\n-------------------------------------\n\nYou can view the permissions granted by each role using the gcloud CLI\nor the Google Cloud console. \n\n### gcloud\n\nTo view the permissions granted by a specific role, run the following\ncommand: \n\n gcloud iam roles describe roles/\u003cvar translate=\"no\"\u003eROLE\u003c/var\u003e\n\nReplace \u003cvar translate=\"no\"\u003eROLE\u003c/var\u003e with any IAM role.\nGKE roles are prefixed with `roles/container`, such as\n`gcloud iam roles describe roles/container.admin`.\n\n### Console\n\nTo view the permissions granted by a specific role, perform the following\nsteps:\n\n1. Go to the **Roles** section of the **IAM \\& Admin**\n page on the Google Cloud console.\n\n [Go to IAM \\& Admin](https://console.cloud.google.com/iam-admin/roles)\n2. To see the roles for GKE, in the **Filter table** field,\n enter `Kubernetes Engine`.\n\n3. Select the role you want to view. The description of the role and a list of\n assigned permissions displays.\n\nManage IAM roles\n----------------\n\nTo learn how to manage IAM roles and permissions for human\nusers, refer to\n[Granting, changing, and revoking access to project members](/iam/docs/granting-changing-revoking-access)\nin the IAM documentation.\n\nFor *service accounts* , refer to\n[Granting roles to service accounts](/iam/docs/granting-roles-to-service-accounts).\n\nExamples of IAM use cases\n-------------------------\n\nHere are a few examples of how IAM works with GKE:\n\n- A new employee has joined a company. They need to be added to the Google Cloud project, but they only need to view the project's clusters and other Google Cloud resources. The project owner assigns them the project-level [Compute Viewer](/compute/docs/access/iam#compute.viewer) role. This role provides read-only access to get and list nodes, which are Compute Engine resources.\n- The employee is working in operations, and they need to update a cluster using `gcloud` or the Google Cloud console. This operation requires the `container.clusters.update` permission, so the project owner assigns them the Kubernetes Engine Cluster Admin role. The employee now has the permissions granted by both the Kubernetes Engine Cluster Admin and Compute Viewer roles.\n- The employee needs to investigate why a Deployment is having issues. They need to run `kubectl get pods` to see Pods running in the cluster. The employee already has the Compute Viewer role, which is not sufficient for listing Pods. The employee needs the Kubernetes Engine Viewer role.\n- The employee needs to create a new cluster. The project owner grants the the Service Account User role on the \u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e`-compute@developer.gserviceaccount.com` service account to the employee so that the employee's account can access Compute Engine's default service account. GKE attaches this service account to nodes by default so that system workloads can send data like logs and metrics to Google Cloud.\n\nWhat's next\n-----------\n\n- [Read the access control overview](/kubernetes-engine/docs/concepts/access-control)\n- [Learn about managing access to Google Cloud resources](/iam/docs/manage-access-other-resources)\n- [Learn more about allow policies](/iam/docs/policies)\n- [Learn about deny policies](/iam/docs/deny-overview)"]]
