Google Workspace: keyless authentication through Application Default Credentials and Service Account impersonation

Feature search

• I have searched the existing issues and this feature has not been requested yet or is already in our Public Roadmap

Which component would this feature affect?

Prowler SDK / CLI

Related to specific cloud provider?

Google Workspace

New feature motivation

The Google Workspace provider can only authenticate with a downloaded Service Account JSON key (GOOGLEWORKSPACE_CREDENTIALS_FILE / GOOGLEWORKSPACE_CREDENTIALS_CONTENT). Organizations that enforce the iam.disableServiceAccountKeyCreation organization policy — Google's default for organizations created since 2024 — cannot create that key at all, and CI systems that already authenticate keyless through Workload Identity Federation end up storing a long-lived, super-admin-scoped secret just for this provider.

Nothing in Domain-Wide Delegation requires a local private key: google-auth (already pinned at 2.52.0 in Prowler) supports impersonated_credentials.Credentials(..., subject=<user>), which asks the IAM Service Account Credentials API to sign the delegation assertion (iam.serviceAccounts.signJwt) and exchanges it for the delegated user's access token. That is the path google-auth's maintainers pointed to when keyless delegation was requested in googleapis/google-auth-library-python#1785 (closed July 2025 as already supported; that repository has since been archived and the library now lives in googleapis/google-cloud-python/packages/google-auth, where the subject support is unchanged). The GCP provider already exposes --impersonate-service-account for the analogous keyless flow.

Solution Proposed

Add a third credential source to GoogleworkspaceProvider, tried after the key file/content:

• --impersonate-service-account <sa-email> on the CLI (parity with prowler gcp) and GOOGLEWORKSPACE_IMPERSONATE_SERVICE_ACCOUNT as the environment variable, plus impersonate_service_account= on the provider constructor and test_connection.
• Source = google.auth.default(); credentials = impersonated_credentials.Credentials(source, target_principal=<sa>, target_scopes=SCOPES, subject=<delegated user>). The Admin Console Domain-Wide Delegation setup is unchanged (same client id, same six scopes); only the JSON key step disappears.
• Key material keeps precedence when both are configured; a missing ADC raises a dedicated GoogleWorkspaceADCError; the existing 403 hint mentions roles/iam.serviceAccountTokenCreator when impersonating.
• Docs: a "Keyless Authentication with Service Account Impersonation" section with prerequisites (ADC, roles/iam.serviceAccountTokenCreator on the SA — granted to the SA itself when ADC already is the SA via WIF — and the IAM Service Account Credentials API) and a GitHub Actions / google-github-actions/auth example.

Use case and benefits

• Scheduled Google Workspace scans from GitHub Actions authenticate through Workload Identity Federation only: no Service Account key to create, store as a CI secret, rotate, or leak.
• Organizations under iam.disableServiceAccountKeyCreation can onboard the provider without a policy exception.
• Local runs work with gcloud auth application-default login plus roles/iam.serviceAccountTokenCreator on the Service Account — the same operator model the GCP provider already uses.

Describe alternatives you've considered

• Keep using a JSON key with a project-scoped exception to the org policy: works, but re-introduces a long-lived, super-admin-scoped secret that has to be rotated and stored in CI.
• Have the provider accept GOOGLE_APPLICATION_CREDENTIALS directly without impersonation: not possible — Domain-Wide Delegation needs an assertion signed as the Service Account, which ADC alone cannot produce; impersonation with subject is the documented google-auth path.

Additional context

I have the change ready (provider, CLI flag, tests, docs, changelog fragment) and will open a PR against master referencing this issue.