Repository navigation
config preflight exits 0 on allow_unauthenticated_users = true #5090
Description
Summary
openshell-gateway config preflight validates the shape of a configuration but not whether its choices are ones an operator should permit. In particular it exits 0, silently, on allow_unauthenticated_users = true — the one switch that turns v0.1.6's refusal-to-start-unauthenticated back into v0.1.5's warn-and-continue.
Measured on v0.1.6
Four arms, same binary, same host:
| config | result |
|---|---|
| valid config | exit 0, silent |
compute_driver = "not-a-driver" |
exit 1, category=malformed |
| malformed TOML | exit 1 |
allow_unauthenticated_users = true under [openshell.gateway.auth] |
exit 0, silent |
Why this seems worth a signal
v0.1.6 added the refusal to start without OIDC, mTLS user, operator auth, or gateway JWTs (#4814 — thank you, it is a real hardening over 0.1.5's warn-only behaviour). allow_unauthenticated_users is documented as the escape hatch for "trusted local development only", and that is a reasonable thing to provide.
The gap is that preflight is the tool an operator reaches for before starting the service, and it gives the same silent exit 0 for a correctly-authenticated configuration and for one that has opted out of authentication entirely. With the Docker compute driver the gateway holds a socket that is root-equivalent on its host, so the difference between those two configurations is not a small one.
Suggestion
A warning rather than a failure would fit the stated purpose: the switch is deliberate and documented, so failing preflight on it would break the development workflow it exists for. Something like
warning: allow_unauthenticated_users = true — inbound authentication is disabled
(documented for trusted local development only)
would mean an operator who ran preflight cannot have missed it, and exit 0 would still hold for anyone who meant it. A --strict mode that failed on it would also work, if that fits the CLI's conventions better.
Related
- feat(gateway): refuse to start without user authentication unless allow_unauthenticated_users is set #4814 introduced the refusal this switch opts out of.
- config preflight should name the offending key and flag unusable launch-signing setups #3959 reports adjacent preflight gaps on 0.1.2 — preflight not naming the offending key, and exit 0 on a configuration whose
CreateSandboxcalls then fail. That issue is about configurations that are invalid but unreported; this one is about a configuration that is valid but unsafe, which is why it is filed separately rather than as a comment there.
Happy to re-measure on a newer release if that is useful.
Activity