Access GCP resources from GKE via Workload Identity
Recently, we’ve implemented GCP Workload Identity in one of our potential customers’ applications(running on GKE) to access GCP services distinctly and securely.
In this blog, I’m going to show how can we leverage the power of GCP Workload Identity for secure access. I’ve written this blog with one primary use case and with some Addon Use-Cases(the ones I worked on and implemented).
Workload Identity
Workload Identity allows you to securely access GCP Services and APIs from applications running on Google Kubernetes Engine(GKE). The trick is to impersonate an IAM service account to access resources, in simple terms, bind your Kubernetes SA to IAM SA.
Upon enabling Workload Identity in GKE Cluster, GKE automatically creates a fixed workload identity pool for the cluster’s Google Cloud project in PROJECT_ID.svc.id.goog format.
When you configure a Kubernetes SA in a namespace to use Workload Identity, IAM authenticates the credentials using the serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KUBERNETES_SERVICE_ACCOUNT] member name.
Note: Enabling Workload Identity doesn’t grant your workloads any IAM permissions by default.
K8s objects that use the configured Kubernetes service account automatically authenticate as the IAM service account when accessing Google Cloud APIs.
Primary Use-Cases
Access secrets from Secret Manager from the application running on GKE
In this use case, we’ll see how to access Cloud SQL DB username and password secrets stored in Secret Manager from applications deployed on Google Kubernetes Engine. Connection to CloudSQL is via Cloud SQL Proxy.
If you a want better understanding of “Why Cloud SQL Proxy is always a better choice”, read this blog: Cloud SQL Auth proxy demystified by Mike Pietruszka and Jake Luna published at SADA Engineering Medium Publication.
Let’s start by creating a secret in Secret Manager; from Security ➞ Secret Manager, I’ve created two secrets db_user and db_password consumed by the application to make a connection with CloudSQL via CloudSQL Proxy. CloudSQL proxy would be a sidecar container running in the same application pod which you have to define specs in the deployment manifest file.
Update your container spec as below which allows CloudSQL Proxy to run as a sidecar container.
.
.
spec:
serviceAccountName: workload-sa
containers:
- name: cloudsql-proxy
image: gcr.io/cloudsql-docker/gce-proxy:1.33.1
command: ["/cloud_sql_proxy",
"-instances=rohan-orbit:asia-southeast1:stark=tcp:0.0.0.0:5432"]
- name: app-container
image: gcr.io/rohan-orbit/app-container:<VERSION>
imagePullPolicy: Always
.
.Don’t forget to update the application property file with localhost.
Once done with the above steps, it’s time to set up Workload Identity.
- Create GCP SA which will be bound to K8s SA:
gcloud iam service-accounts create gke-wl-sa --project=rohan-orbit- Bind necessary IAM roles to the GCP SA:
gcloud projects add-iam-policy-binding rohan-orbit \
--member "serviceAccount:gke-wl-sa@rohan-orbit.iam.gserviceaccount.com" \
--role "roles/cloudsql.client"- Create K8s SA for workload identity in the thor namespace:
kubectl -n thor create sa workload-sa- Bind K8s SA with GCP SA:
gcloud iam service-accounts add-iam-policy-binding \
--role="roles/iam.workloadIdentityUser" \
--member="serviceAccount:rohan-orbit.svc.id.goog[thor/workload-sa]" \
gke-wl-sa@rohan-orbit.iam.gserviceaccount.com- Annotate K8s SA:
kubectl -n thor annotate serviceaccount workload-sa iam.gke.io/gcp-service-account=gke-wl-sa@rohan-orbit.iam.gserviceaccount.comOnce workload identity has been set up properly, you’ll see that cloudsql proxy(sidecar container) is able to connect with Cloud SQL.
Note: You’ll see unauthorized access in cloudsql proxy logs if workload identity doesn’t exist.
Addon use-cases
- Assuming your application which is deployed and running on GKE does some processing and generate artifacts that need to be pushed to GCS or Artifact Registry and which further sends a message to Pub/Sub. In order to let your GKE app upload files over GCS or Artifact Registry securely, you can leverage Workload Identity.
- Assume there is one more application which needs to publish messages to Cloud PubSub which will be utilised by Cloud Function which further sends a message over Slack Channel with info. I’ve written a blog demonstrating PubSub being utilised by Cloud Function to post messages over Slack. Here is the link.
Note: I’ll keep adding more use-cases in Addon use-cases section whenever I implement new.
Read my other Cloud/DevOps/Infra blogs:-
Read industry professional interviews:-
Clap if you find this solution informative and useful.
Follow and subscribe to my medium space to stay tuned for interviews and tech blogs. To know more about me, check my website. Till then have a good day and Sayonara!!!
