Hands-On with Entra ID SSO for Kubernetes: OIDC and Group-Based RBAC on kubeadm

A person joins a project. They get access to the application through Entra ID, and that part is a single onboarding step. Then they ask for access to the Kubernetes cluster that runs on an on-prem server, and a second onboarding starts. Someone creates a client certificate, or hands over a shared admin kubeconfig, or creates a ServiceAccount token for them. That second path lives outside the identity system, so nobody reviews it, nobody expires it, and nobody remembers it when the person leaves.

The consequences are easy to predict. Leavers keep cluster access. The audit log shows a shared identity such as kubernetes-admin instead of a person. Laptops hold credentials that stay valid for a year or more.

This lab removes the second path. The Kubernetes API server trusts Entra ID as an OpenID Connect (OIDC) provider. Users sign in with their normal Entra account (and MFA), and Kubernetes RBAC is bound to Entra group object IDs. Adding someone to a group gives them cluster access, and removing them takes it away. No Kubernetes user is ever created.

To keep the cost low, the cluster is a single kubeadm node on one Linux server, and the identity side runs on the free tier of Microsoft Entra ID. If the server is a local machine, nothing is billed. If you use a cloud VM as a stand-in for the on-prem server, only that VM costs money (see Prerequisites).

• One joiner, mover and leaver process. Entra ID already knows who is on the team. Cluster access should follow that record and not a separate spreadsheet of certificates.
• Named identities in the audit trail. When a pod is deleted at 02:00, the API server audit log should show which person did it. A shared admin certificate cannot answer that question.
• No long-lived credentials on laptops. The kubeadm admin kubeconfig holds a client certificate that lasts a year. OIDC tokens last about an hour.
• Least privilege that people can read. A group called k8s-lab-developers bound to the edit role in one namespace is something a reviewer understands in ten seconds.
• MFA comes with the identity provider. The cluster does not need its own MFA. Whatever Entra enforces at sign-in applies to kubectl too.
• Evidence for reviews. Auditors in EU organisations ask who can reach production, how access is removed and where the logs are. This setup gives a direct answer to each.

• You run Kubernetes yourself (on-prem, edge, a private datacenter, a distribution that has no cloud-provider integration) and your company already uses Entra ID for its workforce.
• More than two or three people need cluster access, and the shared admin kubeconfig has started to circulate.
• An audit or security review flagged shared cluster-admin credentials or missing leaver controls.
• You need to answer "who changed this" from the Kubernetes audit log.
• You want one place to switch off a person's access during offboarding.