Connecting your GCP project

Microsoft Entra ID and Azure are the live, proven surface. Google Cloud coverage is in preview and rolls out per environment. The setup below is the path you follow once Google Cloud is enabled for your account: you can prepare the pool and service account now, and verification switches on when Permafrost finishes provisioning federation.

Permafrost reads your IAM principals and role bindings across the Google Cloud resource hierarchy so it can score every principal against the access it actually uses, alongside Microsoft, in one identity attack surface. It reads by impersonating a service account you create — and it reaches that service account through workload identity federation, so no JSON key is ever generated or downloaded.

The setup has three parts: a workload identity pool with an OIDC provider that trusts Permafrost's short-lived token, a read-only service account, and a binding that lets Permafrost's federated identity impersonate that service account. Each request carries a fresh, automatically issued token; your provider validates it before access is granted.

A downloaded service-account key is a long-lived credential: it exists somewhere, it must be protected, and it has to be rotated. Workload identity federation removes the key from the equation. Permafrost holds no credential to your project. The OIDC provider you create restricts the trust to Permafrost's exact token subject, so only Permafrost can federate in — the issuer, audience, and subject come from Permafrost's live token and are shown in the connect wizard.

The service account is granted read-only roles and nothing more. You pick the tightest that satisfies your organization policy.

• Security Reviewer (roles/iam.securityReviewer) — reads IAM policies and role bindings across the resource hierarchy.
• Cloud Asset Viewer (roles/cloudasset.viewer) — reads the Cloud Asset inventory, the resources and their attached IAM.

Both are read-only across IAM and resource policy. No write role is requested, and no data-plane read of object contents or secret values is included. Service-account key material is never read — only key metadata, so Permafrost can flag a key that is old or unused without ever touching the key itself.

The connect wizard generates a copy-ready gcloud script and a Terraform equivalent that create the pool, the OIDC provider, the read-only service account, the impersonation binding, and the role grants in one pass. Run the gcloud script in Cloud Shell, which is already signed in as you, or apply the Terraform if you manage Google Cloud as code. Each outputs the service-account email you paste back into Permafrost.

You finish by pasting the service-account email. Permafrost federates in, impersonates the service account, and runs a single harmless read — cloudresourcemanager.projects.list — to confirm access before the connection activates. The proof is that the read-only impersonation works; there is no key to check, because none was created.