1.2 Access & First Week

Welcome! If you are reading this documentation, you should already have received your name@moonitoring.com account and be ready to start finding your way around Moonitoring.

Your first week is usually about settling in, getting familiar with the communication platforms we use, and learning the tools that support the team's daily work. Take the time to explore them and understand where conversations, tasks, and shared information live.

After this initial period, you will normally begin focusing on your project or mission. Whenever possible, an experienced team member or the project's manager will work alongside you, helping you understand the context and get started with confidence.

Give yourself time

Onboarding is not a test, and nobody expects you to know everything immediately. Ask questions, take notes, and lean on your colleagues while you build up context.

Cloud access

Having a moonitoring.com account does not grant cloud administration or access to application data. We use dedicated Google Workspace or Cloud Identity groups for human cloud access. Terraform grants roles to the groups; authorized directory administrators manage their members manually outside Terraform. You do not need a Terraform change each time someone joins an existing approved group.

Group email	Intended access after the reviewed IAM rollout
infra-admins@moonitoring.com	Administer the shared foundation and active environments through their Terraform identities. One group covers stage and, after explicit activation, production; this is privileged infrastructure access.
stage-release-admins@moonitoring.com	Approve the stage build/deployment gate, separately from PR review.
prod-release-admins@moonitoring.com	Reserved for production release approval; production remains inactive.
stage-observers-admins@moonitoring.com	Inspect stage resource metadata, ordinary logs and monitoring, without SQL login/Studio, object contents, secrets, Terraform state or impersonation.
observers-admins@moonitoring.com	Reserved for the corresponding production observation scope; no production grant is active.

As of 4 November 2026, six security groups exist, but no IAM grants to these groups are live. Their Google display names have a gcp prefix; their email addresses above do not. The sixth group, stage-infra-admins@moonitoring.com, is unused: do not grant it access or delete it as part of this rollout. Existing personal access remains in place. Jacopo and Lorenzo are the agreed responsible people; the group verification record distinguishes confirmed memberships from checks still pending.

The stage approval gate is separate from PR review and is not active yet. Cloud Build's project-level approver role in the shared CI project does not provide separate stage/prod approval scopes; production approval activation remains blocked until that boundary is resolved. An infrastructure administrator's direct cloud permissions can bypass the deployment path, so this is not a universal approval requirement for every Google Cloud action. Follow the team-access runbook for rollout and acceptance checks.

Joining or changing a group

1. Agree the required access with the responsible infrastructure owner. Record the person, group, reason, approver and any end date. Each group needs a named owner and backup; do not assume that every developer should be an infrastructure administrator.
2. An authorized directory administrator adds the corporate account to the approved group and records the directory audit event or equivalent change evidence. Group owners control membership; members must not be able to grant themselves broader access.
3. Verify membership, who may change it and whether external membership is prohibited; the latter settings are not yet verified for this rollout. Verify the required operation after propagation, and an operation that should remain denied. Existing personal or inherited grants can mask missing group access, so also verify the group-to-resource assignment.
4. Changes to a group's role or resource scope require a reviewed Terraform plan. During the initial migration, add and verify group access before removing a superseded personal grant in a separate reviewed step, then test again with fresh authentication.

Cloud groups do not synchronize application users, Organization memberships, roles, capabilities or entitlements. Those follow the application access model. Interactive SQL access and its database privileges also require an explicit separate decision. Observer log access reads actual log content, so applications must avoid recording raw data or secrets there.

Leaving or reducing access

The group owner and directory administrator remove memberships that are no longer justified and record who changed them, when and why. Review direct IAM exceptions, other groups, external organization-policy delegation and any separately granted SQL/application access; removing one membership is not a complete offboarding check. Revoke sessions where appropriate, allow for propagation and verify that the former access is denied. Terraform-managed exceptions are removed through a reviewed change; unrelated personal grants are not automatically removed by Terraform's additive IAM resources.

Review group membership and named exceptions regularly and when responsibilities change. Keep an already authorized administrator available for recovery during the initial access migration; do not remove the working access path before its replacement is verified.