Signed-route endpoint access for the Docker runtime (pre-OSEP feedback)

[dcaminos]

Hi all — I'd like to gauge appetite before opening an OSEP PR.

Problem. On the Docker runtime there's no first-party, authenticated way to expose a single
sandbox's port to a browser. secure_access and signed routes are Kubernetes-gateway-only
(configuration.md), and Docker allows only ingress.mode = "direct". The one server-wide
credential ([server] api_key) is the wrong thing to hand a browser user — it's the control-plane
master key, never expires, and isn't scoped to a sandbox/port.

Idea. Teach the OpenSandbox server's own reverse proxy to verify OSEP-0011 signed routes
for Docker, reusing the existing signature format, expires semantics, and
[ingress.secure_access] key ring verbatim — through one shared, runtime-agnostic verifier
abstraction (the K8s gateway and the Docker proxy become two call sites of the same logic, not two
implementations). Operators point a wildcard transport (wildcard DNS + reverse proxy, or a
wildcard-capable tunnel) at the proxy; each sandbox gets its own signed, expiring hostname and thus
its own browser origin. Wildcard host is primary; URI path mode is a documented single-hostname
fallback.

Explicitly out of scope: multi-tenancy on Docker, any managed/vendored tunnel, and any change
to Kubernetes behavior. Fully opt-in and backward compatible.

Questions for maintainers:

1. Is enabling secure_access on Docker (verification in the server proxy) a direction you'd accept?
2. Preference on factoring the verifier as shared code vs a Docker-local implementation?
3. Any concerns with the server proxy taking on verification (vs a separate Docker ingress component)?

Draft OSEP for reference (not yet a PR):
https://github.com/dcaminos/OpenSandbox/blob/feature/osep-signed-endpoints-docker/oseps/0023-signed-route-endpoint-access-for-the-docker-runtime.md

Happy to adjust scope based on feedback before submitting the OSEP.