This architecture page shows a practical proof-of-concept for enterprise Kubernetes RBAC using corporate LDAP or Active Directory. The recommended pattern is LDAP-backed identity into an OIDC broker such as Keycloak or Dex, then group claims into the Kubernetes API server, then namespace-aware RBAC with `RoleBinding` and `ClusterRoleBinding`.
Visual representation of the complete authentication and authorization flow.
A realistic POC has five layers.
Existing source of truth for people and groups.
Looks up users and groups from LDAP.
Trusts the OIDC issuer and validates tokens.
Maps users and groups to permissions.
Final access target for teams and administrators.
Choose a view to focus on authentication, group resolution, RBAC decisions, or day-2 operations.
The enterprise password stays in the directory layer. Kubernetes never stores or validates the LDAP password itself.
This is the normalization step. Directory groups become portable claims that Kubernetes RBAC can match.
Once the token is trusted, authorization is completely native Kubernetes behavior.
This is what makes the model scalable for enterprises: add people to groups, not one-off Kubernetes users.
A clean POC uses group-based access instead of individual user bindings wherever possible.
Lets developers create and update Deployments, Services, Pods, and ConfigMaps in the development namespace only.
Supports release validation, log access, and controlled rollout visibility for the QA namespace.
Allows rollout inspection, pod restart, and incident triage while keeping broad admin actions tightly constrained.
Reserved for platform engineers who manage namespaces, nodes, storage, policy, and observability.
This split makes the group-to-namespace intent obvious during demos.
`RoleBinding` subjects: `k8s-dev`, optionally named users for exceptions. Supports build, deploy, and debug workflows.
`RoleBinding` subjects: `k8s-qa`, release coordinators, and read-only observers.
`RoleBinding` subjects: `k8s-prod-ops`. Avoid broad write access for normal developer groups here.
`ClusterRoleBinding` subjects: `k8s-admins`. Use a custom ClusterRole if full `cluster-admin` is too wide.
These steps are ordered to make the exercise demonstrable with minimal moving parts.
Create or identify LDAP groups such as `k8s-dev`, `k8s-qa`, and `k8s-admins`, then add test users.
Point Dex or Keycloak at the LDAP server and define bind, search base, and group claim settings.
Set issuer URL, client ID, username claim, groups claim, and CA trust.
Bind groups, not individual users, unless you are proving an exception path.
Use one user from each group, acquire a token, and confirm the identity and groups are visible to Kubernetes.
Show that users can act only in their mapped namespaces, and that cross-namespace operations are rejected.
These samples are intentionally generic so you can adapt them to Dex, Keycloak, or a similar OIDC bridge.
The API server must trust the issuer and know which claims represent the user and groups.
--oidc-issuer-url=https://sso.example.com/realms/k8s --oidc-client-id=kubernetes --oidc-username-claim=email --oidc-groups-claim=groups --oidc-ca-file=/etc/kubernetes/pki/oidc-ca.crt
This is the core pattern for namespace delegation from enterprise groups.
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: dev-team-binding namespace: dev subjects: - kind: Group name: k8s-dev apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: developer-role apiGroup: rbac.authorization.k8s.io
Use sparingly in the POC, or replace with a narrower custom ClusterRole.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: platform-admins subjects: - kind: Group name: k8s-admins apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: cluster-admin apiGroup: rbac.authorization.k8s.io
Use one user per group and test across namespaces to prove isolation.
kubectl auth can-i create deployment -n dev kubectl auth can-i get pods -n qa kubectl auth can-i delete namespace prod kubectl get pods -n prod
If the exercise is for human enterprise users, an OIDC bridge is usually the cleanest pattern. Direct client certificates for every employee do not scale well for joiner-mover-leaver processes, group management, or self-service governance.