Repository navigation
Replies: 1 comment
|
Closing this one out: the static-credential half landed as separate, smaller PRs (#1954 keeps Docker sandbox ports off public interfaces, #1963 lets |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
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_accessand signed routes are Kubernetes-gateway-only(
configuration.md), and Docker allows onlyingress.mode = "direct". The one server-widecredential (
[server] api_key) is the wrong thing to hand a browser user — it's the control-planemaster 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,
expiressemantics, and[ingress.secure_access]key ring verbatim — through one shared, runtime-agnostic verifierabstraction (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:
secure_accesson Docker (verification in the server proxy) a direction you'd accept?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.
All reactions