NKP login with Microsoft Entra ID: from app registration to group-based access

Summary: the lab’s NKP 2.19 now accepts sign-in with Microsoft Entra ID accounts, and Entra’s sign-in policies, such as MFA, now apply to the dashboard and to kubectl as well. From saving the Identity Provider to the first Entra login took 12 minutes. Access is granted to groups, never to individuals: three Entra groups became three NKP profiles, tested with real users. Ana administers the whole platform, Bruno operates only his workspace’s cluster and Carla works only in the project namespace. A fourth account, with no group, authenticates and sees nothing. Everything worked with Entra ID on the free license. The post shows the configuration on both sides, the right roles for each profile and the best practices that got each one ready.

The result in one table

The local admin and the certificate kubeconfigs kept working throughout the configuration. That’s the emergency (break-glass) access in case the Entra login becomes unavailable.

How identity works in NKP

NKP uses Dex, an OpenID Connect provider that runs only once, on the management cluster. Workload clusters don’t have their own Dex: each one gets a kube-oidc-proxy (for kubectl) and a traefik-forward-auth (for the web UIs), which trust the central Dex.

Three practical consequences:

1. Entra handles authentication (password, MFA, account lockout). NKP handles authorization (what each group can do).
2. The API servers don’t change. I checked in the lab: none of them has --oidc-* flags. OIDC comes in through kube-oidc-proxy, so there’s no control plane restart.
3. In NKP, permissions are granted to groups. The bindings screen itself says so: “Both groups and roles must be defined before setting up cluster role bindings”. The order is always: Entra group → NKP group → role → binding.

What to prepare first

1. The app in Entra ID

NKP needs an app registration in Entra, which becomes Dex’s OIDC “client”.

1. App registrations → New registration: name nkp-dex, Accounts in this organizational directory only.
2. Redirect URI (Web): https://<nkp-address>/dex/callback. In the lab, https://nkp.lab.example.local/dex/callback. The browser resolves the internal name; Entra only requires https.

3. Token configuration:
   • Add groups claim → Security groups, Group ID format in the ID token;
   • Add optional claim (ID token) → email and upn.

4. API permissions → Microsoft Graph, delegated permissions: openid, profile, email, offline_access, User.Read and GroupMember.Read.All. Then Grant admin consent.

5. Certificates & secrets → New client secret. Write down the expiration date and set a reminder 30 days before it.

Write down three values for the next step: the Tenant ID, the app’s Client ID and the Object ID of each group. Entra sends the group’s ID in the token, not its name.

2. Entra ID as the Identity Provider in NKP

In Kommander, logged in as the local admin: Identity Providers → Add Identity Provider → OIDC.

In this screenshot, the Client Secret field got the Entra Secret ID instead of the Value: that’s the detail from the tip in step 1. In the lab, the fix was the Identity Provider’s Edit, which leaves the Client ID and Client Secret fields empty to keep the previous values.

Before saving, check the Redirect URI the form shows: it must be exactly the one registered in the Entra app. If NKP shows an IP and Entra has the name, the login comes back with AADSTS50011.

The full setup in Kommander, in 31 seconds (no audio, identifiers hidden):

The NKP dashboard lives at /dkp/kommander/dashboard. There, the login screen gets the Log in with Entra ID button, next to the local login:

Before	After

The first test is with Eva, who isn’t in any group. She signs in with email and password in Entra and lands back in NKP with “Not Authorized”. That’s the expected result, and it proves the separation: authenticated is not authorized. This test also validates the secret, the redirect and the issuer in one go.

3. The NKP groups: oidc: + Object ID

Identity Providers → Groups → Create Group. For each Entra group, one NKP group with the same name (it stays readable) and, under Identity Provider Groups, the value oidc:<group Object ID>. The oidc: prefix is what NKP adds to groups that arrive through the OIDC connector, and the screen itself points this out.

An NKP group on its own grants no permissions at all. Access comes from the binding, at one of three levels: global (all clusters), workspace (a team’s clusters) or project (a namespace distributed to the workspace’s clusters).

