Skip to content

fix(rbac): read hub client id from operator OIDC secret#157

Open
aktech wants to merge 2 commits into
mainfrom
worktree-issue-135-rbac-hub-client-id
Open

fix(rbac): read hub client id from operator OIDC secret#157
aktech wants to merge 2 commits into
mainfrom
worktree-issue-135-rbac-hub-client-id

Conversation

@aktech

@aktech aktech commented Jul 9, 2026

Copy link
Copy Markdown
Member

The RBAC bootstrap job derived the hub client id from the jupyterhub-<release>-<chart> convention and failed with "client not found" on operators that name clients differently. The job now reads client-id from the operator-provisioned <fullname>-oidc-client Secret (via the K8s API, with a ServiceAccount + single-secret Role, polling while the operator provisions). rbac.bootstrap.hubClientId still overrides.

Closes #135

Bootstrap job derived the id as jupyterhub-<release>-<chart>, but
operator releases use other naming conventions, failing the job with
"client not found". Read the client-id key from the operator-provisioned
<fullname>-oidc-client Secret instead (the same source the hub mounts at
/etc/oauth), polling while the operator is still provisioning. Explicit
rbac.bootstrap.hubClientId still wins and skips the read. The job gets a
ServiceAccount plus a get-one-secret Role in the release namespace since
it runs in the keycloak namespace.

Closes #135
@aktech aktech requested a review from pmeier as a code owner July 9, 2026 13:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

RBAC bootstrap job derives hub OIDC client id instead of reading it from the operator, breaking on operators that use a different naming convention

2 participants