Skip to main content
Google Cloud is a provider: connect it once with a service account, and Nexus can reach the projects behind it. From there it queries your logs, metrics, and traces, and inspects the Kubernetes clusters running on GKE, all through a single set of credentials.

What it provides

Connecting Google Cloud lets Nexus discover and query the data sources behind your projects: Each has its own page covering what it supports and how it’s enabled.

Setup

What you’ll need:
  • A Google Cloud service account key in JSON.
  • The IAM permissions below, granted to that service account.
We recommend a read-only service account: Nexus only ever reads from Google Cloud, never writes. Grant the permissions through read-only roles rather than broad editor or owner roles.

Permissions

Grant these on each project you want Nexus to reach. Logs, metrics, and traces. These are what the connect form checks before a project can serve that capability:
  • logging.logEntries.list: list Cloud Logging entries.
  • logging.views.access: read the log views those entries belong to. Nexus needs this together with logging.logEntries.list before it can read logs. roles/logging.viewer covers both permissions for a project’s default log views. roles/logging.viewAccessor covers specific log views.
  • monitoring.timeSeries.list: query Cloud Monitoring time series, which is how Nexus graphs metrics.
  • cloudtrace.traces.get: retrieve a Cloud Trace trace by its ID.
Finding projects and workloads. These let Nexus discover what a project runs, so queries name a real resource:
  • cloudresourcemanager.projects.list: list the projects the service account can reach. Without it, connect a single project by supplying its ID directly (see below).
  • serviceusage.services.list: list the APIs enabled on a project, which decides whether Nexus looks for Cloud Logging, Cloud Monitoring, Cloud Trace, GKE, Cloud SQL, or Memorystore.
  • monitoring.metricDescriptors.list: list the metric types a project emits, and the labels on them, before a metric query is built.
  • logging.buckets.list: read each log bucket’s retention window. This one is optional. Queries still run without it, and the retention window stays unknown.
  • cloudsql.instances.list: list Cloud SQL instances, so a query can name a specific database.
  • redis.instances.list: list Memorystore for Redis instances.
  • The roles/container.viewer role: discover GKE clusters. It includes container.clusters.list, the call that finds clusters in a project. Reading workloads inside a cluster is covered on the Kubernetes page.

Connect Google Cloud

  1. From the Nexus telemetry settings, add a telemetry data source and choose Google Cloud.
  2. Paste your service account JSON key. If the account can’t list projects across your organization, enter a single project ID instead and we’ll connect just that project.
  3. Test the connection. We check the key is valid and confirm the account holds the permissions it needs.

Enabling projects

Once connected, Nexus discovers every project the service account can reach. Each project arrives disabled by default, so you opt in deliberately rather than exposing every project at once. Review the list and enable the ones your team runs production workloads in. Enabling a project turns on its Cloud Logging access and surfaces the GKE clusters running inside it, which you then enable individually.

Private clusters

If a GKE cluster’s API endpoint is private, attach a proxy to the Google Cloud connection. Discovered clusters use that proxy by default, and each one can instead choose a different proxy or the public internet from Network access in its settings. If you change the proxy on the connection later, clusters still inheriting it follow the change. The proxy is only used to reach your clusters. Nexus calls Cloud Logging, Cloud Monitoring, Cloud Trace, and the rest of Google’s APIs over the public internet.

Google Cloud Logging

Querying your project logs during an incident.

How telemetry works

Routing, query planning, guidance, and memory.