dev: Keycloak realm user `admin` collides with Harbor's built-in `admin`, so the documented SSO login never onboards

Context

Following the README's "Full Keycloak SSO — make up-sso" flow, clicking Login with Keycloak in Harbor and signing in as the documented realm user (admin / nebari-admin, realm nebari) fails at the OIDC callback with:

{"errors":[{"code":"UNKNOWN","message":"failed to create user record: user admin or email admin@nebari.local already exists"}]}

Harbor already has a built-in local-DB user named admin (the harborAdminPassword account). The operator dev stack's keycloak/setup.sh creates the realm user with the same username, so Harbor's OIDC auto-onboard (oidc_auto_onboard=true, oidc_user_claim=preferred_username) refuses to create a second admin. As far as I can tell the documented SSO login path cannot ever have worked; the SSO wiring itself (redirect, issuer, callback) is fine.

Environment

• harbor-pack main @ 877dbab, dev/make up-sso + make host-access
• kind on Colima (macOS arm64), nebari-operator v0.1.0-alpha.19
• Harbor 2.15.1 (chart 1.19.1), OIDC-setup Job completed, auth_mode=oidc_auth

Steps to reproduce

1. cd dev && make up-sso && make host-access, add the /etc/hosts line.
2. Open https://harbor.nebari.local → Login with Keycloak.
3. Sign in as admin / nebari-admin.
4. Harbor returns the JSON error above instead of onboarding the user.

Workaround — create a differently-named user in the nebari realm via kcadm in the Keycloak pod and log in as that user:

kc() { kubectl exec -n keycloak keycloak-keycloakx-0 -- /opt/keycloak/bin/kcadm.sh "$@"; }
kc config credentials --server http://localhost:8080/auth --realm master --user admin --password admin
kc create users -r nebari -s username=dev -s email=dev@nebari.local -s firstName=Dev -s lastName=User -s enabled=true -s emailVerified=true
kc set-password -r nebari --username dev --new-password dev-password

That user onboards fine. It is not a Harbor system admin (no oidcSetup.adminGroup is set by default), so projects have to be created via Login via Local DB as admin / Harbor12345, or by granting the user sysadmin through the API.

Value and/or benefit

The README's SSO quick start works as written. Any of these would do it:

• Have enable-sso.sh seed a non-admin realm user (e.g. dev) and print that as the login, rather than the operator's realm admin. I have a dev/seed-user.sh (idempotent kcadm user create + password) and dev/harbor-bootstrap.sh (grant sysadmin, create a project, add the user as project admin, print the nebi registry add line) that I can send as a PR if that shape is acceptable.
• Or set oidcSetup.adminGroup in the dev flow to a group the seeded user belongs to, so the first SSO login is a Harbor admin and the Local-DB fallback isn't needed.
• Update the README's "Keycloak user admin / nebari-admin" line accordingly, and note that a Keycloak pod restart wipes the seeded user along with the realm.

Anything else?

Two smaller things noticed on the same run, happy to split out:

• _metallb's kubectl wait --timeout=90s is tight for a first-time image pull.
• The cluster target skips setup entirely when the kind cluster already exists, so a failure partway through _cluster-create leaves a half-built cluster that a re-run of make up-sso silently reuses. Re-running the individual _metallb / _services / _keycloak-setup / _operator targets recovers, but that isn't documented.
• On Colima, Docker handed the kind network 192.168.1.0/24 (overlapping the LAN), which makes every pod's call to the API server time out. Pre-creating the network with a 172.x subnet fixes it; a one-line note in "Local dev on kind" would save the next person an hour.

Read the README's “Full Keycloak SSO” flow and dev/keycloak/setup.sh, then run make up-sso to reproduce the callback failure. Trace the documented realm-user credentials and the OIDC onboarding settings; done means the documented login creates a Harbor user without colliding with the local admin and the README matches the seeded credentials.