Skip to content

Access Management

Statement

Access to ClaimGuard's two distinct surfaces — the cloud / infrastructure layer and the application layer — is governed by separate, documented controls. The cloud side is gated through Google Workspace identity, IAP-SSH, and per-secret IAM bindings on a least-privilege service account. The application side uses an org-scoped role-based model with three authorisation middleware layers and per-key API authentication. Both sides log every privileged action.

The access-management control is operating today across both surfaces. The lifecycle and review layer has roadmap items: no scheduled periodic access review, no formalized joiner/mover/leaver process as a written SOP, no automated de-provisioning, and OS Login is not yet enforced on the VM (the SSH side still uses metadata-keyed access on top of IAP).

Implementation

Cloud / infrastructure access

  • Identity: Google Workspace (dtectvision.ai). See Identity provider.
  • MFA: mandatory at Workspace policy level. See MFA.
  • Privileged role inventory: owners are the founder pair after the IAM cleanup pass cleanup; per-secret bindings on the the workload service account service account; broad-developer roles deferred per founder request to avoid disrupting sibling research workloads on the shared GCP project. See Privileged access for the per-binding record.
  • SSH: IAP-tunnel-only on tcp/22, scoped to Google's IAP source range. No public SSH endpoint, no jump host, no shared bastion VM.
  • Audit: every privileged action recorded for 400 days, immutable. See Audit logging (cloud).

Application access

  • Identity: application-issued email + password (no external SSO yet). API keys for programmatic clients. See Authentication.
  • Authorization: four roles (SUPER_ADMIN, ADMIN, REVIEWER, EXEC_VIEWER) enforced by middleware; org-scoping at the SQL layer. See Authorization.
  • Sessions: stateless 24h JWTs. See Session management.
  • Audit: see Application audit logging.

Joiner / mover / leaver — current state

  • Joiner (cloud): a new operator gets a Workspace identity, appropriate IAM grants assigned by an owner, and proceeds. There is no written checklist; the founder pair grants the minimum needed.
  • Joiner (application): an org admin creates the user via the user-create endpoint with the desired role. The bcrypt-hashed password is set; the an admin-recovery field on the user record admin-recovery column is also written today (gap; see Authentication).
  • Mover: role changes happen via the user-update endpoint. Outstanding JWTs continue to bind the prior role until expiry (≤24h). Cloud-side role changes happen via gcloud projects add-iam-policy-binding / remove-iam-policy-binding.
  • Leaver (cloud): the IAM cleanup pass documents the actual process by example — every binding for the leaver is removed; the gcloud projects remove-iam-policy-binding ... invocations are recorded in the journal.
  • Leaver (application): the org admin sets the active-account flag. the authentication middleware re-checks the active-account flag against the user account store on every request, so the leaver's outstanding JWT is rejected on their next call (401 an explicit disabled-account error code) — not at the next 24h boundary. Cross-listed on Session management.
  • Stale home directories for removed cloud-side users persist on the VM until OS Login (the OS Login step) lands. See Privileged access.

Periodic review — what's not in place

  • No scheduled periodic review of project IAM.
  • No scheduled periodic review of application user / API-key inventory.
  • No sign-off artifact for either review.

A first review pass and a quarterly cadence are the highest-leverage items on the roadmap.

Status

implemented — verified 2026-05-06. Cloud-side and application- side access controls are operating with separate documented models. Departed-staff IAM cleanup demonstrated 2026-05-04 (the former engineer SA + dangling binding deleted; Sergey + Ben confirmed clean). Known gaps below are lifecycle and review-cadence items.

What's in place:

  • A clean cloud-side identity-and-access story (Workspace + IAP + per-secret SA bindings + audit log).
  • A consistent application-side authorization model with four roles and org-scoping.
  • A documented per-leaver removal process by example (the IAM cleanup pass entries).

Known gaps

  • No periodic access review. Largest gap on this page.
  • No formalized joiner/mover/leaver checklist.
  • OS Login is not yet enforced (the OS Login step) — until it lands, cloud-side SSH still uses metadata keys on top of IAP, and stale home directories persist on the VM.
  • No automated de-provisioning — a leaver requires manual IAM / application cleanup.
  • a personal-account principal remains a personal-account principal on the cloud side; planned for re-binding.

Roadmap

  • First quarterly access review — covers cloud IAM, application user inventory, and API-key inventory. Founder sign-off recorded.
  • Joiner/mover/leaver written checklist — one page per role (cloud operator, application user). Trigger on the same Workspace / application events.
  • OS Login enable (the OS Login step) plus stale-home-dir cleanup, in the combined the SA-swap step+the Secure Boot step+the OS Login step maintenance window.
  • Re-bind a personal-account principal to a Workspace identity.
  • JIT access elevation evaluation for owner-class actions (e.g., a "request 30-minute owner role" flow) — longer-term.