4. Platform admin: Ana

Global Access Control → Cluster Role Bindings → group nkp-plataforma-admins:

• Cluster Admin Role: admin on every managed cluster;
• dkp-kommander-admin: admin of the Kommander dashboard.

The two go together. With only dkp-kommander-admin, Ana got past the dashboard authorization, but the screen stayed blank: the dashboard queries the clusters with the permissions of whoever is logged in, and the role on the clusters was missing. With both, the full dashboard showed up in under 5 minutes, the time it takes NKP to federate the role to the clusters.

Only dkp-kommander-admin	Cluster Admin Role + dkp-kommander-admin

Ana’s sign-in through Entra ID, from the button to the full dashboard (no audio, internal names hidden):

5. Workspace operator: Bruno

Bruno operates the services workspace’s cluster and shouldn’t see the rest of the platform. The binding is on the workspace: workspace selector → Access Control → Cluster Role Bindings → group nkp-servicos-operadores. The first choice was the Workspace Cluster Admin Role + Kommander Workspace Admin Role:

The binding in the dashboard, with that first choice of roles:

In the dashboard, the result was as expected from the very first configuration: Bruno’s workspace selector lists only the services workspace, without Global and without the others.

Bruno’s sign-in, landing straight in his workspace:

In kubectl, the choice of role matters. The workspace role list has about 30 similar names. In NKP 2.19, the default Workspace Cluster Admin Role is an aggregated role: it has no rules of its own and receives those of the roles labeled aggregate-to-cluster-admin. On the cluster, that meant access to the Cluster API resources and the dashboard URLs, but not to the core Kubernetes resources: can-i create deployments returned no and get nodes returned Forbidden. Ana’s global admin role, by contrast, has explicit * rules.

With that default role, Bruno signs in through Entra, but kubectl answers no and Forbidden (recorded before the fix; the kubeconfig commands, which contain the token, were cut):

The solution was a custom Workspace Role, created in the dashboard (Access Control → Roles → Create Role), of type Cluster Role, with two rules: all resources and verbs, and all nonResourceURLs. I named it “Cluster Operator (full)”.

The group’s final binding swapped the Workspace Cluster Admin Role for that role and kept the Kommander Workspace Admin Role (the workspace dashboard). NKP federated the new role to the cluster in under 1 minute:

# node names and Object ID anonymized
$ kubectl auth whoami
ATTRIBUTE   VALUE
Username    [email protected]
Groups      [oidc:<object-id-do-grupo> system:authenticated]
$ kubectl auth can-i create deployments --all-namespaces
yes
$ kubectl get nodes
NAME                              STATUS   ROLES           AGE    VERSION
cluster-servicos-control-plane-1  Ready    control-plane   3d2h   v1.36.2
cluster-servicos-control-plane-2  Ready    control-plane   3d2h   v1.36.2
cluster-servicos-control-plane-3  Ready    control-plane   3d2h   v1.36.2
cluster-servicos-worker-1         Ready    <none>          3d2h   v1.36.2
cluster-servicos-worker-2         Ready    <none>          3d2h   v1.36.2
cluster-servicos-worker-3         Ready    <none>          3d2h   v1.36.2

6. Project developer: Carla

Carla works only in one project’s namespace. In the services workspace: Projects → Create Project (app-demo, placed only on the services cluster). NKP creates the app-demo-mkgxc namespace on the cluster. In the project, the nkp-servicos-devs group gets App Deployer (creates and changes workloads) + Kommander Project Edit (the project in the dashboard).

For a project-only developer to use the dashboard, it takes three bindings, one at each level:

Workspace roles already include the front door; project roles don’t. That’s why, with only the project binding, Carla got “Not Authorized”; with the door but without workspace read access, the screen stayed blank. With all three, she sees the services workspace and her project:

