[TaylorMutch]

Summary

Reject gateway startup when no OIDC issuer, mTLS user authentication, operator authentication, or gateway JWTs are configured unless unauthenticated users are explicitly allowed. The configuration error appears before tracing services and listeners start and includes the supported authentication options and development opt-in.

Related Issue

Closes #4814

Changes

• Validate the effective authentication configuration before starting gateway services.
• Preserve the explicit development opt-in, its warning, and configured authentication behavior.
• Reject requests without credentials when no authenticator chain is configured unless development access is explicitly enabled; cover operator-only authentication at the router and real TLS boundaries.
• Cover all 32 authentication/opt-in combinations and exercise startup with the opt-in omitted and explicitly false.
• Document the startup requirement and update gateway troubleshooting guidance.

Release Notes

Gateways without OIDC, mTLS user or operator authentication, or gateway JWTs now refuse to start. For trusted local development, explicitly set allow_unauthenticated_users = true under [openshell.gateway.auth].

Testing

• Checks appropriate to the affected code and behavior pass
• Unit tests added/updated
• E2E tests added/updated

Passed:

• cargo test --offline --locked -p openshell-server --features test-support --lib: 2,371 passed, 21 ignored, including operator-only router and real TLS regression coverage.
• cargo clippy --locked -p openshell-server --features test-support --all-targets -- -D warnings
• cargo fmt -p openshell-server -- --check
• mise run docs: no errors; three Fern warnings.
• Markdown lint and git diff --check.

Full deployment e2e suites have not been run. Inspected the dev task, Docker Compose, Helm CI, and Docker/Podman e2e configurations: they already opt into unauthenticated users or configure gateway JWTs. This draft leaves deployment e2e validation outstanding.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Configuration documentation updated

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[github-actions]

🌿 Preview your docs: https://nvidia-preview-pr-4821.docs.buildwithfern.com/openshell

[github-actions]

Compatibility review (advisory)

New or updated breaking changes; see the full report for all findings.

1. configuration — No explicit risk acceptance found

Without OIDC, mTLS user/operator authentication, or configured/discovered gateway JWTs, openshell-gateway previously warned and started but now rejects startup when allow_unauthenticated_users is omitted or false.

• Impact: Existing local-development and trusted-proxy deployments using those configurations now exit with 'gateway has no user authentication configured' before binding ports, leaving CLI and SDK clients unable to connect.
• Action: Preserve startup compatibility for existing configurations in v0.1.6 and defer the mandatory authentication or explicit opt-in requirement to a minor release with the documented migration.
• PR: fix(gateway): require authentication or explicit development opt-in #4821

Review details

• Execution: complete
• Candidate: PR #4821 (6323b2971ceca1e4e913f531e3b5adddb406bbe4)
• Baseline: 029fda684da8efc4772a526288038705ee9d148d (029fda684da8efc4772a526288038705ee9d148d)
• Reviewed: rust-sdk, python-sdk, go-sdk, typescript-sdk, api-behavior, cli, configuration, policy, helm, state

Advisory review; publication gates are unchanged.

Branch check run

[github-actions]

Label test:e2e applied for b8c6ee6. Open the existing run and click Re-run all jobs to execute with the label set. The run will execute the standard E2E suite after building the required gateway, sandbox, and supervisor images once. The matching required CI gate status on this PR will flip green automatically once the run finishes.

[TaylorMutch]

We acknowledge this is a change but it fixes a bug and guides users towards the proper UX for configuring auth.

[mrunalp]

The operator-only exemption in validate_user_auth leaves one case of implicit admin access open. With no OIDC or configured/discovered gateway JWTs, this configuration passes the new startup check:

[openshell.gateway.auth]
allow_unauthenticated_users = false

[openshell.gateway.mtls_auth]
enabled = false
operator_enabled = true

Client certificates remain optional at the TLS layer. For a caller without a certificate, no operator principal is created and build_authenticator_chain returns None. With user mTLS disabled and unauthenticated access false, the final branch in AuthGrpcRouter::call still supplies unauthenticated_dev_user_principal(), granting openshell-admin and openshell:all.

This exposure exists on the PR base too; the concern is that the new validation explicitly accepts a configuration that still allows it. Could we reject credential-less requests in the no-chain fallback unless allow_unauthenticated_users is true, and add an operator-only request test?

I reproduced this at b8c6ee6 with a temporary router regression test: a credential-less ListSandboxes request reached the handler as unauthenticated-local-dev instead of returning Unauthenticated. Both new PR tests passed in the same focused run.