This document describes the differences between Identity and Access Management (IAM) andKubernetes role-based access control (RBAC) in Google Kubernetes Engine to help you manageaccess to resources within your project. This document assumes that you knowabout the following:

• Overview of IAM in GKE
• Overview of Kubernetes RBAC

This document is for Security specialists who control access to permissions andwant to understand the differences and overlap between IAM andRBAC. To learn more about common roles and example tasks that we reference inGoogle Cloud content, seeCommon GKE user roles and tasks .

Manage access to GKE resources

When you create a Google Cloud project, you are the only user on the project. Bydefault, no other users have access to your project or its resources, includingGoogle Kubernetes Engine (GKE) resources. GKE supports multipleoptions for managing access to resources within your project and its clustersusing role-based access control (RBAC).

These mechanisms have some functional overlap, but are targeted to differenttypes of resources. Each is explained in a dedicated section on this page, but in brief:

• Kubernetes RBAC is built into Kubernetes, and grants granularpermissions to objects within Kubernetes clusters. Permissions exist asClusterRole or Role objects within the cluster. RoleBinding objects grantRoles toKubernetes users, Google Cloud users, IAMservice accounts, orGoogle Groups.

  If you primarily use GKE, and need fine-grained permissionsfor every object and operation within your cluster, Kubernetes RBAC is thebest choice.

• IAM manages Google Cloud resources, includingclusters, and types of objects within clusters. Permissions are assigned toIAMprincipals.

  There is no mechanism for granting permissions for specific Kubernetes objectswithin IAM. For instance, you can grant a user permission tocreate CustomResourceDefinitions (CRDs), but you can't grant the userpermission to create only one specific CustomResourceDefinition, or limitcreation to a specific Namespace or to a specific cluster in the project.An IAM role grants privileges across all clusters in theproject, or all clusters in all child projects if the role is applied at thefolder level.

  If you use multiple Google Cloud components and you don't need to managegranular Kubernetes-specific permissions, IAM is a good choice.

Kubernetes RBAC

Kubernetes has built-in support for RBAC that lets you create fine-grainedRoles, which exist within the Kubernetes cluster. A Role can be scoped to aspecific Kubernetes object or a type of Kubernetes object, and defines whichactions (called verbs) the Role grants in relation to that object. A RoleBindingis also a Kubernetes object, and grants Roles to users. AGKE user can be any of:

• Google Cloud user
• IAM service account
• Kubernetes ServiceAccount
• Google Workspace user
• Google Workspace Google Group
• Users authenticated usingX509 client certificates

To learn more, refer toRole-Based Access Control.

IAM

IAM lets you grantroles toprincipals. A role is acollection of permissions, and when granted to a principal, allows thatprincipal to access one or more Google Cloudresources. For more information about principals, roles, and otherIAM terminology, seeIAM overview.

In GKE, a principal can be any of the following:

• User account
• Service account
• Google Workspace Google Group
• Google Workspace domain
• Cloud Identity domain

For more information about using IAM to control access inGKE, seeCreate IAM allow policies.

IAM policy types

IAM supports the following policy types:

• Allow policies: grant roles to principals. For details, seeAllow policy.
• Deny policies: prevent principals from using specific IAMpermissions regardless of the roles that those principals are granted. Fordetails, seeDeny policies.

Use deny policies to restrict specific principals from performing specificactions in your project, folder, or organization even if an IAMallow policy grants those principals a role that contains the relevantpermissions.

IAM recommendations

Consider using the following IAM predefined roles to facilitatecommon scenarios:

• Kubernetes Engine Cluster Viewer (roles/container.clusterViewer): DevOps,engineers, and application developers who only need to connect to thecluster.
• Kubernetes Engine Cluster Admin (roles/container.clusterAdmin): Platformadministrators and cluster operators who need to manage one or more clustersin a Google Cloud project.

For a list of the available predefined IAM roles, refertoPredefined GKE roles.

GKE uses IAM service accounts that are attached to your nodes to run system tasks like logging and monitoring. At a minimum, thesenode service accounts must have theKubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) role on your project. By default, GKE uses theCompute Engine default service account, which is automatically created in your project, as the node service account.

Best practice: Instead of using the Compute Engine default service account, create acustom service account for your nodes to use and give it only the permissions that GKE needs to run system tasks. For more information, seeConfigure a custom node service account.

IAM interaction with Kubernetes RBAC

IAM and Kubernetes RBAC work together to help manage access toyour cluster. RBAC controls access on a cluster and namespace level, whileIAM works on the project level. An entity must have sufficientpermissions at either level to work with resources in your cluster.

What's next

• Read the GKE security overview.
• Learn how to use Kubernetes RBAC.
• Learn how to create IAM policies for GKE.
• Learn how to use IAM Conditions for load balancers.