> ## Documentation Index > Fetch the complete documentation index at: /docs/llms.txt > Use this file to discover all available pages before exploring further. # Google Cloud > Read Cloud Logging and Cloud Monitoring through a service account. Auto Monitors can create alert policies. **1. Create a service account** Run the setup command Ordyn shows, or create a service account by hand with the roles below. Then create a key in JSON format. **2. Connect** Go to **Connections**, click **Connect** next to Google Cloud, and enter the project ID and the key JSON. ## Permissions The service account needs Cloud Asset Viewer, Service Usage Consumer, Logs Viewer and Monitoring Viewer to read, plus Monitoring AlertPolicy Editor, Monitoring NotificationChannel Editor and Logs Configuration Writer for Auto Monitors to create alert policies. Optionally, Cloud Run Viewer, Compute Viewer, Kubernetes Engine Cluster Viewer and Cloud SQL Viewer let Ordyn confirm deleted resources. The setup command grants all eleven and enables the core APIs Ordyn calls. ### Infrastructure inventory List deployed resources through Cloud Asset Inventory. | Granted by | Used for | | - | - | | **Cloud Asset Viewer** (`roles/cloudasset.viewer`) | Listing deployed resources and their configuration through Cloud Asset Inventory. | | **Service Usage Consumer** (`roles/serviceusage.serviceUsageConsumer`) | Calling Cloud Asset Inventory on behalf of the project. | Permissions Ordyn uses: `cloudasset.assets.listResource`, `cloudasset.assets.searchAllResources`, `serviceusage.services.use`. ### Resource configuration Read resource configuration from Cloud Asset Inventory. Granted by: **Cloud Asset Viewer** (`roles/cloudasset.viewer`). Permissions Ordyn uses: `cloudasset.assets.listResource`. ### Metrics Discover metrics and read time series through Cloud Monitoring filters or PromQL in the connected metrics scope. Granted by: **Monitoring Viewer** (`roles/monitoring.viewer`). Permissions Ordyn uses: `monitoring.metricDescriptors.list`, `monitoring.timeSeries.list`, `monitoring.monitoredResourceDescriptors.list`. ### Logs Read application logs, including GKE and Cloud Run logs. Granted by: **Logs Viewer** (`roles/logging.viewer`). Permissions Ordyn uses: `logging.logEntries.list`. ### Infrastructure change history Read Admin Activity and System Event audit logs. Granted by: **Logs Viewer** (`roles/logging.viewer`). Permissions Ordyn uses: `logging.logEntries.list`. ### Existing alerts Read existing alert policies and notification channels. Granted by: **Monitoring Viewer** (`roles/monitoring.viewer`). Permissions Ordyn uses: `monitoring.alertPolicies.list`, `monitoring.alertPolicies.get`, `monitoring.notificationChannels.list`. ### Manage monitoring Create and maintain the alert policies, log-based metrics and the notification channel that delivers alerts to Ordyn. | Granted by | Used for | | - | - | | **Monitoring AlertPolicy Editor** (`roles/monitoring.alertPolicyEditor`) | Creating alert policies. It does not include creating notification channels. | | **Monitoring NotificationChannel Editor** (`roles/monitoring.notificationChannelEditor`) | Creating the channel that delivers alerts to Ordyn. | | **Logs Configuration Writer** (`roles/logging.configWriter`) | Creating log-based metrics. | Permissions Ordyn uses: `monitoring.alertPolicies.create`, `monitoring.alertPolicies.update`, `monitoring.alertPolicies.delete`, `monitoring.notificationChannels.create`, `logging.logMetrics.create`, `logging.logMetrics.get`, `logging.logMetrics.update`, `logging.logMetrics.delete`. ### Confirm deleted resources Confirm that a Cloud Run service, Compute Engine instance, GKE cluster or Cloud SQL instance was deleted. Only needed if you want deleted resources to leave inventory right away; without these, Ordyn keeps them until it can confirm. | Granted by | Used for | | - | - | | **Cloud Run Viewer** (`roles/run.viewer`) | `run.services.get` | | **Compute Viewer** (`roles/compute.viewer`) | `compute.instances.get` | | **Kubernetes Engine Cluster Viewer** (`roles/container.clusterViewer`) | `container.clusters.get` | | **Cloud SQL Viewer** (`roles/cloudsql.viewer`) | `cloudsql.instances.get` | Permissions Ordyn uses: `run.services.get`, `compute.instances.get`, `container.clusters.get`, `cloudsql.instances.get`. * Ordyn's core APIs are Cloud Asset, Cloud Resource Manager, Cloud Monitoring and Cloud Logging. The setup and grant commands enable them with `gcloud services enable cloudasset.googleapis.com cloudresourcemanager.googleapis.com monitoring.googleapis.com logging.googleapis.com --project `. If one is disabled, the permission check marks the reads that go through it as unverified and names the disabled API. Auto Monitors write access is checked from IAM permissions only, so it can still show verified while an API is disabled. * Confirming deleted resources also calls the Cloud Run, Compute Engine, Kubernetes Engine and Cloud SQL Admin APIs (`run.googleapis.com`, `compute.googleapis.com`, `container.googleapis.com`, `sqladmin.googleapis.com`). The setup command does not enable them. Each is already on in a project that uses that service; if one is off, Ordyn keeps that kind of resource in inventory until it can confirm the deletion. * Whoever runs the setup or grant command needs `serviceusage.services.enable` in the project to enable the APIs (for example the Service Usage Admin role) and `resourcemanager.projects.setIamPolicy` to grant the roles (for example Project IAM Admin). If enabling an API fails, the command stops before granting any role and exits non-zero. ### How to grant > **Enable the APIs and grant the roles** > > ```bash theme={null} > gcloud services enable cloudasset.googleapis.com cloudresourcemanager.googleapis.com monitoring.googleapis.com logging.googleapis.com --project && > gcloud projects add-iam-policy-binding --member "serviceAccount:" --role roles/cloudasset.viewer && > gcloud projects add-iam-policy-binding --member "serviceAccount:" --role roles/serviceusage.serviceUsageConsumer && > gcloud projects add-iam-policy-binding --member "serviceAccount:" --role roles/logging.viewer && > gcloud projects add-iam-policy-binding --member "serviceAccount:" --role roles/monitoring.viewer && > gcloud projects add-iam-policy-binding --member "serviceAccount:" --role roles/monitoring.alertPolicyEditor && > gcloud projects add-iam-policy-binding --member "serviceAccount:" --role roles/monitoring.notificationChannelEditor && > gcloud projects add-iam-policy-binding --member "serviceAccount:" --role roles/logging.configWriter && > gcloud projects add-iam-policy-binding --member "serviceAccount:" --role roles/run.viewer && > gcloud projects add-iam-policy-binding --member "serviceAccount:" --role roles/compute.viewer && > gcloud projects add-iam-policy-binding --member "serviceAccount:" --role roles/container.clusterViewer && > gcloud projects add-iam-policy-binding --member "serviceAccount:" --role roles/cloudsql.viewer > ``` Replace the values in angle brackets. Permission catalog version `2026-10-16.1`. See [permission changes](/reference/permission-changes). ## What Ordyn reads Cloud Logging entries filtered by resource, severity, and time, including GKE and Cloud Run logs, plus Cloud Monitoring metrics. ## PromQL and Managed Service for Prometheus Ordyn uses your existing Google Cloud connection to query PromQL in the connected project's metrics scope. PromQL supports native Cloud Monitoring metrics as well as Prometheus metrics; no additional Prometheus connection or token is needed. The existing Monitoring read and alert-policy roles cover these operations. Ordyn can preserve PromQL evidence, run watches, and manage native PromQL alert policies. Each PromQL policy has one condition; multiple signals use separate policies. Kubernetes-managed Rules, ClusterRules, and GlobalRules are a separate inventory, inspected only through configured Kubernetes connections. Inaccessible cluster inventories are reported as uninspected. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.