When you trying to set up permissions for different teams, you may want to set default permission for a specified team, then only grant privileged permission when necessary by using Privileged Identity Management (PIM) for just-in-time requests.

This article shows you how to:

• Set default role for example groups, to access or perform operations in an AKS cluster based on Microsoft Entra group membership with AKS-managed Microsoft Entra integration.
• Basic role for accessing cluster with kubectl and Azure portal.
• Self-active the role to get just-in-time access to AKS cluster.
• Set approver to apporve or deny approval for just-in-time access.

NOTE

Microsoft Entra Privileged Identity Management (PIM) is Microsoft Entra ID P2 or Microsoft Entra ID Governance capabilities requiring a Premium P2 SKU. For more on Microsoft Entra ID licenses for PIM and SKUs, see Microsoft Entra ID Governance licensing fundamentals and pricing guide.

TIP

This article finally goes online as an official document: Use Privileged Identity Management (PIM) to control access to your Azure Kubernetes Service (AKS) clusters.

Before you begin#

• See AKS-managed Microsoft Entra integration for an overview and setup instructions.

Configure Microsoft Entra related settings#

Create demo groups in Microsoft Entra ID#

In this article, we will create three groups which are:

• Default: only has read-only access to resources in the cluster (Azure Kubernetes Service RBAC Reader).
• Admin: has admin access to resources in the cluster (Azure Kubernetes Service RBAC Admin).
• Approver: has permission to approve or deny just-in-time access. Not applicable if you want the members in default group can do self-escalation within a specific period.

TIP

Technically, you do can set two groups instead of setting additional approver group. However, if you include admin group as approver, the memeber who get just-in-time acess will have the power to approve other just-in-time request. The set-up like this should only be used for test purpose.

1. Get the resource ID of AKS cluster, and resource group ID where AKS cluster is by using the az aks show command.

AKS_ID=$(az aks show \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --query id -o tsv)

rG_ID=$(az group show --name myResourceGroup --query id -o tsv)

2. Create the default group by using the az ad group create command.

DEFAULT_ID=$(az ad group create --display-name default --mail-nickname default --query id -o tsv)

3. Create an Azure role assignment for the default group using the az role assignment create command.
   There are three roles that require to be assigned depending on your own scenario:

• Azure Kubernetes Service RBAC Reader: assigned at the scope of AKS cluster, which gives basic read-only access to see most objects.
• Reader: assigned at the scope of resource group, which will allow users to see AKS or other resources in the resource group on Azure portal.
• Azure Kubernetes Service Cluster User Role: assigned at the scope of AKS cluster, which allow user to get kubeconfig context for using kubectl.

az role assignment create \
    --assignee $DEFAULT_ID \
    --role "Azure Kubernetes Service RBAC Reader"  \
    --scope $AKS_ID

az role assignment create \
    --assignee $DEFAULT_ID \
    --role "Reader"  \
    --scope $rG_ID

az role assignment create \
    --assignee $DEFAULT_ID \
    --role "Azure Kubernetes Service Cluster User Role"  \
    --scope $AKS_ID

4. Create the admin group with “Azure Kubernetes Service RBAC Admin” role.

ADMIN_ID=$(az ad group create --display-name admin --mail-nickname admin --query id -o tsv)

az role assignment create \
    --assignee $ADMIN_ID \
    --role "Azure Kubernetes Service RBAC Admin"  \
    --scope $AKS_ID

NOTE

If you want to let users in admin group change the settings of nodepool, like manually scale out/in nodes, you have to create the assignment like this: az role assignment create --role "Contributor" --assignee $ADMIN_ID --scope $AKS_ID/nodepools/<nodepool-name>.
Note that this only give permission to scale out/in from AKS resource. If you want to do scale out/in or other operations from VMSS resource, you need to create assignment with relative role at VMSS scope.

5. Create the approver group without any role

APPROVER_ID=$(az ad group create --display-name approver --mail-nickname approver --query id -o tsv)

Create demo users in Microsoft Entra ID#

In this article, we will create two users. One is normal user who only has default role, and one is the privileged user who can approve or deny just-in-time access requests from normal user.

1. Create the normal user, add add the user to default group by using the az ad user create and az ad group member add command.

DOMAIN=contoso.com
PASSWORD=Password1

NUSER_ID=$(az ad user create \
    --display-name n01 \
    --password ${PASSWORD} \
    --user-principal-name n01@${DOMAIN} \
    --query id -o tsv)

az ad group member add --group $DEFAULT_ID --member-id $NUSER_ID

2. Create the privileged user, and add the user to approver group.

PUSER_ID=$(az ad user create \
    --display-name p01 \
    --password ${PASSWORD} \
    --user-principal-name p01@${DOMAIN} \
    --query id -o tsv)

az ad group member add --group $APPROVER_ID --member-id $PUSER_ID

Enable Privileged Identity Management (PIM) for the admin group#

Now, we will enable Privileged Identity Management (PIM) for the group with the name “admin”.

