feat(hub): extend trust-bundle mechanism to the hub pod

[oren-openteams]

Closes #159.

Summary

Extends the chart's existing enterprise CA bundle mechanism (custom.trust-bundle-enabled + _setup_trust_bundle in 01-spawner.py) to also cover the hub pod. The singleuser side was already thorough; the hub was the last gap.

Before this PR, outbound HTTPS from the hub to any TLS-inspected external endpoint (external Keycloak URL, oauthenticator refresh, jhub-apps configuration fetches) had no way to trust the org CA short of overriding the entire authenticator via hub.extraConfig.

Changes

values.yaml jupyterhub.hub.*:

• extraVolumes — adds org-ca (ConfigMap, optional: true) + ca-merged (emptyDir). Same names as the singleuser side.
• extraVolumeMounts — adds ca-merged at /etc/ssl/certs-extra, matching the singleuser path.
• initContainers — new merge-ca-bundle container. Copies the image's system CA into the emptyDir, then appends the org CA IFF /org-ca/<key> exists (so missing trust-manager is a no-op). Uses the hub image so the system CA store the init container reads matches what the hub container has at runtime.
• extraEnv — adds all five CA env vars pointing at the merged file: REQUESTS_CA_BUNDLE, SSL_CERT_FILE, NODE_EXTRA_CA_CERTS, CURL_CA_BUNDLE, GIT_SSL_CAINFO. Rust tooling (rustls-native-certs) honours SSL_CERT_FILE but does not iterate SSL_CERT_DIR, so the explicit file path is required.

Also updates the trust-bundle-enabled docstring to describe the hub-side wiring and cross-references the two places that now consume trust-bundle-configmap/trust-bundle-key.

Design note — unconditional on the hub

Unlike the singleuser side (gated at spawn time by custom.trust-bundle-enabled via a Python hook), the hub-side wiring is unconditional. z2jh renders the hub Deployment from static values, so runtime gating isn't available without a chart-side helper (which would require the chart to interpose on how values reach z2jh).

optional: true on the ConfigMap and the [ -f ... ] guard on the shell append make the always-on wiring functionally identical to the singleuser disabled path on clusters without trust-manager — merged bundle equals system bundle, env vars point at a file that matches the system trust store, no behaviour change. Costs one extra init container run per hub pod start (< 1s wall-clock on typical images).

Deployers who need to opt out entirely can override hub.extraVolumes etc. in their own values, subject to the existing warning about re-including the pre-existing chart entries.

Follow-up work worth flagging

custom.trust-bundle-configmap and custom.trust-bundle-key now drive TWO sites (singleuser Python hook reads them at runtime; hub-side static YAML references the same default explicitly). Changing them requires editing values in two places until a chart helper binds them. Kept the duplication out of scope for this PR to keep the diff surgical, but happy to add the helper in a follow-up if reviewers prefer.

Tests

tests/unit/test_hub_ca_bundle.py — 12 assertions pinning the shape of the jupyterhub.hub.* block:

• extraVolumes contains org-ca (optional ConfigMap) + ca-merged (emptyDir); preserves the two pre-existing chart entries (custom-config, oauth-client)
• extraVolumeMounts exposes ca-merged at /etc/ssl/certs-extra; preserves pre-existing entries
• initContainers has merge-ca-bundle; it uses the hub image; the shell command copies system CA and conditionally appends org CA; volume mounts are wired correctly
• extraEnv sets all five CA env vars to the merged bundle path; preserves the existing OIDC-client-secret entry
• Cross-cutting: the hub-side org-ca ConfigMap name matches the default custom.trust-bundle-configmap value (drift detector)

Runs standalone (pyyaml + pytest only, no chart deps):

$ python -m pytest tests/unit/test_hub_ca_bundle.py -v
=============== 12 passed in 0.21s ===============

Verification

Not deployed end-to-end yet — will be validated as part of the downstream deploy that motivated this. Change is declarative YAML plus a values-shape unit test; the maintainers' existing CI (helm lint / chart-render) should cover the rest. Happy to iterate if anything doesn't render cleanly.

[oren-openteams]

Verified end-to-end on a private-VPC dev cluster.

The daa32b9 init-container fix was necessary — without it kubelet refuses to start merge-ca-bundle with container has runAsNonRoot and image will run as root, because z2jh sets a pod-level runAsNonRoot: true without an explicit uid and the hub image's default USER is root. Pod sits at Init:CreateContainerConfigError indefinitely with no logs from the init container itself — the CI failure surfaced it via hub_login_page timing out for 5 min waiting on the pod. Local kind reproduce confirmed the kubelet event. Fix mirrors what the hub container itself declares (runAsUser: 1000, runAsGroup: 1000, allowPrivilegeEscalation: false, capabilities.drop: [ALL]) so ownership on the shared ca-merged emptyDir stays coherent.

Post-fix: all 14 CI checks green (including the previously-failing e2e shared-storage suite and hub_login_page), and on the real cluster:

• Init container completes cleanly, hub pod goes Ready
• /etc/ssl/certs-extra/ca-bundle.crt in the hub contains both the system CAs and the org CA
• Outbound HTTPS from the hub to the TLS-inspected external Keycloak URL validates cleanly for the first time (previously required a hub.extraConfig override with hard-coded in-cluster URLs to sidestep the CA trust gap)

One minor documentation note worth flagging: on deploys where the target trust-manager Bundle uses a different key than the chart default (ca-certificates.crt vs, e.g., ca-bundle.crt), the init container's shell script needs the key updated too — the custom.trust-bundle-key value only drives the singleuser side (the "duplication out of scope" note in the PR body). Not a blocker; something reviewers might want to keep in mind for a follow-up bind helper.