Workload Access Control In Google Kubernetes Engine with Workload Identity

Managing workload permissions in Kubernetes has long been a challenging task, especially when a pod needs to access a cloud resource. This typically necessitates using service account keys, which can be cumbersome to manage and pose security risks. Google’s Workload Identity is an innovative solution that directly addresses these challenges, simplifying permissions and authentication in Kubernetes

What is Workload Identity ?

Google Kubernetes Engine (GKE) Workload Identity is a feature that allows you to map a Kubernetes Service Account to a Google Cloud IAM (Identity and Access Management) Service Account so that users can manage pods permissions using IAM.

In this article, I will discuss the utility of GKE Workload Identity, use cases, and then walk through the setup of one use case.

Some use cases when workload identity can help save the day

GKE Workload Identity is useful in several ways:

1. Simplifies authentication: I no longer need to create and manage application credentials. Instead, I can use IAM service accounts to authenticate to Google Cloud resources.
2. Enhances security: By using IAM service accounts, I can control access to Google Cloud resources using IAM roles and policies, which reduces the risk of secrets management.
3. Improves manageability: By using IAM service accounts, I can enforce the least privilege principle and make it easier to manage the access rights of my applications.

Some common use cases for GKE Workload Identity include:

1. Accessing Google Cloud Storage: If my application requires access to Google Cloud Storage, I can use GKE Workload Identity to securely access the storage without managing the application credentials.
2. Accessing Google BigQuery: If my application requires access to Google BigQuery, I can use GKE Workload Identity to securely access the data without managing the application credentials.
3. Accessing Google Cloud SQL: If my application requires access to Google Cloud SQL, I can use GKE Workload Identity to securely access the database without managing the application credentials.

To understand the value of Workload Identity, consider what it would be like to set up these use cases without this feature. In the absence of Workload Identity, you would need to manage and store application credentials, which can be difficult and error-prone, especially in large and complex environments. With Workload Identity, you have a centralised Identity and Access Management (IAM) solution, making it easy to manage permissions and ensure that your applications have the correct access to the resources they need.

How to setup GKE workload Identity

In this section, I will walk through the setup of the first use case: Accessing Google Cloud Storage. To set up GKE Workload Identity, follow these steps:

Step1 : Enable workload identity on your Kubernetes cluster

gcloud container clusters update <cluster-name> --workload-pool=<project-id>.svc.id.goog

The result should be something like this :

$ gcloud container clusters update cluster-1 --zone europe-west9-a --workload-pool=poc-tgw.svc.id.goog
Default change: During creation of nodepools or autoscaling configuration changes for cluster versions greater than 1.24.1-gke.800 a default location policy is applied. For Spot and PVM it defaults to ANY, and for all other VM kinds a BALANCED policy is used. To change the default values use the `--location-policy` flag.
Updating cluster-1...
Updated [<https://container.googleapis.com/v1/projects/poc-tgw/zones/europe-west9-a/clusters/cluster-1>].
To inspect the contents of your cluster, go to: <https://console.cloud.google.com/kubernetes/workload_/gcloud/europe-west9-a/cluster-1?project=poc-tgw>

Step 2 : Create a Google Cloud IAM Service Account: For example, here is a script that can be run in the command line to create the service account :

gcloud iam service-accounts create iam-service-account \\ --display-name "Service account for my-app"

Step 3: Grant the necessary permissions to the IAM Service Account: For accessing Google Cloud Storage, you can grant the “Storage Object Viewer” role. Here is a script to grant this permission:

gcloud projects add-iam-policy-binding <project-id> \
--member serviceAccount:iam-service-account@<project-id>.iam.gserviceaccount.com \
--role roles/storage.objectViewer

Step 4 : Create a Kubernetes Service Account: For example, you can use the following command:

kubectl create serviceaccount k8s-service-account

Step 5 : Bind the Kubernetes Service Account to the IAM Service Account: For example, you can use the following command:

kubectl annotate serviceaccount k8s-service-account \
iam.gke.io/gcp-service-account=iam-service-account@<project-id>.iam.gserviceaccount.comStep 6: Deploy your application: Finally, deploy your application using the Kubernetes Service Account.

Testing the new GKE workload Identity setup

Step 1: First you need to create a Google Cloud Storage bucket with uniform access control and upload some files to it. For example, to create a bucket named “my-example-bucket”:

gsutil mb -p <project-id> -c STANDARD -l us-east1 gs://my-example-bucket/

Step 2: Second, you need to create a Kubernetes manifest that deploys an application that accesses Google Cloud Storage using GKE Workload Identity:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      serviceAccountName: k8s-service-account
      containers:
      - name: my-app
        image: google/cloud-sdk:alpine
        command: ["gsutil", "ls", "gs://my-example-bucket"]

In this example, image field specifies the google/cloud-sdk:alpine Docker image, which includes the gsutil tool that allows you to interact with Google Cloud Storage.

Step 3:This manifest can be deployed using the kubectl apply command:

kubectl apply -f <manifest-file-name>.yaml

Step 4: Get pod logs and make sure that all files in specified bucket are listed in the output

$ kubectl logs -f deployment.apps/my-app

The command output must be something like this, in my case i upload one file api.jpg

$ kubectl logs -f deployment.apps/my-app
gs://my-example-bucket/api.jpg

With this setup, your application can access Google Cloud Storage using GKE Workload Identity, without having to manage the application credentials.

Conclusion

By adopting Workload Identity, developers can reduce operational overhead, mitigate security risks, and focus on building robust, scalable applications. As Kubernetes continues to evolve, embracing innovative solutions like Workload Identity will undoubtedly prove crucial in navigating the ever-changing landscape of container orchestration and cloud-native technologies.

Originally published at https://hassene.belgacem.io .