Security(H-02): chart fails open to DummyAuthenticator when OAuth URLs/config mount are absent

Summary

The chart defaults to DummyAuthenticator, which accepts any username with any password. The custom auth module only replaces it when OAuth URLs resolve, so a missing hostname, a missing OAuth secret mount, or a values override that drops the config mount silently leaves the hub on dummy auth. Because home volumes are named claim-{username}, an attacker who supplies a victim's username can attach the victim's persistent volume.

Severity: High · CWE-306 (Missing Authentication for Critical Function)
Validation: Confirmed against HEAD f932d80 on 2026-07-14 (assessed at 69c84f7; unchanged since).

Evidence

• values.yaml:527-532 sets admin_access: true and authenticator_class: dummy. With no password configured, dummy auth admits any username/password pair.
• config/jupyterhub/00-gateway-auth.py:595-652: production wiring runs only when _resolve_oauth_urls() returns non-None (chart-substituted callback URL or OAUTH_CALLBACK_URL). When it returns None, configure() is never called and the dummy default stands. The comment at 00-gateway-auth.py:611-615 documents this intentionally.
• values.yaml:562-565 warns that z2jh treats extraVolumes/extraVolumeMounts as REPLACE (not merge). An override that drops the custom-config mount (values.yaml:570-584) leaves jupyterhub_config.d/ empty, so 00-gateway-auth.py never loads and dummy remains.
• The spawner names home volumes claim-{username} (config/jupyterhub/01-spawner.py, PVC naming), so identity and storage selection both derive from the dummy username.

Impact

When the fallback is reachable, an attacker submits a victim's username and any password, is accepted as that hub user, and mounts claim-victim. That exposes notebooks, source, data, shell startup files, SSH material, and any user-persisted credentials. Selecting an admin account may also grant admin hub authority. This is a fail-open posture: a configuration omission degrades to unauthenticated-equivalent access instead of failing closed.

Related behavior is discussed in #133 (hub currently crash-loops on a missing /etc/oauth secret rather than falling back), which notes that dummy-auth fallback "risks briefly exposing a dummy-auth hub on a real deployment."

Remediation

• Remove DummyAuthenticator from production defaults; keep it only in an explicit dev values file that is never externally routed.
• Fail Helm rendering or hub startup when production mode lacks a real authenticator.
• Make the required config and OAuth secret mounts non-optional.
• Add schema validation so list-replacement cannot remove security-critical mounts.
• Reject DummyAuthenticator at startup unless an explicit unsafe-dev flag is set.

Acceptance criteria

• A default render cannot start with DummyAuthenticator.
• Omitting the config mount or OAuth material fails closed.
• Arbitrary username/password login fails in every routable profile.
• A victim username cannot attach the victim's PVC without a valid IdP session.

Related

• #133 (missing OAuth secret / dummy fallback behavior)

_{Source: data-science-pack 0.1.0 security assessment (pinned commit 69c84f72df259ec755ed40bfc83f20158c550d55), finding H-02.}

Start with values.yaml:527-584 and config/jupyterhub/00-gateway-auth.py:595-652, then inspect the chart’s default render and startup path. Verify that missing OAuth material or the custom-config mount cannot leave DummyAuthenticator active, and use the acceptance criteria to confirm default renders, routable profiles, login behavior, and PVC access fail closed.