feat(cloud): add GCP WIF credential support for OpenShift

[maxcao13]

AI Summary:

Introduce a cloud credential provider framework that creates and manages GCP WIF secrets. The operator builds the external_account credential JSON, creates the Secret via CreateOrUpdate with owner references, and wires volumes/mounts/env vars into the keda-operator Deployment.

• New cloud package with provider interface and GCP WIF implementation
• Platform-agnostic enablement gated on env vars, with Infrastructure CR fallback for project ID on OpenShift
• Transform helpers for injecting volumes, mounts, and env vars
• Unit and envtest integration tests covering both Subscription-patch and console-install env var configurations, plus negative cases
• RBAC updates for Secret management

Made-with: Cursor

My summary:

Allows the keda-olm-operator to be enabled with gcp wif integration for Red Hat OpenShift (currently not supported for general case Kubernetes with OLM). I tried to keep the code structure as generic for identity provider workflows, in the case we need to support Azure or AWS in the future.

A [user story]/[testing workflow] is as follows:

User wants to scale their pods on OCP with KEDA OLM Operator based on their managed Prometheus instance in their GCP project: e.g. https://keda.sh/docs/2.19/scalers/prometheus/#google-managed-service-for-prometheus

1. User installs openshift cluster on GCP using the OCP installer with Manual credential mode to enable GCP WIF
2. User creates a GCP IAM service account with proper permissions to retrieve metrics for the the Prometheus Scaler and assigns the monitoring role as detailed docs above: https://keda.sh/docs/2.19/scalers/prometheus/#google-managed-service-for-prometheus
3. User installs the keda-olm-operator through OperatorHub, and fills in the console parameters accordingly (GCP project number, pool ID, SA email, provider id) (they can also edit their Subscription object without the console path with AUDIENCE + SERVICE_ACCOUNT_EMAIL):

4. The parameters get translated as environment variables passed to the olm operator pod, and the olm operator code then builds an external_account json embedded secret with the WIF audience URI, STS token URL, SA impersonation URL, and the path to the projected token file.
5. We also pass in CLOUDSDK_CORE_PROJECT if it's set from the Subscription object to pass to the keda-operator. The keda-operator code uses this environment variable as the default GCP project ID to use when calling SDK code. If the env var is not set, it falls back to checking the project ID on the infrastructure object (only on OpenShift).
6. The olm operator then mounts the secret into the keda-operator pod, and passes in GOOGLE_APPLICATION_CREDENTIALS pointing to that mounted credential so that the keda-operator can now obtain a short-term access token from the STS token url to impersonate the authorized service account from earlier. keda-operator can now query your GCP project for anything it needs now (and can access, in this case, it's the managed prometheus instance in GCP which only needs the monitoring.viewer role) that it has the temporary access token.

Checklist

• Commits are signed with Developer Certificate of Origin (DCO)