GCP

Trace connects to Google Cloud through a service account provisioned in Trace's own GCP organization, dedicated to your organization. You grant that service account a read-only role set at the scope you choose — your whole organization, one folder, or a single project. Authentication is keyless (Workload Identity Federation): no service-account keys are ever created, stored, or exchanged. Trace never modifies your resources — the only change in your environment is the IAM role and bindings you create yourself when applying the grant.

How it works

1. From Settings → Integrations → GCP in the dashboard, choose the scope, enter its ID, and connect. Trace provisions your dedicated service account and shows you its email.
2. Apply the generated grant with Terraform, the gcloud CLI, or Cloud Shell. It creates a Trace-defined custom role that enumerates exact read-only permissions and binds it, together with roles/cloudasset.viewer, to your dedicated service account. Applying it requires an account that can create custom IAM roles (an Owner, or Role Administrator). For organization and folder grants the custom role is defined at the organization level, so it needs Organization Role Administrator; a project grant needs it on the project. If your organization enforces domain-restricted sharing you'll also need roles/orgpolicy.policyAdmin, which is often a different person: see below.
3. Click Verify access. Trace checks that the granted permissions are sufficient, warns if the grant is broader than Trace needs, then activates the integration.

If your grant is rejected: domain-restricted sharing

If applying the grant fails with do not belong to a permitted customer, your organization enforces the org policy constraints/iam.allowedPolicyMemberDomains. It only lets you grant roles to identities on an allowlist, and your Trace service account lives in Trace's own Google Cloud organization, so it isn't on yours yet. Google enforces this policy by default on every organization created on or after May 3, 2024, with your own domain as the only allowed value, so most organizations hit this.

Add Trace's Cloud Identity customer ID, C03q9l5oc, to the allowlist:

gcloud resource-manager org-policies allow iam.allowedPolicyMemberDomains \
  "C03q9l5oc" --organization="YOUR_ORG_ID"

org-policies allow appends to the allowlist rather than replacing it, so nothing you already permit is lost. The constraint ID goes in bare: this command rejects the constraints/ prefix that describe and set-policy accept. Running it needs roles/orgpolicy.policyAdmin, which is often held by someone other than the person applying the grant.

Org policy changes take up to 15 minutes to take effect. Wait, then apply the grant again. Both the gcloud script and the Terraform config are safe to re-run.

Narrowing it further

The customer ID admits every identity in Trace's Cloud Identity account. Two ways to grant less, both of which you drive:

• Scope the exception. Instead of amending the organization-wide policy, set the same exception on only the project or folder you're granting Trace, with inheritFromParent enabled so the rest of your allowlist still applies. Trace's identities then become bindable only inside the scope you granted. Google documents the hierarchy semantics under restricting identities by domain.
• Allowlist the one service account. If your organization uses the newer iam.managed.allowedPolicyMembers constraint rather than the legacy one, its allowedMemberSubjects parameter takes individual principals, so you can permit exactly the service account Trace provisioned for you and no other identity.

What Trace sees

The role set is metadata-only: list and describe resources, read IAM policies, and query Cloud Asset Inventory. Data-plane reads are excluded by design — Cloud Storage object contents, Secret Manager values, BigQuery table data, and monitoring data are not readable. Every permission in the custom role is enumerated in the onboarding artifacts, so you can audit the exact set before applying it.

Why connect GCP

Source code alone can't tell you what's actually reachable in your live environment. During a penetration test, Trace uses read-only recon of your real GCP footprint — what's deployed, what's public, how services connect — to confirm whether a weakness is genuinely reachable and exploitable, rather than only theoretically vulnerable. Credentials are minted per session, stay read-only, and expire automatically.

Disconnecting immediately revokes Trace's access and deletes your dedicated service account, invalidating every grant that references it (if the deletion is delayed, the integration page offers a retry). You can also remove the role bindings on your side at any time.