Use PIM roles for accessing to the AKS namespace

[txgx (humpalu)]

Dear community,

Our IT Security will block the PIM group creation in our environment due to the required high privileges.
We are trying to use PIM roles for namespace access but no luck. I rolled over the documentation of aks and it says its not supported on UI. I event can't make it work with powershell or terraform.

Im looking for ideas is it really impossible? Or how can I move the whole Pim concept to the namespace level without elevated privileges permissions in Entra

[Terry (tltaylor1)]

Hi, it is not impossible, and the reason it looked that way is that the two products with PIM in the name are different things. Your security team blocked PIM for Groups, which needs directory-level privilege to create and manage role-assignable groups. What you want is PIM for Azure resources, which needs nothing in Entra beyond what you already have on the cluster: Owner or User Access Administrator at the cluster or its resource group is enough to create eligible assignments there.

The pieces:

1. Azure RBAC for Kubernetes authorization on the cluster (--enable-azure-rbac). With it, access to the Kubernetes API is granted through ordinary Azure role assignments, and the built-in roles Azure Kubernetes Service RBAC Reader, Writer, and Admin are meant to be scoped to a namespace. The scope is the cluster's resource ID with the namespace appended:

az role assignment create --role "Azure Kubernetes Service RBAC Writer" --assignee --scope $AKS_ID/namespaces/

2. The portal is why it seemed unsupported. The AKS documentation states that after you create a namespace-scoped assignment, the portal cannot show it; you list it with az role assignment list. The assignment is there and works, the UI just has no view for it.

3. The just-in-time part is a PIM for Azure resources eligible assignment at that same scope instead of an active one. The role eligibility schedule request takes the scope as the path prefix, so the request goes to <AKS_ID>/namespaces//providers/Microsoft.Authorization/roleEligibilityScheduleRequests/ with the role definition and principal in the body; in Terraform the same thing is azurerm_pim_eligible_role_assignment with scope set to that string, next to an azurerm_role_assignment for anything that should be permanent. Users then activate the role in the portal under My roles, Azure resources, and the activation is a time-boxed role assignment at the namespace, with approval and justification if you configure the role settings that way.

One thing to test first, because I have not found a documentation page that states it either way: whether the eligibility API accepts the namespace suffix as a scope. Role assignments certainly do. Create one eligible assignment at the namespace scope and activate it; if the API refuses the scope, the fallback is an eligible assignment of the Reader or Writer role at the cluster scope, which is still just-in-time and still needs no PIM for Groups, just wider than one namespace.

If this gets you to a working setup, please mark the answer as accepted. It helps the next person who is told PIM is off the table. And if you are curious what I build, my repositories are at github.com/tltaylor1; a ⭐ on anything you find interesting is always appreciated. Good luck with the security team.