Cross-Cloud Trust Between AKS and GCP Using OIDC¶

Overview¶

This document outlines how to configure cross-cloud trust between Azure Kubernetes Service (AKS) and Google Cloud Platform (GCP) using OIDC and Workload Identity Federation. This setup enables pods running in AKS to securely access GCP resources without storing or using GCP service account keys.

We rely on Workload Identity Federation, which allows GCP to accept OIDC tokens issued by AKS.

Architecture¶

AKS Pod
  |
  |---> Gets OIDC Token (projected via service account)
        |
        |---> Sends token to GCP STS (Security Token Service)
              |
              |---> GCP validates token against Workload Identity Pool
                    |
                    |---> Returns short-lived access token to access GCP APIs

Benefits¶

🔐 No long-lived secrets in Kubernetes
🔄 Short-lived and scoped credentials
🎯 Fine-grained IAM roles in GCP
☁️ Cross-cloud identity federation

Prerequisites¶

AKS cluster with OIDC issuer enabled
A GCP project (terraform-state in this case)
Permissions to configure IAM and Workload Identity Federation in GCP

Step-by-Step Setup¶

Step 1: Retrieve OIDC Issuer URL from AKS¶

First, fetch the OIDC issuer URL for your AKS cluster:

az aks show \
  --name <AKS_CLUSTER_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --query "oidcIssuerProfile.issuerUrl" \
  --output tsv

You will get a URL like:

https://oidc.prod-aks.azure.com/<uuid>/

Step 2: Create a Workload Identity Pool in GCP¶

2.1 Go to GCP Console → IAM → Workload Identity Federation¶

Create a new Workload Identity Pool
- Name: aks-pool
- Pool ID: aks-pool
- Project: terraform-state

Add a Provider within the pool
- Name: aks-oidc-provider
- Provider Type: OIDC
- Issuer URI: Use the OIDC URL from Step 1
- Acceptable audiences: api://AzureADTokenExchange (default for AKS)
📂 Full configuration:
➡ Terraform GCP Workload Identity Pool Code

Step 3: Link GCP IAM Permissions to AKS service accounts¶

You don’t need to create a GCP service account. Instead, GCP IAM can directly recognize a Kubernetes service account from AKS and assign permissions.

Principle name should look sonething like this

principal://iam.googleapis.com/projects/632304642337/locations/global/workloadIdentityPools/prod-aks-workload-identity-pool/subject/system:serviceaccount:<namespace>:<serviceAccountName>

Step 4: Configure Kubernetes pod¶

Pod needs below mentioned 3 things

Mount a projected token volume so that the workload can obtain a Kubernetes ServiceAccount token from a local file.

Mount the ConfigMap that contains the credential configuration file so that the workload can access the necessary configuration for using Workload Identity Federation.

Add an environment variable GOOGLE_APPLICATION_CREDENTIALS that contains the path of the credential configuration file so that workloads can find the file.

Helm templates for backend have been updated to support GCP trust

Helm Templates

Test the Integration¶

Deploy a pod using the configured service account and test access to GCP resources. For example, access GCS:

Run gcloud commands inside the pod to verify that you have access to GCP resources

Summary¶

With this setup:

AKS pods authenticate to GCP using projected OIDC tokens.
No need for GCP service account keys or secrets in Kubernetes.