When you create a Google Cloud project, you are the only user on the project. By default, no other users have access to your project or its resources, including Google Kubernetes Engine resources. Google Kubernetes Engine supports multiple options for managing access to resources within your project and its clusters using role-based access control (RBAC).
These mechanisms have some functional overlap, but are targeted to different types of resources. Each is explained in a section below, but in brief:
Kubernetes RBAC is built into Kubernetes, and grants granular permissions to objects within Kubernetes clusters. Permissions exist as ClusterRole or Role objects within the cluster. RoleBinding objects grant Roles to Kubernetes users, Google Cloud users, Google Cloud service accounts, or Google Groups (beta).
If you primarily use GKE, and need fine-grained permissions for every object and operation within your cluster, Kubernetes RBAC is the best choice.
IAM manages Google Cloud resources, including clusters, and types of objects within clusters. Permissions are assigned to IAM members, which exist within Google Cloud, G Suite, or Cloud Identity.
There is no mechanism for granting permissions for specific Kubernetes objects within IAM. For instance, you can grant a user permission to create CustomResourceDefinitions (CRDs), but you can't grant the user permission to create only one specific CustomResourceDefinition, or limit creation to a specific Namespace or to a specific cluster in the project. An IAM role grants privileges across all clusters in the project, or all clusters in all child projects if the role is applied at the folder level.
If you use multiple Google Cloud components and you don't need to manage granular Kubernetes-specific permissions, IAM is a good choice.
Kubernetes has built-in support for RBAC that allows you to create fine-grained Roles, which exist within the Kubernetes cluster. A Role can be scoped to a specific Kubernetes object or a type of Kubernetes object, and defines which actions (called verbs) the Role grants in relation to that object. A RoleBinding is also a Kubernetes object, and grants Roles to users. In a GKE user can be any of:
- Google Cloud user
- Google Cloud service account
- Kubernetes service account
- G Suite user
- G Suite Google Group (beta)
To learn more, refer to Role-Based Access Control.
IAM allows you to define roles and assign them to members. A role is a collection of permissions, and when assigned to a member, controls access to one or more Google Cloud resources. Roles fall into three broad categories:
- Basic roles provide coarse permissions limited to Owner, Editor, and Viewer.
- Pre-defined roles, such as the pre-defined roles for GKE, provide finer-grained access than basic roles and address many common use cases.
- Custom roles allow you to create unique combinations of permissions.
A member can be any of:
- Google account
- Service account
- Google group
- G Suite domain
- Cloud Identity domain
An IAM policy assigns a set of permissions to one or more Google Cloud members.
You can also use IAM to create and configure service accounts, which are Google Cloud accounts associated with your project that can perform tasks on your behalf. Service accounts are assigned roles and permissions in the same way as human users.
Service accounts provide other functionality as well. To learn more, refer to Creating IAM Policies.
IAM interaction with Kubernetes RBAC
IAM and Kubernetes RBAC work together to help manage access to your cluster. RBAC controls access on a cluster and namespace level, while IAM works on the project level. An entity must have sufficient permissions at either level to work with resources in your cluster.
- 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.