# Secrets & Infisical

Gate 3. The full, real secret inventory — derived by grepping every `process.env.*` reference
across `platform/api/src`, `platform/gateway/src`, `platform/provisioner/src`, and
`platform/lab-router/src` (not guessed, not copied from a template list) — and the current
status of centralizing it in Infisical. **This document never contains a secret value.**

## Infisical project status — action required

Chase's self-hosted instance is `infisical.cedshomelab.com` (confirmed reachable, confirmed NOT
`app.infisical.com` — the earlier Phase 9.1 attempt failed for exactly this reason: the existing
machine identity is valid for the self-hosted instance only). Authenticated successfully this
phase using the machine identity at `~/.config/infisical/identity.env`
(`universal-auth`, org "Ceds HomeLab").

**Update, Phase 10.1**: Chase confirmed a "RootNode Academy" project already exists on this
instance. Re-investigated with a proper API call rather than trusting the CLI's interactive
picker alone — `GET /api/v2/organizations/{orgId}/workspaces` (the same authenticated identity,
a direct, complete enumeration, not a scrollable TUI) returns **8** projects visible to this
identity: Core Infrastructure, Kubernetes, Media Platform, Monitoring, Network Service,
Privileged Access Manager, Storage, Synthos Systems. (Two more than Phase 10's original 6-project
CLI capture, and with different membership — the CLI capture was evidently incomplete, not just
under-scrolled; "Hermes Fleet," which appeared in the CLI list, doesn't appear in this
authoritative API list at all.) **Still no "RootNode Academy" entry, under this identity.**

**Root cause, narrowed**: an identity's own workspace list in Infisical reflects only the
projects it has been explicitly granted access to (a per-project ACL, separate from org
membership) — an org owner's dashboard view would show every project in the org regardless of
any one identity's grants. The most likely explanation is that the project exists, created by
Chase, but the `claude-code-migration` machine identity was never added to its access list —
not that the project doesn't exist. This session cannot tell the two apart without either
org-owner API scope or the web dashboard, neither available here. **No duplicate project was
created**, per Phase 10.1's explicit instruction.

**Owner action required — the fix, precisely:** in the Infisical dashboard
(`https://infisical.cedshomelab.com`), open the RootNode Academy project → **Project Settings →
Access → Machine Identities**, and add `claude-code-migration` (identity id
`f3b42de1-11b6-4aa1-8f2e-7b85accec5fb`) with read/write access to whichever environments should
be automatable. Once granted, a future session can list/read/write its secrets directly — no
further CLI/API workaround needed. Until then, every secret continues to live only in local,
gitignored `.env` files (development) — see `docs/PHASE10_PRODUCTION_DEPLOYMENT.md` for
staging/production status.

## Secret inventory (real, from code — not from this prompt's guessed category list)

Every environment variable the application code actually reads, categorized. "Secret" = must
never appear in git, logs, or a browser; "Config" = fine to template/document in plain text
(already handled by `infra/environments/*/*.env.template`, unchanged by this phase).

