How to authenticate to Google Cloud integrations using Workload Identity

[ylandovskyy]

If you are not familiar with workload identity federation, please check out this doc page. Eventually, it’s the best practice, when doing authentication to Google Cloud API as it removes the risk, where the SA keys can get leaked and cause troubles.

Overview

Google Cloud API integration configuration that has Workload Identity Authentication

All of Google Cloud integrations will feature 2 types of authentications:

• Workload Identity
• Service Account Key

Inside the configuration you will see a parameter called “Workload Identity Email”, which is standartised across Marketplace. This parameter is responsible for the Workload Identity authentication.

In order to authenticate, you just need to perform 3 steps:

• Create a principal that is going to be used for impersonation
• Grant the python pod SA “Service Account Token Creator” Role
• Use the created principal inside integration configuration

Step 1. Creating the principal

The first step is to create a principal that will have all of the permissions that you need to execute the Google Cloud API requests. For example, if you were leveraging previously the SA keys, then SA itself is the principal that we are going to use for impersonation.

For the sake of simplicity let’s assume — workload-service@example.iam.serviceaccount.com is our principal.

Depending, if you want to access the whole Google Cloud Organisation or just a Project, this SA will need to have the respective permissions at the org or project level.

Step 2. Python Pod Nuances

All of the integration scripts in Google SecOps are executed in the dedicated python pod. If this pod doesn’t have permissions to do the impersonation, then workload identity is not possible.

For example, if you are going to put the principal right now into the “Workload Identity Email” parameter in any Google Cloud integration and do a test run, you will see an error that looks like this:

Error caused by the fact that python pod SA doesn’t have necessary Role

“Impersonation is not allowed for the provided service account workload-service@example.iam.serviceaccount.com. Please add the “Service Account Token Creator” role to the service account: gke-****@soar-playground.iam.gserviceaccount.com Execution State: ExecutionState.FAILED — Failed”

Using this error you can discover what is the name of the SA for python pod. In my example, it’s gke-****@soar-playground.iam.gserviceaccount.com.

Now that you know the python pod SA, you need to grant it the “Service Account Token Creator” Role in the project of your Google Cloud org.

Step 3. Validating Configuration

At this stage, if everything is configured correctly, you expect to see the green checkmark. Eventually, this is how it should look like:

If you see any additional errors, pay attention to the message. It will be most likely tied to the missing permissions.

[sangaviv]

Hi @ylandovskyy , Thanks for the detailed solution. I am ending up with the same error for the impersonation. What is this gke-****@soar-playground.iam.gserviceaccount.com? and where can I find this python pod SA. It doesn't exist in my org or project in GCP. 

[ylandovskyy]

Hey @sangaviv ,

The gke-****@soar-playground.iam.gserviceaccount.com is the python pod SA. So, it means that you need to add Role to it within your Google Cloud org. Like in the screenshot below. After that you will be able to perform impersonation with the SA that you want to use inside your integrations.

Let me know, if it makes sense

[sangaviv]

Yes, that worked. Thanks a lot Yuriy!