Identity API is tied to kubauth and does not work with the official Keycloak sandbox

[alex-mabrouk]

Describe the Bug

While working with the new control-plane server on the official sandbox, I noticed that the Identity API (/api/v1/identity/*) cannot work there.

The sandbox now uses Keycloak through the generic defaultIdp OIDC configuration, and kubauth is not installed on it. Authentication works fine for the different services because they only rely on standard OIDC.

The Identity API is different: its implementation is built directly on top of the kubauth CRDs (User, Group and GroupBinding), and even the IdentityRepository interface exposes these CRD types in its public methods (CreateUser(ctx, *crd.User), etc.). Since those CRDs do not exist on the sandbox cluster, every Identity endpoint returns a 500.

Steps to Reproduce

1. Deploy the official sandbox (OKDP/okdp-sandbox, clusters/sandbox/) ; Keycloak is the identity provider, kubauth is not installed.
2. Run the control-plane server against that cluster.
3. Call any Identity endpoint, e.g.:
   curl http://localhost:8093/api/v1/identity/users
4. Optionally confirm the CRDs are absent:
   kubectl get crd | grep kubauth → no results.

Expected Behavior

The Identity API should either work against the configured identity provider (the sandbox uses Keycloak), or not be exposed when it cannot be supported.

Actual Behavior

All /api/v1/identity/* endpoints return 500: the server tries to read/write kubauth.kubotal.io/v1alpha1 CRDs that do not exist on the cluster.

Environment

Kubernetes version

Details

$ kubectl version
Client Version: v1.36.2
Kustomize Version: v5.8.1
Server Version: v1.34.0
Warning: version difference between client (1.36) and server (1.34) exceeds the supported minor version skew of +/-1

Helm version

Details

$ helm version
version.BuildInfo{Version:"v4.2.2", GitCommit:"b05881cf967a5a09e19866799d0edfd40675803a", GitTreeState:"clean", GoVersion:"go1.26.4", KubeClientVersion:"v1.36"}

Chart / component version:

Cluster setup (Kind version, node count, any custom config):
kind version
kind v0.30.0 go1.24.6 linux/amd64

Logs

Client side:


$ curl -i http://localhost:8093/api/v1/identity/users
HTTP/1.1 500 Internal Server Error
{"error":"the server could not find the requested resource"}

$ curl -i http://localhost:8093/api/v1/identity/groups
HTTP/1.1 500 Internal Server Error
{"error":"the server could not find the requested resource"}

$ kubectl get crd | grep kubauth
(no results)


Server side:


time="2026-07-15T09:09:31Z" level=error msg="Failed to list users" error="the server could not find the requested resource"
time="2026-07-15T09:09:31Z" level=error msg="Internal Server Error" duration=11.92726ms ip="::1" latency=11.92726ms method=GET path=/api/v1/identity/users status=500
time="2026-07-15T09:09:31Z" level=error msg="Failed to list groups" error="the server could not find the requested resource"
time="2026-07-15T09:09:31Z" level=error msg="Internal Server Error" duration=1.578151ms ip="::1" latency=1.578151ms method=GET path=/api/v1/identity/groups status=500

Anything else we need to know?

This made me wonder whether this feature still belongs in the core server, so this issue is as much a design question as a bug report.

From what I understand, in most production environments users and groups already come from an existing corporate identity provider (Entra ID, LDAP/AD, Okta, Keycloak, ...). The platform authenticates against that provider, but it usually does not own the lifecycle of human identities. The sandbox follows the same approach: users, roles and clients are seeded declaratively through the Keycloak configuration.

Possible directions:

1. Make the Identity API provider-neutral (an abstraction with one adapter per identity provider).
2. Keep user and group management outside the core server, and let administrators manage identities directly in their identity provider (or declaratively for kubauth/Keycloak).
3. Keep the current API, but clearly define it as a kubauth-specific feature rather than part of the provider-neutral core.

For me the first question is simply: should managing human users and groups be a responsibility of the OKDP control-plane at all? Agreeing on that point first will make it much easier to decide what should happen to the current implementation.

[mlahouar]

Thanks for the detailed analysis, this matches the direction I have in mind for identity. The default path should be bring your own OIDC provider: the control plane only assumes a standard issuer (issuer URL, client, groups claim, all from config), and the test you ran on the official OKDP sandbox (Keycloak) proves exactly that.

kubauth remains valuable as a fallback: local users and groups for platforms that do not control their corporate OIDC server, and a fast time to market (you can stand up an operational platform right away instead of waiting weeks for a client on the corporate IdP, then switch later). But the recommended path stays bring your own OIDC, and kubauth should never be a hard dependency.

On the Identity API itself: I would drive it from the platform configuration: the identity section is enabled when the platform is configured with kubauth, and cleanly disabled otherwise (endpoints off, UI hiding identity management). With an external IdP, users and groups are managed in the IdP, not by the control plane.

A short design note before implementation would be welcome.

[alex-mabrouk]

Thanks, this makes the intended direction much clearer.

I hadn't given enough weight to the fallback use case (local users/groups for a self-contained platform before a corporate IdP is available), and I think keeping kubauth for that scenario makes sense.

My understanding is now:

• External OIDC is the default path.
• Kubauth remains an optional identity provider when the platform needs to manage its own users and groups.
• The Identity API and UI are only available in that mode, and are hidden otherwise.

The only point I'd like to keep separate is OIDC client provisioning, since it solves a different problem (registering clients for services rather than managing human identities).

I already have a working Keycloak implementation for that, validated against the sandbox, so I'll include it as a separate section in the design note rather than mixing it with the identity model.

I'll write a short design proposal based on this and share it before starting the implementation.