GCP ServiceAccount chaining for Cloud Connectors

[amirbenun]

Two-Hop Chain

OIDC Token -> Elastic Global SA -> Customer Target SA -> Resources

Hop 1: OIDC to Global SA

Purpose: Authenticate Elastic infrastructure

• OIDC token from file exchanges with GCP Workload Identity Federation
• Returns credentials for Elastic's Global Service Account
• Configured by Elastic (env vars: pool, provider, project number)

Hop 2: Global SA to Target SA

Purpose: Access customer resources

• Elastic Global SA impersonates customer Target SA
• Uses IAM Credentials API with serviceAccountTokenCreator role
• Configured by customer (IAM binding + SA email in policy)

Why Two Hops?

Security

• Elastic Global SA has zero permissions on customer resources
• Each hop creates audit logs
• Only short-lived tokens (1hr), no keys

Multi-Tenancy

• One Elastic Global SA serves many customers
• Each customer has isolated Target SA

Screenshot/Data

Related Issues

Checklist

• I have added tests that prove my fix is effective or that my feature works
• I have added the necessary README/documentation (if appropriate)

Introducing a new rule?

• Generate rule metadata using this script
• Add relevant unit tests
• Generate relevant rule templates using this script, and open a PR in elastic/packages/cloud_security_posture

[mergify]

This pull request does not have a backport label. Could you fix it @amirbenun? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v./d./d./d is the label to automatically backport to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.