| Variable | Category | Purpose | Consuming service | Environments | Rotation |
|---|---|---|---|---|---|
| `PLATFORM_DB_URL` | **Secret** (contains DB password) | Postgres connection string | Platform API | Dev/Staging/Prod (per-env DB, never shared) | On suspected compromise; routine rotation not yet scheduled |
| `PROVISIONER_SHARED_SECRET` | **Secret** | Platform API ↔ Provisioner trust boundary (`X-Provisioner-Key`) | Platform API, Provisioner | Dev/Staging/Prod (distinct per env) | On suspected compromise |
| `INTEGRATION_SHARED_SECRET` | **Secret** | Website backend ↔ Platform API trust boundary (`X-RootNode-Integration-Key`) | Platform API, website's backend (external) | Dev/Staging/Prod | On suspected compromise; the website team needs the current value out-of-band |
| `GOOGLE_SERVICE_ACCOUNT_JSON` | **Secret** | Full GWS service-account credential (Gmail API, domain-wide delegation) | Platform API (`email/gws-provider.js`) | Prod only (dev/staging use the deterministic dev provider by default) | Per Google Cloud's own service-account key rotation practice |
| `GOOGLE_DELEGATED_USER` | Config (an email address, not a secret) | Which real mailbox the service account impersonates via domain-wide delegation | Platform API | Prod | N/A |
| `EMAIL_FROM_ADDRESS` / `EMAIL_FROM_NAME` / `EMAIL_REPLY_TO` | Config | Sender identity — `academy@rootnodeacademy.com` | Platform API | All | N/A |
| `STRIPE_SECRET_KEY` | **Secret** | Stripe API authentication (checkout creation, refunds, retrieval) | Platform API (`payment-provider.js`) | Dev/Staging = TEST key; Production = LIVE key — **never mixed**, see Gate 8 status below | Per Stripe's own key-rotation guidance; rotate immediately if ever exposed |
| `STRIPE_WEBHOOK_SECRET` | **Secret** | Verifies a webhook delivery actually came from Stripe | Platform API (`webhook-routes.js`) | One per registered webhook endpoint (TEST vs. LIVE endpoints each have their own) | Regenerates automatically if the endpoint is recreated |
| `TEST_PAYMENT_WEBHOOK_SECRET` | Low-sensitivity (dev-only, never real money) | Shared secret for the deterministic `TestProvider`'s fake webhook signature | Platform API | Dev/test only | N/A |
| `LAB_ROUTER_TLS_KEY` | **Secret** | Lab Host Router's mTLS private key | Lab Host Router | Staging/Prod (dev uses a self-signed pair generated locally) | Per the mTLS cert lifecycle already documented in Phase 4.1 |
| `LAB_ROUTER_TLS_CERT` / `LAB_ROUTER_TLS_CA` | Sensitive but not strictly secret (public cert material) | mTLS certificate/CA chain | Lab Host Router, Gateway | Staging/Prod | Same lifecycle as the key above |
| `PLATFORM_DB_URL`'s host component, ports, timeouts, session TTLs, `PAYMENT_PROVIDER`, `COOKIE_SECURE`, `TRUST_PROXY`, `PUBLIC_APP_ORIGIN`, `DNS_RESOLVER`, `NO_PROXY_CIDRS`, etc. | Config | Plain operational configuration | Various | All, per-environment values | N/A |

Every "Config" row is already handled the existing way — plain values in `infra/environments/
*/*.env.template` (checked into git, safe) or `docker-compose.dev.yml`'s `${VAR:-default}`
substitutions. Only the "Secret" rows above need an Infisical home.

## Environment separation (Stripe — the one category with real launch consequences)

- **Development/Staging**: `STRIPE_SECRET_KEY`/`STRIPE_WEBHOOK_SECRET` must be **TEST** values
  only (`sk_test_...`/a `stripe listen`-issued or TEST-mode dashboard `whsec_...`). This is what
  Phase 9.1 validated end to end.
- **Production**: `STRIPE_SECRET_KEY`/`STRIPE_WEBHOOK_SECRET` must be **LIVE** values
  (`sk_live_...`, and a permanent LIVE-mode dashboard webhook endpoint's own signing secret).
  **Not configured — Chase has not provided live Stripe credentials, and this phase did not ask
  for or receive them** (per Phase 10's own stop condition: "real money could move" /
  "identity verification requires Chase" — live Stripe activation requires Chase's own Stripe
  business/identity verification, not something this session can do on his behalf). See `docs/
  PHASE10_LAUNCH_READINESS.md` Gate 8 status.

## Secret hygiene performed this phase

- Confirmed (again, freshly) that no real secret value has ever entered git history (`docs/
  PHASE10_CANONICAL_STATE_AUDIT.md` §1.6).
- Confirmed `platform/.env`'s Stripe fields are correctly blank (not left set from Phase 9.1's
  validation session) — matches this repo's own "unset after a deliberate session" convention.
- **Not yet performed** (blocked on the missing Infisical project): migrating any real secret
  value out of local `.env` files and into Infisical. Per this phase's own instruction, a local
  credential is never deleted until its Infisical replacement is verified — nothing was deleted.

## What Chase needs to do

1. In the existing "RootNode Academy" project's **Project Settings → Access → Machine
   Identities**, add `claude-code-migration` (id `f3b42de1-11b6-4aa1-8f2e-7b85accec5fb`) with
   read/write access to whichever environments should be automatable. **Do not create a second
   project** — this one-line access grant is the fix, per Phase 10.1's investigation.
2. Confirm the project's environment names (Phase 10.1 could not see them without access) —
   reuse whatever exists rather than renaming to force a Development/Staging/Production match,
   per this repo's own "existing structure wins" instruction.
3. Once access is granted, a future session can populate every "Secret" row above from the
   current local `platform/.env`/`platform/provisioner/.env` values for Development, and Chase
   provides the real Staging/Production values (Stripe LIVE keys especially) directly when ready
   for those environments — never invented or guessed by this phase.