Google Chronicle API Isssue

1. The "Identity Mismatch" (The most common cause)

You likely granted the Service Account Token Creator role to your own user or to the "Workload Identity Email" itself. This is incorrect.

In the Chronicle/SecOps ecosystem, the "impersonator" is actually a Google-managed service account that runs the integration engine (the "Python Pod"). You must grant the role to that specific system account so it has permission to "act as" your service account.

• How to find the correct ID:

  1. Go to Chronicle SecOps > Settings > Integrations.

  2. Attempt to "Test" your Google Chronicle integration.

  3. Look closely at the error logs. It will likely say: "Please add the 'Service Account Token Creator' role to the service account: gke-init-python@soar-xxxx.iam.gserviceaccount.com"

• The Fix:

  • In the GCP Console, go to IAM & Admin > Service Accounts.

  • Select your "Workload Identity" Service Account.

  • Click the Permissions tab.

  • Grant the Service Account Token Creator role to the gke-init-python... account you found in the error.

2. Domain Restricted Sharing Policy

If your organization has the Domain Restricted Sharing policy enabled, it blocks any identity outside your Workspace domain from being added to IAM roles.

Because the gke-init-python@soar-... account lives in a Google-owned domain (not yours), your project will block you from even adding it to the IAM list, or it will ignore the binding if it was forced.

• The Fix:

  1. Go to IAM & Admin > Organization Policies.

  2. Find the policy "Domain restricted sharing".

  3. Edit the policy and add an exception for the Google SecOps Customer ID: C03h2sojs.

  4. Save and wait about 5-10 minutes for the policy to propagate.

3. Missing Service Account Credentials API

Impersonation requires a specific backend API to generate short-lived tokens. If this isn't enabled in the project where your service account resides, the request will fail regardless of permissions.

• The Fix: Ensure the Service Account Credentials API (iamcredentials.googleapis.com) is Enabled in your Google Cloud project.

Is the customer id different for service accounts that look like:
 

soar-python@yyyyyyyyyyy-tp.iam.gserviceaccount.com
 

C03h2sojs as an exception didn’t let me add the above service account as a principal with access (but works fine when totally disabling the org policy).

I dont think it matters. I’d have to understand a little further on your use case.  

I think there may be a parameter in your org policy to allow what you need not jsut turnign it off. 

Sorry, here’s some quick context — just trying to avoid using JSON SA creds. Not having the issue that the OP had, but your thorough response prompted me to respond here.

So I noticed this in a customer’s GCP environment and recreated it in our internal one.

I’ve overwritten "Domain restricted sharing" to allow C03h2sojs

But when I add our SecOps “soar-python@…” service account as a principal with access we get “IAM policy update failed: One or more users named in the policy do not belong to a permitted customer.”

Disabling the policy at our project level will allow us to add “soar-python@…” as the principal. So this confirms "Domain restricted sharing" is what causes the above message.

So I tested the exact same org policy against a known external Workspace. Before doing anything, adding an external account produces the same error, but after adding their external Workspace ID as an exception in the same exact way as I tried with C03h2sojs, it works as expected / without error.

To me this points towards C03h2sojs not being accurate as the most logical explanation. But curious if you have any other ideas!

I’m wondering if the old “gke-init-python@…” addresses belonged to C03h2sojs, but not the new ones.

Yes JSON creds are old and cumbersome at this point.  Here’s what you need.   

The Architectural Shift

Google SecOps recently underwent a massive backend migration for its SOAR execution environments. They moved from a legacy shared-pool architecture to dedicated "Tenant Projects" (which is what the -tp stands for in your new service account string).

• The Old Architecture: Used the gke-init-python@soar-[UNIQUE_ID].iam.gserviceaccount.com service accounts. Those accounts lived in a specific Google-managed organization bound to the C03h2sojs Customer ID.

• The New Architecture: Uses the soar-python@[TENANT_ID]-tp.iam.gserviceaccount.com service accounts. These are spun up in entirely different, newly provisioned Google-managed organizations to improve backend isolation and security.

Because the new soar-python accounts do not reside in the legacy organization, your Domain Restricted Sharing policy rightly looks at the C03h2sojs exception, sees that the new SA belongs to a different external Workspace, and blocks it.

How to Fix It

Because Google provisions these new tenant projects dynamically under the new architecture, there isn't a single, universal "new" Customer ID string published in the standard public documentation yet.

Here is how you get the new exception string for your policy:

1. Check Migration Comms: When your environment was migrated to the new -tp architecture, Google sent an automated email detailing the new service account requirements. The associated Customer ID may be listed in those transition documents.

2. Ping Google Support / Your CE: Open a quick ticket or message your Customer Engineer. Tell them: "We are on the new soar-python@-tp architecture, and GCP Domain Restricted Sharing is blocking Workload Identity Federation. What is the specific Workspace Customer ID for our SOAR tenant project so we can add it as a policy exception?"

Thank you! That makes a lot of sense.

I’m having trouble finding an email with this information (it may have gone to one of my colleagues). Do you happen to know what the email subject would be exactly?