GCP

connect from resolve ai to google cloud to give the agent access to logs, metrics, alerts, and dashboards to be used in investigations resolve ai 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 resolve ai simplest to set up prerequisites permissions in google cloud to create a service account, and permissions in resolve ai 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 resolve ai below in resolve ai 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) resolve ai'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 resolve ai 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 resolve ai 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 resolve ai support to get the specific aws account id and iam role arn that the provider should trust — that's the identity resolve ai's workload uses to authenticate 3 create the service account resolve ai 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 resolve ai 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 https //docs resolve ai/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 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 resolve ai integrations list automatically once the satellite registers it; verify it with check health on the gcp integration page