feat(gcp): Added Support of GCP Role Impersonation

[AyushAggarwal1]

No description provided.

[CLAassistant]

All committers have signed the CLA.

[AyushAggarwal1]

Hi @alphadev4 / @tzurielweisberg
Can I get a review on this?

[mihaivaduva21]

@fatimaaqua @alphadev4 @tzurielweisberg @rfletcher @mwarkentin — 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.