Skip to content

rbac.bootstrap.hubClientId derivation uses literal "jupyterhub-" prefix; should use .Release.Namespace #76

Description

@viniciusdc

Problem

After PR #74 flipped rbac.bootstrap.enabled: true as the chart default, the post-install/upgrade RBAC bootstrap Job started failing on real deployments with:

==> 2. hub OIDC client + service account
Traceback (most recent call last):
  File "/scripts/keycloak_rbac_bootstrap.py", line 521, in <module>
    sys.exit(main())
  File "/scripts/keycloak_rbac_bootstrap.py", line 265, in get_client_uuid
    raise RuntimeError(
RuntimeError: client 'jupyterhub-data-science-pack-nebari-data-science-pack' not found in realm 'nebari'

Root cause

The chart's values.yaml documents the auto-derive behavior:

ClientId of the hub OAuth client in Keycloak (created by the nebari-operator NebariApp). Leave empty to derive from the release + chart name (the operator's standard pattern: jupyterhub-<release>-<chart>). Override for non-standard client ids.

That assumption doesn't match the operator. nebari-operator actually builds the client id as <namespace>-<release>-<chart> — it uses the NebariApp's namespace as the prefix, not the literal string jupyterhub. So for a release data-science-pack of chart nebari-data-science-pack in namespace nebari-system, the operator provisions:

nebari-system-data-science-pack-nebari-data-science-pack

…but the chart's auto-derive produces:

jupyterhub-data-science-pack-nebari-data-science-pack

The two only agree when the NebariApp lives in a namespace literally named jupyterhub, which I'd guess only matches local-dev k3d clusters (which is plausibly where the assumption was first formed).

Fix

Replace the literal in the derivation with .Release.Namespace. Concretely in templates/keycloak-rbac-bootstrap-job.yaml (and any helper that owns the derivation):

- name: HUB_CLIENT_ID
  value: {{ default (printf "%s-%s-%s" .Release.Namespace .Release.Name .Chart.Name) .Values.rbac.bootstrap.hubClientId | quote }}

…and update the values.yaml comment to say "derive from .Release.Namespace-.Release.Name-.Chart.Name (the operator's standard pattern)".

Cluster impact (real deployment hitting this)

NIC's Hetzner cluster sync moved past e987b6d (alpha.12) to the merged PR #74 (0cdf3f2). The RBAC Job failed every post-sync run with the error above until we explicitly set rbac.bootstrap.hubClientId to the operator-provisioned name in deployment-level values (see openteams-ai/nic-deploy#12 for the workaround).

Every deployment using nebari-operator + a namespace that isn't named jupyterhub will hit this on first chart sync after the default flipped.

Related upstream change request

Even with this fix, the chart's RBAC Job is a workaround for a CRD gap on the operator side — NebariApp.auth.keycloakConfig supports groups and protocol mappers but not client roles. Tracked at nebari-dev/nebari-operator#119. Once that lands, the whole Job can go.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    Priority

    None yet

    Start date

    None yet

    Target date

    None yet

    Size

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions