carlos / platform Public

Problem. The doc_engine capability (internal/caps/render.go, README "App capabilities") fences an engine's egress away from private networks. It says nothing about who can call the engine. A doc-engine route is a route like any other, so the box's public edge serves it, and nothing on main makes a route internal-only. The only gate is whatever auth the engine applies itself (Gotenberg: basic auth, often none). A leaked credential, or an operator who skips auth, publishes a Chromium/LibreOffice renderer to the internet: resource abuse at best, and an SSRF engine whose only remaining reach is the public internet and its own box's loopback.

Why it matters now. #328 (an isolated tenant reaching its operator's private Gotenberg) gets a per-app egress allow as the near-term answer. The platform's own engine story should not be "put it on the internet behind basic auth", which is what an isolated tenant has to do today to reach a doc-engine route.

Proposed direction (needs a spec):

• A doc-engine route is fleet-internal: the edge refuses its hostname on public listeners.
• Consuming apps get an operator grant to use a named engine, per app (the same exception to the --host-only grant rule that #328's egress allow takes).
• The platform carries the call: a socket bound into each consuming instance's namespace (as the per-instance control socket is), relayed by the box's edge to the engine's box over the fleet's private path. Isolated tenants then reach an engine without any private address opened in their fence.
• Provider-neutral: the relay is the edge's, not a VPC feature.

Not blocking: Tito's Gotenberg is outside the platform, so #328's egress allow unblocks it independently.