feat(google): accept pre-minted access tokens for service-account impersonation / OIDC

[jorgegmz]

Summary

Adds a pre-minted access-token path to the GCP authentication flow so callers that already hold a valid Google Cloud OAuth2 access token can bypass the JWT-from-private-key exchange and inject the token directly.

Mirrors the existing pattern added for Azure in # (feat(azure): accept pre-minted access tokens for federated identity / OIDC).

Why

There are several legitimate scenarios where a caller has a valid Google Cloud access token but no service-account JSON key:

• Service-account impersonation via iamcredentials.generateAccessToken — the orchestrator holds an executor SA and mints short-lived tokens against target SAs.
• Workload-identity federation — federated identity exchanges return access tokens, never private keys.
• OIDC flows — same as above, no client_secret available.

Today these callers must either embed a long-lived private key (defeating the purpose of impersonation/federation) or fork/vendor patches against CloudSploit.

What changed

• helpers/google/index.js authenticate(): when GoogleConfig.access_token is present, return an OAuth2Client with the token set directly via setCredentials({ access_token }). The returned client exposes the same
  .request() surface that plugins consume — no plugin changes required.
• index.js: new else if branch detecting config.credentials.google.access_token and configuring cloudConfig with { type, project, access_token }. Placed ahead of the existing client_email + private_key branch so the
  pre-minted path takes precedence when a token is supplied. project is still required so plugins can address the correct GCP project.

Test plan

• Existing direct-SA path (client_email + private_key) continues to work unchanged.
• New access_token path authenticates plugin API calls successfully.
• Omitting project produces a clear "missing required key" error.
• credential_file path remains unaffected (it's still evaluated first).

[jorgegmz]

Hi @alphadev4,

Friendly ping for review when time permits. This PR adds support for GCP service-account impersonation, workload identity federation, and OIDC-based authentication by allowing callers to provide a pre-minted Google Cloud access token instead of a service-account private key.

The change is fully backward compatible with the existing authentication paths and requires no plugin changes. I'd appreciate any feedback when you have a chance.

Thank you.

[mihaivaduva21]

@fatimaaqua @alphadev4 @tzurielweisberg — could you please provide some clarity on the status of the short-lived credentials PRs below?

Is there a specific technical, security, or architectural reason these changes have not been merged or incorporated into CloudSploit?

The current CloudSploit authentication model appears to rely primarily on long-lived credentials. For organizations operating in regulated or security-sensitive environments, this creates significant challenges, as long-lived static credentials are generally discouraged in favor of short-lived, federated authentication mechanisms.

In particular, we would like to see support for:

• GCP OAuth2 user credentials
• GCP service account impersonation
• Azure OIDC / federated credentials

There are already several open PRs addressing these areas:

• feat(azure): accept pre-minted access tokens for federated identity /OIDC #2190
• feat(google): accept pre-minted access tokens for service-account impersonation / OIDC #2191
• feat(gcp): Added Support of GCP Role Impersonation #2192
• Adding support for gcp user account #1846

Multiple members of the open-source community have contributed work toward supporting short-lived credentials, but there does not appear to be clear communication from the Aqua team regarding whether these PRs will be reviewed, merged, superseded by another implementation, or declined.

This lack of clarity is creating real integration issues for organizations like ours that want to use CloudSploit within regulated environments where long-lived cloud credentials are not an acceptable authentication pattern.

Could the Aqua team please provide a clear position on these PRs?

Specifically:

1. Are short-lived/federated credentials something Aqua intends to support in CloudSploit?
2. If so, can these existing PRs be reviewed or used as the basis for the implementation?
3. If not, could you please provide the technical or product rationale for not supporting them?
4. If the existing PRs are not acceptable, what changes would be required from contributors to get this functionality merged?

A clear resolution would be greatly appreciated. Even if the decision is not to merge the current implementations, communicating the intended direction would help contributors and users avoid duplicating work and allow us to determine whether CloudSploit can meet our security requirements.