Skip to content

6.2.2.23 MoonitoringUser

6.2.2.23.1 Purpose

Anyone who acts for Moonitoring itself: a person on the team, or a service account such as model training, the continuous integration (CI) pipeline that builds our software, or an internal job. Moonitoring users never reference organization users or roles, which keeps platform access isolated from customer access.

6.2.2.23.2 Questions it answers

  • Who operates the platform, and which jobs run under a service account?
  • Who is responsible for a service account, and when was it last used?
  • Which builds, releases or model runs did this user create?

6.2.2.23.3 Fields

Field Type Cardinality Description
id string (uuid) 1..1 Key.
disabled_at datetime 0..1
created_at datetime 1..1
updated_at datetime 1..1

6.2.2.23.4 Subtypes

Discriminator type: every MoonitoringUser is exactly one of the subtypes below (disjoint and complete).

MoonitoringPerson

Field Type Cardinality Description
name string 1..1
surname string 1..1
email string (regex) 1..1 Unique.

MoonitoringServiceAccount

Field Type Cardinality Description
description string 1..1
owner MoonitoringPerson 1..1
credential_ref string 1..1 Reference to the credential in the secret manager. Secrets and keys never enter the database.
The secret is named access-staff-<id>, after the MoonitoringServiceAccount.
last_used_at datetime 0..1
google_service_account string (regex) 0..1 The e-mail of the Google service account allowed to act as this account through Identity-Aware Proxy, such as the CI's: a request IAP lets in with that Google service account's ID token is exchanged at access for a staff token of this account, which carries its own staff roles. It needs no key: credential_ref stays, but nothing has to be stored there.
Only a Google service account's address (ending in .gserviceaccount.com), never a person's, so it can never be confused with a MoonitoringPerson's e-mail; kept in lower case.
Unique among enabled MoonitoringServiceAccounts; a disabled account keeps it but no longer signs in with it.
Set and cleared only by staff holding access.moonitoring_access.manage, through the Console (staff API); each change is an audit event. Empty means the account does not sign in through Identity-Aware Proxy.
  • Its roles hold no admin capability of MoonitoringCapabilityEnum. The training account holds farm.canonical_data.read_all and ai-model-platform.datasets.read; the CI account holds releases.builds.upload and releases.releases.read, and nothing else: releases-publish first reads the applications, depots and builds that the Builds API guards with releases.releases.read. Staging a build on a channel (releases.releases.stage) stays with people.

6.2.2.23.5 Relationships

References

Referenced by

Subtypes

6.2.2.23.6 Rules & constraints

  • Who acts for Moonitoring: a person or a service account (model training, CI, internal jobs). Roles are given to both (MoonitoringAccessControlMembership).
  • Every API call is logged in Cloud Logging with the acting user's id; data reads for models are recorded as ModelRun.