rbac bootstrap job sends rootUrl "https:" on zero-config deploys and fails with KC 400

[dcmcand]

What happened

On a zero-config deploy (only keycloak.hostname set, nebariapp.hostname left empty per the documented convention), the rbac-bootstrap job fails:

INFO reconciling hub client URLs (rootUrl='https:', baseUrl='/hub', initiate.login.uri='https:/hub/oauth_login')
ERROR KC PUT .../admin/realms/nebari/clients/<uuid> -> HTTP 400: {"error":"invalid_input","error_description":"Root URL is not a valid URL"}

Why

templates/keycloak-rbac-bootstrap-job.yaml defaults HUB_EXTERNAL_URL with:

value: {{ .Values.rbac.bootstrap.hubExternalUrl | default (printf "https://%s" .Values.nebariapp.hostname) | quote }}

It reads the raw nebariapp.hostname instead of applying the subdomain derivation the NebariApp template uses, so an empty hostname renders https:// rather than the derived hub.<base-domain>.

The script's if not hub_external_url guard doesn't trip because the value is non-empty, and since the URL patch runs before step 3, the job dies before binding the realm-management roles to the hub service account. The visible symptom downstream is the hub logging 403 GET .../admin/realms/<realm>/clients on every login, so role-gated profiles and shared-mount RBAC silently degrade.

Environment

• nebari-data-science-pack 0.1.0-alpha.16
• codecentric keycloakx 7.1.6, nebari-operator 0.1.0-alpha.20
• Deployed via ArgoCD on a NIC-provisioned EKS cluster

Workaround

Set nebariapp.hostname explicitly. The fix is presumably reusing the same derivation helper the NebariApp template uses (or falling back to the derived hostname in the printf), and arguably the script should also reject a scheme-only URL before sending it to Keycloak.

Related: #76 covers a similar raw-vs-derived problem with hubClientId.