$ kubectl auth can-i create deployments -n app-demo-mkgxc
yes
$ kubectl auth can-i create deployments -n default
no
$ kubectl get nodes
Error from server (Forbidden): nodes is forbidden: User "[email protected]" cannot list resource "nodes" in API group "" at the cluster scope
$ kubectl create deployment podinfo --image=ghcr.io/stefanprodan/podinfo:6.7.1 -n app-demo-mkgxc
deployment.apps/podinfo created
$ kubectl get pods -n app-demo-mkgxc
NAME                       READY   STATUS    RESTARTS   AGE
podinfo-7f5848f5f6-7ztzk   1/1     Running   0          1s

7. kubectl with the Entra login

In the dashboard, the user menu has Generate Token: pick the cluster and copy the commands that build the kubeconfig. The token is issued by Dex with the Entra groups and is valid for 24 hours (in Ana’s token, exp − iat = 86,400 s). The kubeconfig points to the chosen cluster’s kube-oidc-proxy.

Ana’s whole flow, from Generate Token to kubectl get nodes (the kubeconfig commands, which contain the token, were cut):

The numbers

What I learned

1. Authentication and authorization live in different places. Entra says who the person is (with MFA); NKP says what their group can do. Eva proves it in the first test.
2. Groups, always. The token carries the Object ID; NKP uses oidc:<ID>. Joining or leaving a group in Entra changes access from the next token on, without touching NKP.
3. Dashboard roles and cluster roles go together. The dashboard queries the clusters with the permissions of whoever is logged in.
4. Check what a role grants before using it. In NKP 2.19, the default Workspace Cluster Admin Role is aggregated; for an operator with full cluster access, use a custom Workspace Role.
5. A project developer needs three levels. The global front door, workspace read access and work in the project.
6. Keep emergency access. Local admin and certificate kubeconfig, stored in a vault, before touching the login.

Checklist: NKP login with Entra ID

• Certificate kubeconfig and local admin password stored in the vault (break-glass)
• Outbound access from management to login.microsoftonline.com and graph.microsoft.com tested from a pod
• Entra users with the Email attribute filled in
• Security groups in Entra, one per profile, with the Object IDs written down
• App registration with a Redirect URI identical to the one in the NKP form
• Groups claim (Group ID) and optional claims email and upn
• Delegated permissions with GroupMember.Read.All and admin consent
• Client secret Value in the vault and a reminder 30 days before expiration
• OIDC Identity Provider with Username Key email, Insecure Enable Groups and Insecure Skip Email Verified
• Test with an account with no group: it authenticates and gets “Not Authorized”
• NKP groups with oidc:<Object ID>
• Bindings tested with kubectl auth can-i --as-group before granting access
• One kubeconfig per user (export KUBECONFIG) when using Generate Token

What I haven’t tested yet

• kubectl-only access, without the dashboard, for an Entra user who shouldn’t get into Kommander (the k8s-servicos-kubectl group already exists in the lab’s Entra). For exceptions, access with a certificate issued by the cluster itself, bound to one namespace, is covered in NKP teams with native RBAC and quotas.
• User offboarding: how long access remains after disabling the account in Entra, with the 24-hour token.
• MFA on every login with Conditional Access (Entra ID P1). With Security Defaults, Entra prompts for MFA based on risk evaluation, not on every login.
• The same profiles on a cluster with a Pro or Starter license. The recipe with native Kubernetes RBAC (namespace, RoleBinding for the group and quota), which does not depend on workspaces or projects, was tested in the lab and is covered in NKP teams with native RBAC and quotas.
• Rotating the client secret before it expires, without interrupting logins.

References

Nutanix

• Configure NKP single sign-on with Microsoft Entra ID (nutanix.dev)
• Integrating NKP with Microsoft Active Directory via LDAP (nutanix.dev)
• Nutanix Kubernetes Platform: datasheet and editions
• Nutanix Kubernetes Platform Guide 2.19, Identity Providers and Access Control sections (Nutanix portal)

Microsoft

• Optional claims and the groups claim in Microsoft Entra ID
• Security Defaults in Microsoft Entra ID

Projects and community

• Dex: OpenID Connect connector
• Kubernetes: RBAC authorization