GCP - ResolveAI

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.

Option 1: SA Key
Option 2: WIF (AWS)
Option 3: WIF (Satellite KSA)

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

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 for your organization, click GCP, 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) 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

7. Add Resource Names

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 pod mints GCP tokens inside your Kubernetes cluster, authenticating as its own Kubernetes Service Account (KSA) via 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:

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

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.

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:

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:

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:

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/:

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:

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.

​Service Account (SA) Key

​In Google Cloud

​1. Create a service account

​2. Grant roles

​3. Create a private key

​In ResolveAI

​4. Add a GCP connection

​5. Add Resource Names

​6. Authenticate and save

​Workload Identity Federation (AWS → GCP)

​In Google Cloud

​1. Create a Workload Identity Pool

​2. Add an AWS provider to the pool

​3. Create the service account ResolveAI will impersonate

​4. Allow impersonation

​5. Download the federation config

​In ResolveAI

​6. Add a GCP connection

​7. Add Resource Names

​8. Authenticate and save

​Workload Identity Federation (Satellite Kubernetes Service Account)

​In your Kubernetes cluster

​1. Find the satellite’s KSA name and namespace

​2. Get the cluster’s OIDC issuer URL

​In Google Cloud

​3. Create a Workload Identity Pool and an OIDC provider for the cluster

​4. Grant the satellite’s federated principal a role

​5. Generate the credential config JSON

​In your satellite Helm values

​6. Mount a projected KSA token into the satellite pod with top-level volumes and volumeMounts

​7. Add the integration

​8. Deploy and verify

Service Account (SA) Key

In Google Cloud

1. Create a service account

2. Grant roles

3. Create a private key

In ResolveAI

4. Add a GCP connection

5. Add Resource Names

6. Authenticate and save

Workload Identity Federation (AWS → GCP)

In Google Cloud

1. Create a Workload Identity Pool

2. Add an AWS provider to the pool

3. Create the service account ResolveAI will impersonate

4. Allow impersonation

5. Download the federation config

In ResolveAI

6. Add a GCP connection

7. Add Resource Names

8. Authenticate and save

Workload Identity Federation (Satellite Kubernetes Service Account)

In your Kubernetes cluster

1. Find the satellite’s KSA name and namespace

2. Get the cluster’s OIDC issuer URL

In Google Cloud

3. Create a Workload Identity Pool and an OIDC provider for the cluster

4. Grant the satellite’s federated principal a role

5. Generate the credential config JSON

In your satellite Helm values

6. Mount a projected KSA token into the satellite pod with top-level `volumes` and `volumeMounts`

7. Add the integration

8. Deploy and verify