rootnode-academy/docs/SECRETS_AND_INFISICAL.md

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 — [email protected]	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.