Raxx · internal docs

internal · gated

ADR 0083 — Infisical Google OIDC SSO via Cloudflare Access

Status: Superseded 2026-05-13 UTC — partial. CF-Access-gates-URL stays; Infisical-side OIDC trust configuration abandoned. See "Supersession" section below + docs/business-legal/infisical-pricing-2026-05-13.md. Date: 2026-05-12 UTC Deciders: Kristerpher (operator) Scope: Infisical vault (vault.raxx.app) and Infisical Cloud SaaS (app.infisical.com) Issue: #963 Refs: ADR-0031 (platform auth posture), ADR-0042 (auth unification), ADR-0077 (WAF layered defense), docs/ops/runbooks/infisical-cloud-config.md, terraform/cf-access/main.tf

Supersession (2026-05-13 UTC)

Both halves deferred. Pre-launch posture: email-OTP at CF Access. Period.

The premise in Decision 2 below — that Infisical would accept the CF JWT as a generic OIDC IdP at the free tier — was wrong. On 2026-05-13 the operator hit Infisical's Pro paywall when opening Organization Settings → SSO → OIDC. Pricing research (docs/business-legal/infisical-pricing-2026-05-13.md) confirmed OIDC is Pro-gated at ~$18/identity/mo. The Infisical-side configuration is therefore NOT pursued.

A second pivot followed the same day: the operator chose to defer the CF Zero Trust → Google IdP wiring as well, to phase 2 (post-launch). Pre-launch focus is shipping, not SSO polish. Email-OTP at CF Access is sufficient for solo operator with hardware MFA on the receiving inbox.

Pre-launch state (locked 2026-05-13): - CF Access at vault.raxx.app → precedence-1 email-OTP, allow kris@moosequest.net only. Active. This is the entire gate. - terraform/cf-access/terraform.tfvars: both cf_google_workspace_client_id and cf_google_idp_id empty. - Google Workspace IdP exists in CF (dashboard-registered, id 18c69c18-14db-4f12-94f6-6c69d27cb04b) but is NOT in TF state and NOT referenced by any SSO policy. Harmless. - Google OAuth 2.0 client minted in Google Cloud Console + secret in SSM at /raxx/cf-access/google_oidc_client_secret. Both stay in place for phase-2 use.

Phase 2 (post-launch) — what to do when we revisit: see project_infisical_sso_not_pursued.md memory file for the full step-by-step. Short version: terraform-import the existing Google IdP, set both tfvars back, apply. Then operator enrolls a passkey at Google. Do NOT touch Infisical Org Settings → SSO — that half stays abandoned unless tier gating changes.

What remains valid in this ADR: D1 (Google Workspace as identity root — long-term direction), D5 (Google OAuth client secret in SSM — pattern still correct), D6 (rotation cadence — applies whenever phase 2 activates).

What is abandoned: D2 (Infisical-side OIDC trust of CF JWT). Steps 3+4 of docs/ops/runbooks/infisical-sso.md explicitly skipped.

What is deferred: D3 (precedence-2 Google SSO policy at CF Access), D4 (Infisical Org Settings — abandoned, not deferred — distinct).

Revisit triggers: (a) team grows past 1 operator, (b) operator UX pain with email-OTP, (c) Infisical lowers OIDC tier gating, (d) compliance/audit gate appears that requires unified SSO logs.

Context

Operator-locked 2026-05-12: the human-to-human identity layer is Google Workspace (moosequest.net). All operator tooling that requires interactive authentication should use the same identity provider to minimize credential sprawl and to leverage the audit trail that Google Workspace provides.

Infisical supports two SSO paths for interactive operator login:

  1. Direct Google OIDC — Infisical acts as the OIDC relying party, receiving an id_token directly from Google's OIDC endpoint (accounts.google.com). Requires an OAuth 2.0 Client ID registered in Google Workspace admin. Supported on Infisical Pro tier and above.

  2. Cloudflare Access as upstream OIDC IdP — Infisical delegates OIDC to Cloudflare Access, which can itself be backed by any CF-supported identity provider (including Google Workspace). Infisical receives a CF-signed JWT rather than a Google-signed token. This path does not require an Infisical Pro tier SSO feature, since Cloudflare does the identity assertion and Infisical sees it as generic OIDC.

The existing vault.raxx.app CF Access policy already gates the Infisical UI at the edge (operator email allowlist in terraform/cf-access/main.tf → vault_operator). The Infisical Cloud SaaS CF Access app (cloudflare_zero_trust_access_application.infisical_cloud_saas) already exists in Terraform.

Decision

D1: Use Cloudflare Access as the upstream OIDC IdP for Infisical SSO (both self-hosted and Cloud SaaS)

Rationale:

D2: Google Workspace OAuth 2.0 client is registered in CF Zero Trust, not in Infisical directly

The OAuth 2.0 Client ID and Client Secret for the moosequest.net Google Workspace tenant are registered once in CF Zero Trust (Settings → Authentication → Add → Google) and referenced from CF Access policies. They are NOT stored in Infisical's own SSO configuration — which would create a bootstrap circularity: Infisical's SSO config requires secrets that would be stored in Infisical itself.

This separation is consistent with feedback_aws_workloads_use_ssm_not_vault.md: vault-resident secrets should not be the prerequisites for reaching the vault.

D3: Machine identities (service tokens, universal auth) are unaffected

The Infisical service token path (used by Raptor, Console, Velvet, CI) does not go through SSO. Service tokens authenticate against the Infisical API directly. The Google OIDC / CF Access gate applies only to interactive browser-based operator sessions.

The raxx-agent-vault-access-policy (CF Access non-identity service token policy on vault.raxx.app) is explicitly excluded from any MFA or OIDC requirement, as noted in terraform/cf-access/main.tf.

D4: The Terraform provider does not expose Infisical SSO config — operator action required

The official Infisical/infisical Terraform provider does not manage organization-level SSO / OIDC IdP settings (confirmed as of 2026-05). SSO configuration is applied manually via the Infisical Organization Settings UI. The runbook (docs/ops/runbooks/infisical-sso.md) documents the exact steps.

The CF Access Google Workspace IdP registration IS Terraform-manageable via cloudflare_zero_trust_identity_provider (type = google) and is implemented in terraform/cf-access/vault_google_idp.tf. The vault_operator and infisical_cloud_operator CF Access policies are updated to list the Google IdP as the required identity source when cf_google_idp_id is set.

D5: The Google OIDC Client Secret lives in SSM, not in Infisical

Following feedback_aws_workloads_use_ssm_not_vault.md, the Google OAuth 2.0 Client Secret (registered in CF Zero Trust Settings → Authentication) is stored in AWS SSM Parameter Store at /raxx/cf-access/google_oidc_client_secret (SecureString). It is not stored in the Infisical vault. The Client ID is not sensitive and is tracked in terraform/cf-access/terraform.tfvars as a non-secret variable.

Consequences

Positive

Negative / risks

Alternatives considered

Alt A: Direct Google OIDC in Infisical (not via CF Access)

Would require Infisical Pro tier to use the native SSO feature. Also creates a separate OAuth 2.0 client registration with a client secret that must be stored somewhere — reintroducing the bootstrap circularity. Rejected.

Alt B: Email OTP only (no Google OIDC)

The existing CF Access gate uses OneTimePIN (email OTP). This is functional but does not satisfy the operator-locked Google Workspace identity requirement. Rejected for interactive sessions; retained for break-glass / emergency scenarios.

Alt C: SAML 2.0 via Google Workspace

Infisical supports SAML on Pro tier. More complex to configure than OIDC; no incremental benefit over OIDC for a single-operator setup. Rejected.

References