Authentication and authorization in GKE

Access control in Google Kubernetes Engine (GKE) is essential for securing clusters and managing who can perform which operations. In this guide, we’ll dive into the two primary access-control methods—Google Cloud IAM and Kubernetes RBAC—and explore the three types of service accounts used in GKE.

IAM vs. Kubernetes RBAC

Choosing between GCP IAM and Kubernetes RBAC depends on your security requirements:

Feature	GCP IAM	Kubernetes RBAC
Scope	Project-level (all GKE clusters in a project)	Namespace or cluster-level
Permission Granularity	Broad, across multiple Google Cloud services	Fine-grained, Kubernetes API objects & verbs
Principal Types	Users, groups, service accounts	Kubernetes users, groups, service accounts
Best Use Case	Cross-service roles (e.g., billing, logging)	Cluster-specific permissions

Note

Use GCP IAM for overarching control across Google Cloud, and Kubernetes RBAC when you need detailed, in-cluster permissions.

The image is a comparison overview of Kubernetes RBAC and GCP IAM, detailing their features, scope, permissions, and principals. It highlights the differences in managing permissions for Kubernetes clusters and Google Cloud projects.

Google Cloud IAM

Google Cloud’s Identity and Access Management (IAM) lets you assign roles to users, groups, or service accounts at the project level. Each role is a collection of permissions that define what actions can be taken on GKE clusters and other GCP resources.

Scope: Project-wide (all clusters in a project)
Example Role: roles/container.developer (Kubernetes Engine Developer)

gcloud example:

gcloud projects add-iam-policy-binding my-project \
  --member="user:[email protected]" \
  --role="roles/container.developer"

Best for: Broad, cross-service management without per-object granularity

Kubernetes RBAC

Kubernetes Role-Based Access Control (RBAC) is native to the Kubernetes API. It grants permissions on specific Kubernetes resources (pods, deployments, secrets, etc.) at the namespace or cluster level.

ClusterRole: Permissions across the entire cluster
Role: Permissions within a single namespace
RoleBinding / ClusterRoleBinding: Attach Roles or ClusterRoles to subjects (users, groups, service accounts)

Example ClusterRoleBinding for read-only access:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-only-binding
subjects:
- kind: Group
  name: dev-team
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

The image provides an overview of Kubernetes RBAC and GCP IAM, with links to relevant documentation for each.

Service Accounts in GKE

GKE supports three types of service accounts for workload authentication:

Kubernetes Service Accounts
GCP IAM Service Accounts
GKE Service Agents

The image illustrates three types of service accounts: Kubernetes Service Accounts, GCP IAM Service Accounts, and GKE Service Agents, with their respective icons.

1. Kubernetes Service Accounts

Kubernetes Service Accounts are native to Kubernetes. They authenticate Pods to the Kubernetes API server or external services, enabling in-cluster workloads to manage Kubernetes objects.

Scope: Single cluster
Use case: Pod to API-server communication

Create example:

kubectl create serviceaccount my-app-sa --namespace=default

Note

Always assign the minimal set of permissions to a ServiceAccount via Role or ClusterRole.

The image explains Kubernetes Service Accounts, highlighting their use in managing Kubernetes resources, in-cluster entities, API manipulation, and cluster scoping.

2. GCP IAM Service Accounts

GCP IAM Service Accounts are global to a GCP project. They represent non-human identities for applications to call Google APIs and interact with Google Cloud services.

Scope: Project-level
Use case: Granting workloads access to GCP services (e.g., Cloud Storage, Pub/Sub)

Create example:

gcloud iam service-accounts create my-gcp-sa \
  --display-name="My GCP Service Account"

Note

Bind minimal roles (e.g., roles/storage.objectViewer) to limit service-account permissions.

The image explains GCP IAM Service Accounts, highlighting their role in Google Cloud's IAM system, usage by applications on GCP, project scoping, and access control to GCP resources and services.

3. GKE Service Agents

GKE Service Agents are managed by Google to perform cluster lifecycle operations—such as provisioning nodes, disks, and load balancers—on your behalf. When you enable the GKE API, Google automatically creates a service agent with the roles/container.serviceAgent role.

Managed by: Google
Role: roles/container.serviceAgent
Use case: Cluster provisioning and infrastructure management

Warning

Do not delete the GKE Service Agent, as it’s required for cluster operations.

The image explains Kubernetes and GKE Service Accounts, highlighting that they are managed by Google, used for managing cluster resources, have a specific domain, and perform cluster management actions.

Service Account Scope Comparison

Service Account Type	Scope	Primary Use
Kubernetes Service Account	Cluster	In-cluster workloads calling API server
GCP IAM Service Account	Project	Workloads using GCP APIs
GKE Service Agent	Managed by GKE	Cluster lifecycle management

The image compares Kubernetes Service Accounts, scoped within a cluster, with GCP IAM Service Accounts, scoped within a project.

References

Watch Video

Watch video content