> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Google Cloud

> Connect Rootly AI to selected Google Cloud projects for read-only investigations across logs, metrics, alerts, Cloud Run, and Compute Engine.

## Overview

Connecting Google Cloud gives Rootly AI **read-only access** to operational data in the projects you select. During an investigation, Rootly AI can correlate Cloud Logging entries, Cloud Monitoring metrics and alerts, Cloud Run services, and Compute Engine instances.

The connection uses Google's managed Model Context Protocol (MCP) servers. You can authenticate with Google OAuth or Workload Identity Federation without service-account keys. Rootly never asks you to create or upload a service-account JSON key.

<Note>
  Google Cloud IAM establishes which projects the connected identity is allowed to see. The project multi-select in Rootly is a separate boundary: Rootly AI only queries—and, when AI facts ingestion is enabled, ingests facts from—the projects you explicitly select.
</Note>

<Note>
  This AI connector is separate from the [Google Cloud Monitoring alert source](/integrations/google-cloud-monitoring). The alert source sends monitoring events into Rootly; this connector lets Rootly AI read selected Google Cloud projects during investigations. Configure both when you need both behaviors.
</Note>

***

## Before You Start

For either authentication method, you'll need:

* **Rootly administrator access** to configure AI connectors.
* **MCP Tool User (`roles/mcp.toolUser`)** on each selected project. Google requires this role to call managed MCP tools.
* **Google Cloud IAM permissions** for the data you expect Rootly AI to read. Neither authentication method grants access that the connected identity does not already have.
* **At least one active Google Cloud project** selected during setup.

For Workload Identity Federation setup, you must also be able to enable Google Cloud APIs, create a Workload Identity Pool and provider, create a service account, and manage IAM bindings on the trust, quota, and selected projects. If you do not have those administrative permissions, involve a Google Cloud administrator for the setup steps. The resulting Rootly service account only needs the steady-state read roles described below.

