docs(authentik): correct the Mendys silo exposure model — security-service is the front door

[izzywdev]

Follow-up to #428. The exposure guidance that shipped with the MendysRobotics silo was wrong in two ways, one of them actively dangerous.

1. Wrong architecture

It framed the browser-facing surface as a choice between exposing auth.mendysrobotics.com and proxying Authentik's paths on the MendysRobotics ingress. Neither is the architecture.

Authentik is an implementation detail of FuzeFront's security-service, which is the single front door for every tenant. MendysRobotics users reach live. / marketplace.mendysrobotics.com; those hosts route /api/v1/security/* and /api/auth/* to security-service, and security-service drives the correct Authentik instance in-cluster over ClusterIP. Nothing outside FuzeFront's boundary addresses Authentik — not end-users, not the MendysRobotics apps, which hold no Authentik configuration at all.

This is the module's own stated contract, not a new invention — backend/security/src/providers/authentik/config.ts:

"no vendor name leaks past this boundary into the API surface"
"the browser is ALWAYS sent to a same-host path … so the browser never sees an internal identity host"

2. Dangerous advice

It said an exposed IdP host is "only safe behind an edge auth gate (Cloudflare Access)". That is false and would have broken sign-in. A host carrying live OIDC traffic cannot be gated — templates/ingress.yaml already says so:

"Putting an auth gate in front of it would break sign-in for every user."

Access is only usable on an admin host that carries no OIDC traffic. The authentikMendys.ingress block is now documented as a debug escape hatch, not a production path.

Login mechanisms for this tenant, now documented

• Password + enrollment → the server-side flow driver. security-service calls Authentik's /api/v3 flow-executor server-side and issues its own session; the browser never touches Authentik, so no Authentik paths are routed on the Mendys hosts at all (unlike app.fuzefront.com, which does route them).
• Social → the server-brokered path, which already exists: Google redirects to /api/v1/security/social/google/callback on the tenant host — a security-service route — and security-service exchanges the code with Google itself. It must never fall back to Authentik's /source/oauth/*, so securityService.googleBrokered must be "true" for this tenant. It currently defaults to "false".

What is NOT yet true

Recorded honestly in the README: security-service is single-tenant. It reads AUTHENTIK_ISSUER_URL, AUTHENTIK_BASE_URL, AUTHENTIK_CLIENT_ID/SECRET, AUTHENTIK_ADMIN_TOKEN and AUTHENTIK_ENROLLMENT_FLOW_SLUG straight from process.env at ~12 call sites across 7 files, each defaulting to FuzeFront (…/application/o/fuzefront/, fuzefront-enrollment). Until it resolves a tenant per request, this silo cannot serve a login — the blueprints are correct and inert, waiting on that work. Tracked separately.

Verification

Comments and README only. helm lint clean, kubeconform -strict 16/16 valid, and the rendered manifests are byte-identical to the merged state — no Kubernetes spec change, so this cannot disturb anything running.

🤖 Generated with Claude Code