docs: enhance GCP integration documentation + add gcp wip ( workload identity )

[girish-cheedala]

• Revise GCP integration overview for clarity on discovery approaches and authentication methods.
• Introduce a detailed table of supported GCP services.
• Expand on enumeration scope with project-level and organization-level discovery options.
• Add warnings regarding permission requirements for organization-level enumeration.
• Include new authentication methods with descriptions and links.
• Add a new image for GCP integration screen.

[neo-by-projectdiscovery-dev]

Neo Security Audit

High: 1

Highlights

• All Organization ID examples use consistent placeholder values (123456789012) - no real credentials exposed
• Permission warnings preserved and enhanced with reference links to authentication methods

High (1)

• Overly permissive Workload Identity Federation binding — cloud/integrations.mdx:1221
  The WIF configuration grants workloadIdentityUser role to a wildcard principal (projectdiscovery-pool/*) without attribute conditions. This allows any token issued by oidc.projectdiscovery.io to impersonate the service account.

Attack Examples

Overly permissive Workload Identity Federation binding (cloud/integrations.mdx:1221):

Customer A follows this guide and creates service account SA-A with org-level viewer permissions. If ProjectDiscovery's OIDC provider issues tokens to Customer B from the same pool, Customer B's token could impersonate SA-A and enumerate Customer A's entire GCP organization.

Suggested Fixes

Overly permissive Workload Identity Federation binding (cloud/integrations.mdx:1221):

Add an attribute condition to restrict which tokens can impersonate the service account. Example:

gcloud iam service-accounts add-iam-policy-binding \
  pd-cloudlist-reader@YOUR_PROJECT_ID.iam.gserviceaccount.com \
  --role="roles/iam.workloadIdentityUser" \
  --member="principalSet://iam.googleapis.com/projects/YOUR_PROJECT_NUMBER/locations/global/workloadIdentityPools/projectdiscovery-pool/attribute.customer_id/YOUR_CUSTOMER_ID"

Or use --attribute-condition to enforce token claims that uniquely identify the customer.

Hardening Notes

• All Organization ID examples use consistent placeholder values (123456789012) - no real credentials exposed
• Permission warnings preserved and enhanced with reference links to authentication methods
• Security guidance remains accessible within collapsible Accordion components
• No introduction of injection vulnerabilities, authentication bypasses, or information disclosure risks

_{Comment @neo help for available commands. · Open in Neo}

[neo-by-projectdiscovery-dev]

🟠 Overly permissive Workload Identity Federation binding (CWE-863) — The WIF configuration grants workloadIdentityUser role to a wildcard principal (projectdiscovery-pool/*) without attribute conditions. This allows any token issued by oidc.projectdiscovery.io to impersonate the service account.

Attack Example

Customer A follows this guide and creates service account SA-A with org-level viewer permissions. If ProjectDiscovery's OIDC provider issues tokens to Customer B from the same pool, Customer B's token could impersonate SA-A and enumerate Customer A's entire GCP organization.

Suggested Fix

Add an attribute condition to restrict which tokens can impersonate the service account. Example:

gcloud iam service-accounts add-iam-policy-binding \
  pd-cloudlist-reader@YOUR_PROJECT_ID.iam.gserviceaccount.com \
  --role="roles/iam.workloadIdentityUser" \
  --member="principalSet://iam.googleapis.com/projects/YOUR_PROJECT_NUMBER/locations/global/workloadIdentityPools/projectdiscovery-pool/attribute.customer_id/YOUR_CUSTOMER_ID"

Or use --attribute-condition to enforce token claims that uniquely identify the customer.