For broad investigation coverage, the connected identity typically needs read access to Cloud Resource Manager, Cloud Asset Inventory, Cloud Logging, Cloud Monitoring, Cloud Run, and Compute Engine. Your organization can grant a narrower set if Rootly AI only needs some of those products. See [Google Cloud MCP access control](https://docs.cloud.google.com/mcp/access-control) for Google's current role requirements.

<Warning>
  For OAuth, prefer a dedicated Google Workspace user with only the required viewer permissions. For durable background ingestion, prefer Workload Identity Federation so the connection does not depend on a person's account.
</Warning>

***

## Choose An Authentication Method

### Google OAuth

OAuth is the quickest setup. A Google user authorizes Rootly, and Rootly stores the encrypted refresh token needed to maintain the connection. Use a dedicated Workspace user rather than a personal responder account.

The user must have the required read roles on every project you plan to select. Removing that user's IAM access or suspending the account also removes Rootly's access.

### Workload Identity Federation

Workload Identity Federation is the durable option without service-account keys. It is analogous to Rootly's AWS cross-account role connection:

`Rootly tenant identity → Google Security Token Service → customer service account → selected projects`

Rootly signs a short-lived OpenID Connect (OIDC) assertion for your Rootly team. Google validates it through a Workload Identity Pool Provider, then issues a short-lived token for a service account that you own. Rootly stores the provider name, encrypted service-account email, and encrypted access token only until that short-lived token expires. Rootly never stores a service-account private key or long-lived Google credential.

<Warning>
  Workload Identity Federation is rolling out with the corresponding Rootly connector update. If the Google Cloud modal does not show this option yet, use Google OAuth or contact Rootly Support. Do not begin the Google Cloud setup below until the option and tenant subject appear in your Rootly account.
</Warning>

<Note>
  This works across Google Cloud organizations. Each customer creates the trust and service account in a project they control. One service account can receive read roles in multiple projects, while Rootly's project selection remains the narrower application-side boundary.
</Note>

#### Configure Google Cloud For Workload Identity Federation

Open the Google Cloud connection modal in Rootly and choose **Workload Identity Federation**. Keep it open: it displays the Rootly OIDC issuer and the exact tenant subject for your Rootly team.

The following example uses a dedicated trust project and the names `rootly-ai` for the pool and `rootly` for the provider. Replace the placeholder values with your own:

```bash theme={null}
export TRUST_PROJECT_ID="your-security-project"
export TRUST_PROJECT_NUMBER="123456789012"
export QUOTA_PROJECT_ID="your-quota-project"
export POOL_ID="rootly-ai"
export PROVIDER_ID="rootly"
export SERVICE_ACCOUNT_ID="rootly-ai-reader"
export ROOTLY_ISSUER="https://your-rootly-issuer.example"
export ROOTLY_SUBJECT="copy-the-exact-subject-from-rootly"
export PROVIDER_RESOURCE="projects/${TRUST_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${POOL_ID}/providers/${PROVIDER_ID}"
export ROOTLY_AUDIENCE="https://iam.googleapis.com/${PROVIDER_RESOURCE}"
export SERVICE_ACCOUNT_EMAIL="${SERVICE_ACCOUNT_ID}@${TRUST_PROJECT_ID}.iam.gserviceaccount.com"
export ROOTLY_PRINCIPAL="principal://iam.googleapis.com/projects/${TRUST_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${POOL_ID}/subject/${ROOTLY_SUBJECT}"
```

<Steps>
  <Step title="Enable Federation APIs">
    Enable the Security Token Service and IAM Service Account Credentials APIs in the trust project.

    ```bash theme={null}
    gcloud services enable sts.googleapis.com iamcredentials.googleapis.com \
      --project="${TRUST_PROJECT_ID}"
    ```
  </Step>

  <Step title="Create The Workload Identity Pool">
    ```bash theme={null}
    gcloud iam workload-identity-pools create "${POOL_ID}" \
      --project="${TRUST_PROJECT_ID}" \
      --location="global" \
      --display-name="Rootly AI"
    ```
  </Step>

  <Step title="Create An OIDC Provider For Your Rootly Team">
    Configure the provider to accept Rootly's issuer and map the required subject. The attribute condition prevents assertions for a different Rootly team from using this provider.

    ```bash theme={null}
    gcloud iam workload-identity-pools providers create-oidc "${PROVIDER_ID}" \
      --project="${TRUST_PROJECT_ID}" \
      --location="global" \
      --workload-identity-pool="${POOL_ID}" \
      --issuer-uri="${ROOTLY_ISSUER}" \
      --allowed-audiences="${ROOTLY_AUDIENCE}" \
      --attribute-mapping="google.subject=assertion.sub" \
      --attribute-condition="assertion.sub == '${ROOTLY_SUBJECT}'"
    ```
  </Step>

  <Step title="Create And Bind The Service Account">
    Create a dedicated service account, then allow only the exact Rootly tenant subject to impersonate it.

    ```bash theme={null}
    gcloud iam service-accounts create "${SERVICE_ACCOUNT_ID}" \
      --project="${TRUST_PROJECT_ID}" \
      --display-name="Rootly AI read-only"

    gcloud iam service-accounts add-iam-policy-binding "${SERVICE_ACCOUNT_EMAIL}" \
      --project="${TRUST_PROJECT_ID}" \
      --role="roles/iam.workloadIdentityUser" \
      --member="${ROOTLY_PRINCIPAL}"
    ```
  </Step>

  <Step title="Grant Read Access To Selected Projects">
    On each project Rootly should investigate, grant the service account `roles/mcp.toolUser` plus only the product-specific viewer roles you need. Rootly uses Cloud Asset Inventory to discover Compute Engine instances for its bounded background fact inventory. A broad example is shown below; narrow it when a project does not use every product.

    ```bash theme={null}
    export SELECTED_PROJECT_ID="your-production-project"

    for ROLE in \
      roles/browser \
      roles/cloudasset.viewer \
      roles/logging.viewer \
      roles/monitoring.viewer \
      roles/run.viewer \
      roles/compute.viewer \
      roles/mcp.toolUser; do
      gcloud projects add-iam-policy-binding "${SELECTED_PROJECT_ID}" \
        --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
        --role="${ROLE}"
    done
    ```
  </Step>

  <Step title="Configure The Quota Project">
    Google uses the quota project for API quota and billing attribution. Enable the APIs that Rootly calls there, then grant Service Usage Consumer to both the federated Rootly principal and the impersonated service account. The first grant covers service-account impersonation; the second covers subsequent MCP calls.

    ```bash theme={null}
    gcloud services enable \
      cloudresourcemanager.googleapis.com \
      iamcredentials.googleapis.com \
      logging.googleapis.com \
      monitoring.googleapis.com \
      run.googleapis.com \
      compute.googleapis.com \
      cloudasset.googleapis.com \
      --project="${QUOTA_PROJECT_ID}"

    gcloud projects add-iam-policy-binding "${QUOTA_PROJECT_ID}" \
      --member="${ROOTLY_PRINCIPAL}" \
      --role="roles/serviceusage.serviceUsageConsumer"

    gcloud projects add-iam-policy-binding "${QUOTA_PROJECT_ID}" \
      --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
      --role="roles/serviceusage.serviceUsageConsumer"
    ```
  </Step>

  <Step title="Finish In Rootly">
    Enter these values in the Rootly modal:

    * **Workload Identity Provider:** the value of `PROVIDER_RESOURCE`, without a leading `//iam.googleapis.com/`
    * **Service Account Email:** the value of `SERVICE_ACCOUNT_EMAIL`
    * **Quota Project ID:** the value of `QUOTA_PROJECT_ID`

    Continue to the project picker and explicitly select the projects Rootly may query.
  </Step>
</Steps>

<Warning>
  Do not create or send Rootly a service-account JSON key. Workload Identity Federation replaces that long-lived private credential with short-lived tokens.
</Warning>

***

## Connecting

<Steps>
  <Step title="Start The Google Cloud Connection">
    Open **AI & Agents → Connectors**, find **Google Cloud**, and click **Connect**.
  </Step>

  <Step title="Choose Authentication">
    Choose **Google OAuth** for the quickest setup, or **Workload Identity Federation** for a durable non-user identity. For OAuth, complete Google's authorization screen and return to Rootly. For workload identity, complete the authentication-specific setup above.
  </Step>

  <Step title="Select Projects">
    Search the project multi-select and choose up to 50 Google Cloud projects Rootly AI should use. The list contains active projects visible to the Google identity, including each project's display name and project ID. If a visible project is not in the list, enter its exact project ID for Rootly to verify.
  </Step>

  <Step title="Save And Verify">
    Save the selection. Rootly verifies the connection. When AI facts ingestion is enabled for your account, Rootly also begins ingesting project facts for the selected projects.
  </Step>
</Steps>

<ParamField path="Google Cloud Projects" type="multi-select" required>
  Select one or more projects. This selection provides the project scope for investigation tools and bounds optional background fact ingestion when that feature is enabled.

  Authentication and project selection are independent. Adding another project that the connected identity can already access does not require reconnecting. Rootly displays up to 500 discovered projects; for larger organizations, use **Add projects by exact ID** to verify and select projects outside that displayed set.
</ParamField>

<Note>
  Rootly never treats "all projects visible to this Google account" as permission to crawl them all. Newly created projects and projects granted to the identity later remain unselected until an administrator adds them in Rootly.
</Note>

***

## What Rootly AI Can Read

For the selected projects, Rootly AI can use:

* **Cloud Resource Manager** — discover project IDs, names, numbers, folders, and organizations.
* **Cloud Logging** — list log names and query entries with filters and time windows.
* **Cloud Monitoring** — query time series, metric descriptors, alert policies, and active alerts.
* **Cloud Run** — list services and inspect service configuration and status.
* **Compute Engine** — list instances and inspect basic instance state.

All calls use an allowlist of reviewed, read-only tools. Rootly AI cannot create, update, restart, scale, or delete Google Cloud resources.

### Project And Workload Ingestion

When AI facts ingestion is enabled, Rootly records selected projects, their organization or folder hierarchy, Cloud Run services, and Compute Engine instances as infrastructure facts. These facts help it resolve human names such as `payments-prod`, `checkout`, or `worker-1` to the correct Google Cloud resource during an investigation. Logs, metrics, and alerts remain on-demand; Rootly does not persist that raw telemetry as facts.

AI facts ingestion availability depends on your Rootly account rollout. If you need to confirm whether it is enabled for your account, contact Rootly Support. Live investigation tools remain available for the selected projects even when background fact ingestion is not enabled.

Workload ingestion is bounded by the saved project selection. Removing a project purges the facts authored for that project, stops future ingestion, and prevents it from being used as an investigation-tool scope. It does not revoke the connected identity's IAM access; revoke or narrow that access in Google Cloud when you need an enforcement boundary outside Rootly.

***

## During an Incident

You can ask natural questions such as:

* *"Why did checkout errors spike in `store-prod` during the last 20 minutes? Correlate logs and request metrics."*
* *"Are any Cloud Monitoring alerts firing for the payment service, and what changed in its error logs?"*
* *"Is the Cloud Run checkout service healthy in `us-central1`?"*
* *"Which Compute Engine instances in this project are stopped or unhealthy?"*

If a project name is ambiguous, Rootly AI uses discovered project facts to resolve it or asks you to choose among the selected projects.

***

## Adjusting Project Scope

<Steps>
  <Step title="Open The Google Cloud Connector">
    Go to **AI & Agents → Connectors** and click **Configure** on the Google Cloud card.
  </Step>

  <Step title="Update The Project Selection">
    Add or remove projects in the multi-select. Rootly only shows active projects currently visible to the connected Google identity.
  </Step>

  <Step title="Save">
    Save the selection. Added projects become available for investigations and, when AI facts ingestion is enabled, background refreshes. Removed projects are excluded from future queries and refreshes.
  </Step>
</Steps>

If Google definitively reports that a selected project is no longer visible, Rootly blocks live calls to that project and purges the facts it authored for that project. If other selected projects remain visible, the connection stays available. If none remain visible, the connector requires reconfiguration. Transient discovery failures do not replace the last successful fact snapshot with an empty inventory.

***

## Best Practices

* **Select only operational projects Rootly AI needs.** Do not select sandbox, personal, or unrelated projects merely because the identity can see them.
* **Use least-privilege viewer roles.** Grant read access only to the Google Cloud products needed for investigations.
* **Use a stable identity.** Prefer Workload Identity Federation for durable background ingestion. If you use OAuth, a dedicated Google Workspace user avoids coupling the connection to an employee lifecycle.
* **Bind the exact Rootly subject.** Do not grant `roles/iam.workloadIdentityUser` to an entire workload identity pool. Bind the `principal://.../subject/...` value shown for your Rootly team.
* **Separate environments deliberately.** Select production and staging only when responders need both, and use clear project display names so questions resolve predictably.
* **Review project scope after organization changes.** Migrations between folders or organizations can change inherited IAM access.
* **Audit access in Google Cloud.** Google Cloud audit logs remain the authoritative record of API calls and IAM changes.

***

## Troubleshooting

<AccordionGroup>
  <Accordion title="A project is missing from the project picker" icon="magnifying-glass">
    Rootly displays at most 500 projects. First enter the exact project ID in **Add projects by exact ID**; Rootly verifies it before saving. If verification fails, confirm the project is active, appears for the same identity in Google Cloud Console, and grants the identity Resource Manager visibility and `roles/mcp.toolUser`.
  </Accordion>

  <Accordion title="Authorization succeeds but verification fails" icon="triangle-exclamation">
    Rootly could not discover all required managed MCP tools or make a read call. Check that the required Google Cloud APIs and IAM roles are available to the connected identity, then reconnect. Organization policies can also block OAuth applications or Workload Identity Federation.
  </Accordion>

  <Accordion title="Workload Identity Federation token exchange fails" icon="key">
    Confirm that the provider's issuer and allowed audience exactly match the values Rootly derives from the provider resource. Verify the provider's attribute mapping includes `google.subject=assertion.sub`, its condition accepts only your Rootly team ID, and the service-account IAM policy binds the exact `principal://.../subject/...` shown above. Also confirm the Security Token Service and IAM Service Account Credentials APIs are enabled.
  </Accordion>

  <Accordion title="Federation works but Google reports a quota-project error" icon="gauge-high">
    Confirm the configured quota project exists, has the required APIs enabled, and grants `roles/serviceusage.serviceUsageConsumer` to both the exact federated Rootly principal and the connected service account.
  </Accordion>

  <Accordion title="Some tools work while logs, metrics, or workloads fail" icon="lock">
    Google Cloud IAM is product-specific. The identity may be able to discover the project but lack viewer access to Logging, Monitoring, Cloud Run, Cloud Asset Inventory, or Compute Engine. Test the same resource with that identity in Google Cloud Console and add only the missing viewer permissions.
  </Accordion>

  <Accordion title="A selected project was deleted or access was removed" icon="folder-minus">
    Open **Configure**. Rootly identifies previously selected projects that are no longer visible so you can save a repaired scope. If access was removed accidentally, restore IAM permissions first and reopen the connector. Rootly does not use the loss of access as a signal to crawl a different project.
  </Accordion>

  <Accordion title="The connection stopped working after a Google account change" icon="plug-circle-xmark">
    Reconnect Google Cloud and select the projects again. Password changes normally do not revoke OAuth by themselves, but account suspension, administrator revocation, or removal of IAM access does.
  </Accordion>
</AccordionGroup>

***

## Frequently Asked Questions

<AccordionGroup>
  <Accordion title="Can I select multiple Google Cloud projects?" icon="layer-group">
    Yes. One OAuth identity or federated service account can access multiple projects. Rootly's multi-select stores the subset that Rootly AI may use during investigations and, when enabled, background fact ingestion.
  </Accordion>

  <Accordion title="Does selecting projects change Google Cloud IAM?" icon="key">
    No. Project selection only narrows Rootly's behavior. Google Cloud IAM controls what the connected identity can access, and Rootly cannot expand that access.
  </Accordion>

  <Accordion title="Will Rootly automatically ingest new projects?" icon="circle-plus">
    No. Even if the Google identity can see a newly created project, a Rootly administrator must explicitly add it to the connector's project selection.
  </Accordion>

  <Accordion title="Can I connect with a Google Cloud service account?" icon="robot">
    Yes, through Workload Identity Federation. Rootly impersonates a customer-owned service account with short-lived tokens and does not accept uploaded service-account JSON keys. The service account can receive read roles across multiple projects, but an administrator must still select those projects explicitly in Rootly.
  </Accordion>

  <Accordion title="Is the integration read-only?" icon="lock">
    Yes. Rootly exposes only reviewed read tools from Google's managed MCP servers. It does not expose mutation tools or use the connection to alter resources.
  </Accordion>

  <Accordion title="How do I fully disconnect Google Cloud?" icon="trash">
    Disconnect the Google Cloud card in Rootly to remove stored OAuth credentials or workload-identity configuration, stop ingestion, and delete the Google Cloud facts authored by this connector, including selected project, hierarchy, Cloud Run service, and Compute Engine instance facts. Historical investigation context remains unchanged. For defense in depth, also revoke Rootly's OAuth access or remove the workload-identity binding from the service account.
  </Accordion>
</AccordionGroup>

***

## Related Pages

<CardGroup cols={2}>
  <Card title="Connectors Overview" icon="sparkles" href="/ai/connectors/overview">
    The full list of connectors and how they fit together.
  </Card>

  <Card title="Data Privacy for Rootly AI" icon="shield" href="/ai/data-privacy-for-rootly-ai">
    What Rootly AI sees, retention, and model-training controls.
  </Card>

  <Card title="Google Cloud Monitoring Alert Source" icon="bell" href="/integrations/google-cloud-monitoring">
    Send Google Cloud Monitoring alerts into Rootly for routing and response.
  </Card>

  <Card title="Google Cloud managed MCP servers" icon="up-right-from-square" href="https://docs.cloud.google.com/mcp/supported-products">
    Google's reference for managed MCP products and tools.
  </Card>

  <Card title="Google Cloud Workload Identity Federation" icon="key" href="https://docs.cloud.google.com/iam/docs/workload-identity-federation">
    Google's reference for external identities, service-account impersonation, and principal bindings.
  </Card>

  <Card title="Federation for customer resources" icon="users" href="https://docs.cloud.google.com/iam/docs/use-workload-identity-federation-to-let-customers-access-their-cloud-resources">
    Google's SaaS-specific guidance for letting customers create trust in their own Google Cloud environments.
  </Card>
</CardGroup>