Data Flow: Authentication & Authorization

Purpose: For platform engineers, explains how user identity flows from Keycloak through OIDC to Kubernetes RBAC.

Flow Summary

Components

Component	Namespace	Role
Microsoft Entra ID / AD / LDAP	External	Upstream identity source — stores users and groups
Keycloak	keycloak	Identity broker — federates upstream IdPs, issues JWTs
PostgreSQL	keycloak	Stores Keycloak realm configuration and user data
RBAC Manager	rbac-manager	Watches group claims, creates/updates RoleBindings
RBACDefinitions	rbac-manager	CRDs mapping OIDC groups to ClusterRoles
API Server	kube-system	Validates JWT tokens, enforces RBAC

Sequence

1. User initiates login (kubectl, Headlamp UI, or CLI) — redirected to Keycloak.
2. Keycloak redirects to the configured upstream IdP (Microsoft Entra ID, Active Directory via LDAP, or other SAML/OIDC provider).
3. User authenticates against the upstream IdP; group memberships are returned to Keycloak.
4. Keycloak maps upstream groups to local realm groups and issues a JWT containing the groups claim.
5. Client presents the JWT to the Kubernetes API server.
6. API server validates the token signature against Keycloak's OIDC discovery endpoint.
7. API server extracts the groups claim from the token.
8. RBAC Manager has pre-created RoleBindings based on RBACDefinition CRDs that map groups to ClusterRoles.
9. API server evaluates the request against the user's RoleBindings — allow or deny.

Group-to-Role Mapping

OIDC Group	ClusterRole	Access
cluster-admins	cluster-admin	Full cluster access
viewers	view	Read-only across all namespaces

Additional mappings are defined via RBACDefinition custom resources and reconciled by RBAC Manager.

Related

• Logical Diagram — full cluster architecture