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.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.
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.
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 namesrootly-ai for the pool and rootly for the provider. Replace the placeholder values with your own:
Enable Federation APIs
Create The Workload Identity Pool
Create An OIDC Provider For Your Rootly Team
Create And Bind The Service Account
Grant Read Access To Selected Projects
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.Configure The Quota Project
Finish In Rootly
- 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
Connecting
Start The Google Cloud Connection
Choose Authentication
Select Projects
Save And Verify
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.
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 aspayments-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-prodduring 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?”
Adjusting Project Scope
Open The Google Cloud Connector
Update The Project Selection
Save
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.workloadIdentityUserto an entire workload identity pool. Bind theprincipal://.../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
A project is missing from the project picker
A project is missing from the project picker
roles/mcp.toolUser.Workload Identity Federation token exchange fails
Workload Identity Federation token exchange fails
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.Federation works but Google reports a quota-project error
Federation works but Google reports a quota-project error
roles/serviceusage.serviceUsageConsumer to both the exact federated Rootly principal and the connected service account.Some tools work while logs, metrics, or workloads fail
Some tools work while logs, metrics, or workloads fail
A selected project was deleted or access was removed
A selected project was deleted or access was removed
The connection stopped working after a Google account change
The connection stopped working after a Google account change
Frequently Asked Questions
Can I select multiple Google Cloud projects?
Can I select multiple Google Cloud projects?
Does selecting projects change Google Cloud IAM?
Does selecting projects change Google Cloud IAM?
Will Rootly automatically ingest new projects?
Will Rootly automatically ingest new projects?
Can I connect with a Google Cloud service account?
Can I connect with a Google Cloud service account?
Is the integration read-only?
Is the integration read-only?
How do I fully disconnect Google Cloud?
How do I fully disconnect Google Cloud?