sharedStorage.groups allowlist rendered in values but not consumed by chart templates

Summary

sharedStorage.groups in values.yaml is documented as an allowlist that limits which Keycloak groups get a /shared/<group>/ directory mounted, but nothing in the chart templates wires it into the config the spawner actually reads. It's dead config at every released version and on main.

Repro

1. Deploy data-science-pack (any version through 0.1.1 and current main) with sharedStorage.enabled: true and an explicit allowlist:

   sharedStorage:
     enabled: true
     storageClass: longhorn
     groups:
       - cdao
   

2. Log in as a user whose Keycloak token carries more groups than the allowlist — e.g. [cdao, gpu-access, team-openteams, team-navsea].

3. Spawn a JupyterLab session.

4. ls /shared/ in the notebook.

Expected: cdao only, per the allowlist.
Actual: all four groups from the token — cdao gpu-access team-navsea team-openteams — each with its own directory, writable to members.

Root cause

config/jupyterhub/01-spawner.py reads the allowlist from Jupyter's custom.shared-storage-groups:

shared_storage_groups_allowlist = get_config("custom.shared-storage-groups", [])

But templates/hub-config.yaml only wires sharedStorage.enabled into custom.shared-storage-enabled:

"shared-storage-enabled": {{ ternary "True" "False" .Values.sharedStorage.enabled }},

No line wires .Values.sharedStorage.groups into custom.shared-storage-groups. So shared_storage_groups_allowlist always resolves to the [] default, which is the "no allowlist — mount every group" path.

Traced on main as well, not fixed after 0.1.1.

Docs

The Shared Storage docs page describes the allowlist as functional:

sharedStorage:
  groups: []   # empty = mount every group from the user's Keycloak token

Set an explicit allowlist to limit which Keycloak groups get a shared directory.

That description matches the values schema but does not match runtime behavior.

Proposal

Two acceptable directions:

Option A — wire it up

Add to templates/hub-config.yaml where the other custom.* keys are set:

"shared-storage-groups": {{ .Values.sharedStorage.groups | toJson }},

Docs stay accurate, values.yaml stays as-is, existing values files that already set groups: in anticipation of the allowlist (this is what tripped us up) start working.

Option B — drop the field + update docs

If the intent was always "mount every group from the token, no allowlist," remove groups: from values.yaml, remove the "Scoping which groups get a shared mount" section from the docs, and mention the "every-group" default explicitly.

Option A is what the docs already promise, and the extra flexibility is useful — being able to gate /shared/<group> on things like admins-only or sensitive-project without having to solve it in RBAC is a small win. Happy to open a PR for Option A if that's the preferred direction.

Willing to contribute

Yes — Option A is a one-line template addition + a small unit test that renders the chart with a non-empty groups: and asserts the value shows up in the rendered custom config.

Start in templates/hub-config.yaml and compare its custom keys with config/jupyterhub/01-spawner.py, then inspect the chart's existing unit-test setup. Render the chart with sharedStorage.groups set to cdao and add or adjust a test so the rendered custom config contains the expected value; done when the allowlist reaches the spawner config and tests pass.