Cerberius AgentsHelp
Sign in
More in Access to your live system

Google Cloud

Connect Google Cloud projects with a service account, so the agent can look into virtual machines, Cloud Run, Cloud SQL, Kubernetes clusters and settings, and propose fixes a person approves.

In the appPlatformSettingsAccounts and cloudGoogle Cloud

Connect a client's Google Cloud projects so the agent can see what is really running: virtual machines (Compute Engine), Cloud Run services, Cloud SQL databases, Kubernetes clusters (GKE), storage and networks.

What the agent may do is up to you: it is set in Google Cloud, by the roles you give the service account. Nothing is off limits, access included, but every change waits for a person to approve it. See Changes below.

Connect it#

  1. 1

    In the Google Cloud console (console.cloud.google.com), in one of the client's projects, go to IAM & Admin › Service accounts and click Create service account. Name it, for example cerberius-agent. Copy its email.

  2. 2

    In the same project, go to APIs & Services and make sure the Cloud Resource Manager API is enabled: it lets us list the projects the service account can see.

  3. 3

    In each project the agent should see, go to IAM › Grant access. Paste the service account's email, and choose Viewer to let it look, or Editor (or a role of your own) to let it propose changes.

  4. 4

    Back on the service account's page, go to Keys › Add key › Create new key, choose JSON, and download it.

  5. 5

    Here, go to Settings › Accounts and cloud. Click Connect an account (or Connect another), and choose Google Cloud. Paste the whole JSON key file and click Save.

  6. 6

    The projects it can see show under Where to look, each with its roles. Tick the ones to look in (none ticked: all of them, ticked for you when you save), click Save, then Check connection.

If Google Workspace is connected and its service account also has roles in your projects, tick Use the Google Workspace service account instead of adding a key.

The settings#

SettingWhat it is
Use the Google Workspace service accountSigns in with Google Workspace's key. Only if it has roles in your projects too.
JSON keyThe service account's whole key file. Once saved, it is never shown again; the page shows whose key it is. Paste a new one to replace it.
Where to lookThe projects the agent searches, and the only ones changes may go to, with the service account's roles in each. None ticked: all it can see, ticked for you when you save. If the list can't be read (your runner keeps the key, say), type the project IDs: with none typed, the agent looks in every one it can see and no change is made.
Changes in Google CloudThe same switch as under Settings › Approved changes.
Check connectionSigns in, lists the projects with the roles, and counts the virtual machines, Cloud Run services and databases it can see.
DisconnectOn the card. Removes the settings and its own key. Google Workspace's stays.

How the agent uses it#

  • At the start of each investigation, Cerberius Agents signs in as the service account and gives the agent a read-only pass (Google's cloud-platform.read-only scope) that lasts about an hour. The agent never sees the key.
  • Its tools only read (GET), only in the platform's projects, and only Google Cloud's own APIs. They never read Secret Manager.
  • What it reads can appear in its findings as evidence. Secrets are removed first.
  • Fix runs (a change to code) never get Google Cloud.

Changes#

To let the agent propose Google Cloud changes, switch on Changes in Google Cloud on this page, or under Settings › Approved changes. See Allowing changes.

The agent then puts the exact requests in a change, such as resetting a virtual machine or giving someone back a role. When it's approved (by two people, if you asked for that):

  1. Cerberius Agents reads what each request edits, removes or acts on. If one can't be read, nothing runs.
  2. It sends the requests in order, with the service account's roles, and stops at the first one Google refuses.
  3. The agent checks the result and drafts the reply to the requester.

A few requests are never sent, whatever the roles allow: any that makes a service account key or a token (it would land in the ticket), and any that sets a password the agent wrote.

With your own runner#

When the agent runs on your own runner, the key is kept by you (Scrambled for your runner, or In your store as google-cloud-key); with Google Workspace's service account, its key is the one already kept. Your runner then signs in for each investigation, checks the connection and makes the approved changes. It makes none until its own rules allow them: add a google_cloud section naming the APIs changes may use, for example hosts: [compute.googleapis.com]. It needs version 0.13.0 or later.