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 middleware wrappers and per-key API authentication. Both sides log every privileged action.

What's missing — and what keeps this control at partial — is the lifecycle and review layer: there is no scheduled periodic access review, no formalized joiner/mover/leaver process, 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 A1.4-step1 cleanup; per-secret bindings on the claim-guard-vm@train-cvit2.iam.gserviceaccount.com 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: partial — 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 POST /api/users with the desired role. The bcrypt-hashed password is set; the password_plain admin-recovery column is also written today (gap; see Authentication).
  • Mover: role changes happen via PUT /api/users/:id. 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): A1.4-step1 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 is_active = false. requireAuth re-checks is_active against the users table on every request, so the leaver's outstanding JWT is rejected on their next call (401 code: USER_DISABLED) — 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 (A1.6) 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

partial — verified 2026-04-29.

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 (A1.4-step1 entries).

Known gaps

  • No periodic access review. Largest gap on this page.
  • No formalized joiner/mover/leaver checklist.
  • OS Login is not yet enforced (plan step A1.6) — 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.
  • idonithid@gmail.com 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 (A1.6) plus stale-home-dir cleanup, in the combined A1.1+A1.5+A1.6 maintenance window.
  • Re-bind idonithid@gmail.com to a Workspace identity.
  • JIT access elevation evaluation for owner-class actions (e.g., a "request 30-minute owner role" flow) — longer-term.