1. Select the admin group in Azure portal.
   

2. Select Privileged Identity Management, then enable PIM for this group.
   

Set approver of the admin group#

In this article, the users in approver group will be set to review the just-in-time access requests.

1. Go to Microsoft Entra Privileged Identity Management.

2. Choose Groups on the left panel.

3. Choose admin group.
   

4. Go to “Assignments”, then click on “Add assignments”.
   

5. Choose “Member” as the selected role, then choose “default group” as selected member.
   

6. Make sure the “Assignment type” is “Eligible”, then assign.
   

7. Go to “Settings”, then click on “Members”.
   

8. Choose “Edit”.

9. Choose “Require approval to activate”, then add approver group as approver.
   

NOTE

If you decide not to choose “Require approval to activate” here, the users in default group will be able to self-active the role to get just-in-time access to AKS cluster.

10. Make other appropriate changes as you want, then click “Update” to save your changes.

NOTE

The user in approver group has to be the member of the group. Even you set the user as owner, the user will still not be able to review the just-in-time access requests.
This is because the group owner only has administrative rights to the group, not the role assigned to the group. It is possible to set the user as member and owner of the same group at the same time, and they do not conflict with each other.

Till now, the approver has been successfully set.

For more details of PIM configuration, see Configure PIM for Groups settings.

Accessing AKS resources#

Interact with cluster resources with default permission#

As everything has been set, we can try to access the AKS cluster by default role.

1. Use user n01 to login by the command az login

az login -u n01@${DOMAIN} -p ${PASSWORD}

2. Use az aks get-credentials to get kubeconfig for using kubectl.

az aks get-credentials \
    --resource-group myResourceGroup \
    --name myAKSCluster

3. Try to get Pod and secrets

kubectl get po -n kube-system
NAME                                    READY   STATUS    RESTARTS   AGE
azure-ip-masq-agent-2rdd9               1/1     Running   0          30h
azure-policy-767c9d9d9d-886rf           1/1     Running   0          31h
cloud-node-manager-92t6h                1/1     Running   0          30h
coredns-789789675-b2dhg                 1/1     Running   0          31h
coredns-autoscaler-77bbc46446-pgt92     1/1     Running   0          31h
csi-azuredisk-node-lnzrf                3/3     Running   0          30h
csi-azurefile-node-lhbxr                3/3     Running   0          31h
konnectivity-agent-7645d94b-9wqct       1/1     Running   0          30h
kube-proxy-lkx4w                        1/1     Running   0          31h
metrics-server-5955767688-lpbjb         2/2     Running   0          30h

kubectl get secrets -n kube-system
Error from server (Forbidden): secrets is forbidden: User "[email protected]" cannot list resource "secrets" in API group "" in the namespace "kube-system": User does not have access to the resource in Azure. Update role assignment to allow access.

As the role Azure Kubernetes Service RBAC Reader does not have permission to access secrets, this means the default role has been successfully set.

Request just-in-time access to AKS cluster#

This time, we can try to request just-in-time access, as temporarily add the role of Azure Kubernetes Service RBAC Admin. See Activate your group membership or ownership in Privileged Identity Management for the steps.

About the steps for approvers to approve requests, see Approve activation requests for group members and owners.

Interact with cluster resources with admin permission#

After temporarily adding the role of Azure Kubernetes Service RBAC Admin, we can try access secrets again.

1. Remove exsiting stored tokens by kubelogin remove-tokens.

kubelogin remove-tokens

NOTE

If you will encounter error due to lack of permission, re-login is required to refresh the permission. No matter you are using kubectl or Azure portal to access AKS cluster.

2. Try access secrets again

kubectl get secrets -n kube-system
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code XXXXXXXXX to authenticate.
NAME                     TYPE                            DATA   AGE
bootstrap-token-sw3rck   bootstrap.kubernetes.io/token   4      35h
konnectivity-certs       Opaque                          3      35h

IMPORTANT

Due to the design of token lifetime, if you are granting roles to users who use CLI tools, like kubectl/kubelogin, the duration of activating (granting) roles during approval process technically can not be lower than 60 minutes. Even the duration is being set as 0.5 hours, the actual effective time is still between 60-75 minutes.
This is because when kubelogin is trying to get tokens from Microsoft identity platform, access_token and refresh_token will be returned for further use. access_token is used to make request to API, and refresh_token is used to get new access_token if the original one is invalid. The access_token cannot be revoked once being generated. Only the refresh_token can be revoked.

In order to manually revoke refresh_token, use Revoke-AzureADUserAllRefreshToken.

Next steps#

To learn more about Privileged Identity Management (PIM), Kubernetes RBAC with Microsoft Entra intergtation, see:

• What is Microsoft Entra Privileged Identity Management
• Use Kubernetes role-based access control with Microsoft Entra ID in Azure Kubernetes Service

Special Thanks to#

Richard Yang: For providing Azure subscription to complete this article.