How to Authorize Kubernetes Pods in Rancher Desktop to Google Cloud APIs Using Workload Identity Federation (WIF)
In this post, I’ll show you how I used Workload Identity Federation (WIF) to authorize a Kubernetes pod running in Rancher Desktop to access Google Cloud APIs—without needing service account keys. This approach simplifies authentication by using federated identities for workload access, making it more secure and manageable.
Why Use Workload Identity Federation?
Workload Identity Federation (WIF) eliminates the need to handle service account keys. Instead of relying on long-lived keys, you use identity federation to authenticate workloads. This improves security, as there are no keys to rotate or expose, and is ideal for cloud-native environments like Kubernetes.
Steps to Set Up Workload Identity Federation with Rancher Desktop
1. Ensure prerequisites are met
Ensure that your Rancher Desktop cluster meets the following:
- Kubernetes version 1.20 or higher.
- ServiceAccount token volume projections enabled in kube-apiserver. In Rancher Desktop, this is typically already enabled since it's based on K3s, which supports projected volumes.
2. Set up the Kubernetes cluster issuer
To get the cert and key:
$ kubectl config view -o=jsonpath="{.users[?(@.name == 'rancher-desktop')].user.client-certificate-data}" --flatten | base64 -d > rancher.crt
$ kubectl config view -o=jsonpath="{.users[?(@.name == 'rancher-desktop')].user.client-key-data}" --flatten | base64 -d > rancher.key
- Retrieve the cluster's issuer URL:
$ curl -k --cert rancher.crt --key rancher.key https://127.0.0.1:6443/.well-known/openid-configuration
The expected format is something like https://kubernetes.default.svc.
- Download the JWKS for the cluster:
$ curl -k --cert rancher.crt --key rancher.key https://127.0.0.1:6443/openid/v1/jwks > cluster-jwks.json
Rancher Desktop will expose this endpoint since it's based on standard Kubernetes configurations.
3. Create the workload identity pool and provider in GCP
- Create a Workload Identity Pool:
gcloud iam workload-identity-pools create rancher-cowboy \
--location="global" \
--description="Workload identity for Rancher Desktop" \
--display-name="Rancher Desktop Pool"
- Add the Rancher Desktop Kubernetes cluster as a provider:
gcloud iam workload-identity-pools providers create-oidc rancher-desktop\
--location="global" \
--workload-identity-pool="rancher-cowboy" \
--issuer-uri="https://kubernetes.default.svc" \
--attribute-mapping="google.subject=assertion.sub" \
--jwk-json-path="cluster-jwks.json"
4. Grant IAM access
Grant access to the Kubernetes ServiceAccount:
$ gcloud projects add-iam-policy-binding PROJECT_ID \
--role=roles/viewer \
--member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/rancher-cowboy/subject/system:serviceaccount:default:default
5. Deploy the Kubernetes workload
Sample workload with alpine image and gcloud installed to test the access
apiVersion: v1
kind: Pod
metadata:
name: horse
namespace: default
spec:
containers:
- name: rhorse
image: google/cloud-sdk:alpine
command: ["/bin/sh", "-c", "gcloud auth login --cred-file $GOOGLE_APPLICATION_CREDENTIALS && gcloud auth list && sleep 600"]
volumeMounts:
- name: token
mountPath: "/var/run/service-account"
readOnly: true
- name: workload-identity-credential-configuration
mountPath: "/etc/workload-identity"
readOnly: true
env:
- name: GOOGLE_APPLICATION_CREDENTIALS
value: "/etc/workload-identity/credential-configuration.json"
serviceAccountName: default
volumes:
- name: token
projected:
sources:
- serviceAccountToken:
audience: https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/rancher-cowboy/providers/rancher-desktop
expirationSeconds: 3600
path: token
- name: workload-identity-credential-configuration
configMap:
name: wif-cm
6. Authentication and verification
Verify authentication:
$ kubectl exec horse --namespace default -- gcloud auth print-access-token
$ kubectl exec horse --namespace default -- gcloud iam service-accounts list --project PROJECT_ID
This setup ensures that Rancher Desktop running locally on your laptop can securely authenticate workloads with GCP using Workload Identity Federation.
Wait what happened? How did this work?
Workload Requests GCP Access, A K8s Pod in Rancher Desktop runs with a ServiceAccount, which is configured to receive a projected OIDC token.
-
Kubernetes Issues OIDC Token, The K8s API server generates an OIDC-compatible JWT for the Pod based on the ServiceAccount and its audience.
- Token Details, The token contains claims like:
-
Issuer
iss: The Kubernetes API server's OIDC URL. -
Audience
aud: The target GCP Workload Identity Pool URL. -
Subject
sub: The identity of the ServiceAccountsystem:serviceaccount:<namespace>:<service-account-name>. - The token is signed by the K8s cluster.
Pod Passes Token to GCP: The token is presented to GCP during API requests via the Google Cloud SDK or client libraries in the workload.
-
GCP verifies the OIDC token by
- Checking the token signature against the trusted Kubernetes OIDC issuer's public keys (usually from a .well-known/openid-configuration endpoint).
- Ensuring that the token audience matches the configured audience for the GCP WIF provider.
- Validating claims (like expiration and ServiceAccount identity).
In conclusion, I successfully authorized a Kubernetes pod running in Rancher Desktop to interact with Google Cloud APIs using Workload Identity Federation. This method eliminated the need for managing service account keys and simplified the authentication process using federated identities. It’s a more secure and scalable solution for accessing Google Cloud resources from Kubernetes workloads.
If you're looking to improve the security of your Kubernetes workloads, I highly recommend exploring Workload Identity Federation. It’s a great way to manage cloud access without the overhead of key management.
Top comments (0)