> ## Documentation Index > Fetch the complete documentation index at: https://docs.resolve.ai/llms.txt > Use this file to discover all available pages before exploring further. # GCP Connect from ResolveAI to Google Cloud to give the agent access to logs, metrics, alerts, and dashboards to be used in investigations. ResolveAI supports three authentication methods for GCP. Pick a tab below and follow it end-to-end. ## Service Account (SA) Key Paste a GCP Service Account (SA) private key JSON into ResolveAI. Simplest to set up. **Prerequisites:** permissions in Google Cloud to create a service account, and permissions in ResolveAI to create an integration. *** ### In Google Cloud #### 1. Create a service account Open the Service Account page: [https://console.cloud.google.com/iam-admin/serviceaccounts/create](https://console.cloud.google.com/iam-admin/serviceaccounts/create)
#### 2. Grant roles Add `roles/logging.viewer` on the projects, folders, or organizations whose logs you want to expose — a single folder- or org-level grant covers all child projects. For metrics, alerts, and dashboards, also add `roles/monitoring.viewer` on the service account's project.
#### 3. Create a private key Choose type **JSON**, and copy it — you'll paste it into ResolveAI below. *** ### In ResolveAI #### 4. Add a GCP connection Open [Integrations](https://app0.resolve.ai/integrations) for your organization, click [**GCP**](https://app0.resolve.ai/integrations/gcp/connect), then **Add Connection** at the top right. Give the integration a name (ex. `GCP Prod`) and list its environments (ex. `production` and `staging`).
#### 5. Add Resource Names These are the log containers to search: `projects/PROJECT_ID`, `folders/FOLDER_ID`, `organizations/ORG_ID`, or a specific log bucket view. A single folder/org entry covers every log project underneath it, including projects created later (log search only — metrics, alerts, and dashboards use the connection's single Project ID).
#### 6. Authenticate and save Under **Authentication**, choose **Service Account Key** and paste the whole private key JSON from step 3 into the *Service Account Key JSON* field. Click **Save**, then verify the connection with **Check Health**. ## Workload Identity Federation (AWS → GCP) ResolveAI's workload (running on AWS) authenticates to your GCP project directly using its AWS identity, so no long-lived private key is stored — nothing is on the ResolveAI side except the federation config JSON and your project ID. Recommended if your security posture discourages static service account keys. **Prerequisites:** permissions in Google Cloud to create a Workload Identity Pool, and permissions in ResolveAI to create an integration. *** ### In Google Cloud #### 1. Create a Workload Identity Pool Open **IAM & Admin → Workload Identity Federation** ([https://console.cloud.google.com/iam-admin/workload-identity-pools](https://console.cloud.google.com/iam-admin/workload-identity-pools)) and create a pool, or reuse an existing one.
#### 2. Add an AWS provider to the pool Contact ResolveAI support to get the specific AWS account ID and IAM role ARN that the provider should trust — that's the identity ResolveAI's workload uses to authenticate.
#### 3. Create the service account ResolveAI will impersonate Or choose an existing one. Grant it `roles/logging.viewer` on the projects, folders, or organizations whose logs you want to expose — a single folder- or org-level grant covers all child projects. For metrics, alerts, and dashboards, also grant `roles/monitoring.viewer` on your Project ID's project.
#### 4. Allow impersonation Grant the Workload Identity Pool principal the `roles/iam.workloadIdentityUser` role on that service account, so the federated AWS identity is allowed to impersonate it.
#### 5. Download the federation config From the pool's provider page, click **Download config** to get the federation credential JSON (it will have `"type": "external_account"`). Note your **GCP Project ID** as well — you'll need both below. *** ### In ResolveAI #### 6. Add a GCP connection Open [Integrations](https://app0.resolve.ai/integrations) for your organization, click [**GCP**](https://app0.resolve.ai/integrations/gcp/connect), then **Add Connection** at the top right. Give the integration a name (ex. `GCP Prod`) and list its environments (ex. `production` and `staging`).
#### 7. Add Resource Names These are the log containers to search: `projects/PROJECT_ID`, `folders/FOLDER_ID`, `organizations/ORG_ID`, or a specific log bucket view. A single folder/org entry covers every log project underneath it, including projects created later (log search only — metrics, alerts, and dashboards use the connection's single Project ID).
#### 8. Authenticate and save Under **Authentication**, choose **Workload Identity Federation**: paste the federation config JSON from step 5 into the *Workload Identity Config JSON* field, and enter your **Project ID**. Click **Save**, then verify the connection with **Check Health**. ## Workload Identity Federation (Satellite Kubernetes Service Account) The [Resolve Satellite](/resolve-satellite) pod mints GCP tokens inside your Kubernetes cluster, authenticating as its own Kubernetes Service Account (KSA) via [Workload Identity Federation with Kubernetes](https://cloud.google.com/iam/docs/workload-identity-federation-with-kubernetes). * No GCP service account key exists anywhere, no external identity is trusted in your GCP org, and no secret material ever leaves your cluster. * Works with GKE (issuer URLs are publicly reachable, including for private clusters) and any other cluster whose OIDC issuer GCP can reach. * Recommended if your security posture disallows both service account keys and federating third-party identities into your Workload Identity Pool. * Only the credential-config-file method described below is supported; GKE metadata-server auto-discovery (plain ADC with no config JSON) is not. **Prerequisites:** permissions in Google Cloud to create a Workload Identity Pool, plus a running Resolve Satellite in a Kubernetes cluster and access to its Helm values. *** ### In your Kubernetes cluster #### 1. Find the satellite's KSA name and namespace By default the Helm chart creates a service account named after the release: ```shell theme={null} kubectl get statefulset -n SATELLITE_NAMESPACE -l app.kubernetes.io/name=satellite \ -o jsonpath='{.items[0].spec.template.spec.serviceAccountName}' ```
#### 2. Get the cluster's OIDC issuer URL ```shell theme={null} kubectl get --raw /.well-known/openid-configuration | jq -r .issuer ``` *** ### In Google Cloud #### 3. Create a Workload Identity Pool and an OIDC provider for the cluster The pool lives in your active gcloud project; that project's number is `PROJECT_NUMBER` in the steps below. ```shell theme={null} gcloud iam workload-identity-pools create resolve-satellite-pool --location=global gcloud iam workload-identity-pools providers create-oidc resolve-satellite-provider \ --location=global \ --workload-identity-pool=resolve-satellite-pool \ --issuer-uri=ISSUER_URL_FROM_STEP_2 \ --attribute-mapping="google.subject=assertion.sub" ```
#### 4. Grant the satellite's federated principal a role Grant `roles/logging.viewer` on the projects, folders, or organizations whose logs you want to expose. A single folder- or org-level grant covers all child projects, including projects created later. For metrics, alerts, and dashboards, also grant `roles/monitoring.viewer` on the project you'll set as `projectId` in step 7. The principal is: ```text theme={null} principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/resolve-satellite-pool/subject/system:serviceaccount:SATELLITE_NAMESPACE:SATELLITE_KSA_NAME ``` For example, for a folder-level grant: ```shell theme={null} gcloud resource-manager folders add-iam-policy-binding YOUR_FOLDER_ID \ --role=roles/logging.viewer \ --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/resolve-satellite-pool/subject/system:serviceaccount:SATELLITE_NAMESPACE:SATELLITE_KSA_NAME" ``` (Alternative: grant the role to a GCP service account instead, and add `--service-account=THAT_GSA_EMAIL` in step 5 so the federated identity impersonates it.)
#### 5. Generate the credential config JSON `--credential-source-file` must match the token path you'll mount in step 6: ```shell theme={null} gcloud iam workload-identity-pools create-cred-config \ projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/resolve-satellite-pool/providers/resolve-satellite-provider \ --credential-source-file=/var/run/secrets/resolve-gcp-wif/token \ --credential-source-type=text \ --output-file=credential-config.json ``` *** ### In your satellite Helm values #### 6. Mount a projected KSA token into the satellite pod with top-level `volumes` and `volumeMounts` The token `audience` must be the full resource name of the provider from step 3, prefixed with `https://iam.googleapis.com/`: ```yaml theme={null} volumes: - name: gcp-wif-token projected: sources: - serviceAccountToken: path: token expirationSeconds: 3600 audience: https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/resolve-satellite-pool/providers/resolve-satellite-provider volumeMounts: - name: gcp-wif-token mountPath: /var/run/secrets/resolve-gcp-wif readOnly: true ```
#### 7. Add the integration Embed the contents of `credential-config.json` from step 5 in an `integrations` block. Unlike a service account key, this file contains **no secret material** (only pool/provider identifiers and the token file path), so it is safe to place in Helm values: ```yaml theme={null} integrations: gcp: type: gcp create: true connection: projectId: YOUR_PROJECT_ID # project used for metrics, alerts, and dashboards API calls resourceNames: # log containers to search. A folder/org entry covers every log project underneath it (log search only) - folders/YOUR_FOLDER_ID # or projects/..., organizations/... # Contents of credential-config.json from step 5. # Contains no secret material. Must be a string — keep the | block scalar. workloadIdentityConfigJson: | { "type": "external_account", "audience": "//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/resolve-satellite-pool/providers/resolve-satellite-provider", "subject_token_type": "urn:ietf:params:oauth:token-type:jwt", "token_url": "https://sts.googleapis.com/v1/token", "credential_source": { "file": "/var/run/secrets/resolve-gcp-wif/token" } } ``` `workloadIdentityConfigJson` must reach the satellite **as a string** — use the `|` block scalar exactly as shown. Do not deliver it as a raw JSON file inside a Kubernetes Secret: the satellite parses mounted secret files as YAML, a bare JSON file becomes an object instead of a string, and GCP authentication is silently skipped (all calls fail with 401).
#### 8. Deploy and verify The changes from Steps 6 and 7 go in the same values file — apply them together with a single `helm upgrade`. The connection appears in the ResolveAI Integrations list automatically once the satellite registers it; verify it with **Check Health** on the GCP integration page.