Virtualization Technology News and Information
Enabling Secure Cloud Access for Kubernetes Workloads through Identity Federation in Google Cloud Platform (GCP)
There is a genuine need for Kubernetes workloads (K8s) to gain access to sensitive cloud resources.  This concept isn't new to many users of managed Kubernetes services; however, mismanaged identities can create risk. The solution lies in federated identities, simplifying the process of granting access while strengthening security.

It's convenient to use permanent credentials stored as a secret in your K8s cluster, code, or a plaintext artifact. Although time-saving on the surface, providing access this way is playing a dangerous game. Even with the most well-intentioned security controls in place, permanent credentials tend to leak, enabling malicious actors to access sensitive resources in your  environment.

All major Cloud Service Providers (CSPs) have introduced services for federating K8s workloads to  identities within the cloud ecosystem. You can do this using the OIDC authentication protocol, where  the K8s cluster functions as the OIDC issuer and is configured as an OIDC provider in the CSP.

Embracing identity federation eliminates the need to manually manage workload credentials and is  the recommended best practice in the industry. Once set up, identity federation makes giving access  to cloud resources more efficient and secure.

Starting the process of Identity federation for K8s workloads might sound daunting, but it's easier  than many think. In this article, we will review the setup process of identity federation in Google  Kubernetes Engine (GKE).

In GCP you can configure workload identity (find the full tutorial for configuring a GKE workload  identity here) to federate a K8s service account to a GCP IAM service account. The service account is  assigned permissions using the GCP IAM RBAC paradigm.

The instructions are mostly in bash so you need to assign variables with values:




Step 1 - Enable Workload Identity on Your Cluster

To update and enable workload identity on an existing cluster, run the following command:

gcloud container clusters update ${CLUSTER_NAME} -- region=${COMPUTE_REGION} --workload-pool=${PROJECT_ID}

When creating a new cluster, keep in mind that Autopilot clusters enable workload identity by default. When creating a cluster from the command line you can enable workload identity with the following command:

gcloud container clusters create ${CLUSTER_NAME} -- region=${COMPUTE_REGION} --workload-pool=${PROJECT_ID}

Note that if you're using an existing cluster, you should review the section in the GCP tutorial  on existing node pools.

Step 2 - Create an IAM Service Account to Federate

Here are the variables you need:



To start you'll need to create an identity for the K8s service account to federate with. In the case of GCP, the identity is an IAM service account (yes, the two types of identities have the same name).

You can create the IAM service account identity with the command:

gcloud iam service-accounts create ${GSA_NAME} -- project=${GSA_PROJECT}

After you create the IAM service account, you need to bind it to an IAM policy (based on the GCP RBAC paradigm) in order to grant it permissions that the K8s service account will then be able to use to access GCP resources.

Step 3 - Allow the K8s Service Account to Impersonate the IAM Service Account

Use this variable:


Create the IAM policy binding between the K8s service account and the IAM service account:

gcloud iam service-accounts add-iam-policy-binding  ${GSA_NAME}@${GSA_PROJECT} --role  roles/iam.workloadIdentityUser --member "serviceAccount:${PROJECT_ID}[${NAMESPACE}/${KSA_NAME}] "

Step 4 - Annotate the K8s Service Account

You can annotate the K8s service account via the CLI:

kubectl annotate serviceaccount ${KSA_NAME} --namespace  $NAMESPACE}${GSA_NAME}@${GSA_PROJECT}

Note: You can also annotate the K8s service account via (test) yaml:


apiVersion: v1

kind: ServiceAccount


name: web-app-service-account



Step 5 - Configure Deployments/Pods

On top of making sure your deployments/pods use the federated GCP service account you  will need to make sure they are running on nodes that use workload identity (with the nodeSelector field).

Both configurations are done under the "spec" section of either the pod manifest (if you define pods) or the "template" object of the deployment manifest (if you define deployments):


serviceAccountName: <K8S_SERVICE_ACCOUNT_NAME>

nodeSelector: "true"

And that's that! You can now make calls to the GCP environment and use the IAM permissions for which IAM bindings exist for the IAM service account you federated with! Federating K8s workloads has never been easier and makes managing permissions more efficient and secure.


Join us at KubeCon + CloudNativeCon North America this November 6 - 9 in Chicago for more on Kubernetes and the cloud native ecosystem. 



Lior Zatlavi, Sr. Cloud Security Architect - Tenable


Lior has over 15 years of experience in cyber security, with most of that time as a security architect, product manager, and developer for the Israeli government. Lior served in an elite cyber security unit of the Israel Defense Forces (retired with the rank of Major), after which he worked in a cyber security division of Israel's Prime Minister's Office. After leaving the public sector, Lior worked as an independent consultant, specializing in cloud security and identity management.

Lior holds an M.Sc in Electrical Engineering from Tel Aviv University and a B.Sc in Applied Mathematics (cum laude) from Bar Ilan University, Israel.

Published Friday, October 20, 2023 6:57 AM by David Marshall
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
<October 2023>