Understanding Workload Identity in GKE

Image by author

What is Workload Identity?

In Google Kubernetes Engine (GKE), Workload Identity is a method that allows your applications running on GKE to authenticate to Google Cloud services without needing to manage service account keys. It simplifies the process of assigning and managing identities for your workloads, enhancing security and reducing the complexity of key management.

Breaking Down the Concept

To understand Workload Identity, let’s start with a basic scenario. Imagine you’re working in an office building with several departments: HR, Finance, IT, and so on. Each department has certain access rights: HR can access employee records, Finance can access budget reports, and IT can access all systems for maintenance.

Now, suppose each department needs to send a representative to a central library to get specific documents. Instead of giving each representative a master key (which is risky if lost), you issue them an ID card that lets them access only the areas they are authorized to enter. This is much safer and easier to manage.

How Does Workload Identity Work?

In GKE, the concept is similar. Instead of giving each application a key (which could be stolen or lost), Workload Identity allows your applications to use Kubernetes service accounts to get access to Google Cloud resources securely. Here’s how it works in simple terms:

1. Kubernetes Service Account (KSA): Each application (or pod) in your GKE cluster can be associated with a Kubernetes Service Account.
2. Google Service Account (GSA): This is a Google Cloud identity that has permissions to access specific Google Cloud resources, like Pub/Sub, Cloud Storage, or BigQuery.
3. Binding KSA to GSA: You bind the Kubernetes Service Account to the Google Service Account. This means when the application uses the KSA, it automatically gets the permissions of the GSA.

Steps to Implement Workload Identity

Let's walk through the process of setting up Workload Identity step-by-step.

1. Enable the Workload Identity Feature

First, ensure that Workload Identity is enabled on your GKE cluster. This can be done during cluster creation or on an existing cluster.

gcloud container clusters update <CLUSTER_NAME> \
    --workload-pool=<PROJECT_ID>.svc.id.goog

Replace <CLUSTER_NAME> with your GKE cluster's name and <PROJECT_ID> with your Google Cloud project ID.

2. Create a Google Service Account (GSA)

Create a GSA that your workload will use to access Google Cloud services

gcloud iam service-accounts create <GSA_NAME> \
    --display-name "Google Service Account for Workload Identity"

Grant the necessary roles to the GSA to access the required Google Cloud services.

gcloud projects add-iam-policy-binding <PROJECT_ID> \
    --member="serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
    --role="roles/<REQUIRED_ROLE>"

Replace <GSA_NAME>, <PROJECT_ID>, and <REQUIRED_ROLE> with your service account name, project ID, and the role required for your service, respectively.

3. Create a Kubernetes Service Account (KSA)

Create a KSA in your Kubernetes cluster that will be associated with your application.

kubectl create serviceaccount <KSA_NAME> --namespace <NAMESPACE>

Replace <KSA_NAME> with your desired Kubernetes service account name and <NAMESPACE> with the namespace where your application is deployed.

4. Bind the KSA to the GSA

To bind the KSA to the GSA, you need to create an IAM policy binding that grants the KSA the permissions of the GSA.

gcloud iam service-accounts add-iam-policy-binding <GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:<PROJECT_ID>.svc.id.goog[<NAMESPACE>/<KSA_NAME>]"

Replace <GSA_NAME>, <PROJECT_ID>, <NAMESPACE>, and <KSA_NAME> with the appropriate values.

5. Annotate the KSA with the GSA

Annotate the KSA to link it with the GSA.

kubectl annotate serviceaccount <KSA_NAME> \
    --namespace <NAMESPACE> \
    iam.gke.io/gcp-service-account=<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com

6. Deploy Your Application

Deploy your application, ensuring it uses the annotated KSA. Here is an example deployment YAML file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: <NAMESPACE>
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      serviceAccountName: <KSA_NAME>
      containers:
      - name: my-app-container
        image: gcr.io/<PROJECT_ID>/my-app-image
        ...

Replace <NAMESPACE>, <KSA_NAME>, <PROJECT_ID>, and my-app-image with your specific values.

That’s it for this article, I’ll comeup with something more intresting and new. If you’ve felt this article useful and informative share it with your friends and colleagues, don’t forget to follow The kube guy 🙂