Prerequisites#

• kubectl version needs to be gerater than or equal to 1.35.

TL;DR#

• Use --as ${externalUserId} --as-user-extra oid=${externalUserId} for ABAC-enabled AKS cluster.
• Use --as ${externalUserId} for non ABAC-enabled AKS cluster.
• Impersonation messages can be found in AKSControlPlane table, but you need to combine them with AKSAudit or AKSAuditAdmin tables to perform auditing.

Before you begin#

Kubernetes v1.35.0 was released on Dec 18, 2025. As of now (Jan 16, 2026), your client version is likely not upgraded to the latest version required to meet the requirement.
Version 1.35.0 introduces --as-user-extra flag in kubectl, which is mandatory for impersonation in ABAC-enabled AKS cluster. So, be sure to check your kubectl version using the command below:

1
kubectl version

If you are using Azure Cloud Shell, you can use the following command to overwrite the embedded kubectl:

1
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
2
install -m 0755 kubectl ~/.local/bin/kubectl && bash

If you need to uninstall non-embedded kubectl from Cloud Shell, use the command below:

1
rm ~/.local/bin/kubectl && bash

For general environment, follow official documentation to upgrade your kubectl version.

Preparing environment#

Before practicing impersonation, we will need to pre-define some parameters and create a secondary account for comparison.

1. Create secondary account

Modify the following parameters according to your environment:

1
NAME=aksreadonlyuser
2
DOMAIN=contoso.com
3
PASSWORD=Password1

Then, create a new account:

1
az ad user create -o none \
2
    --display-name ${NAME} \
3
    --password ${PASSWORD} \
4
    --user-principal-name ${NAME}@${DOMAIN}

CAUTION

Remember to delete this secondary account after practising.

2. Retrieve the AKS ID and the user object ID

1
aksId=$(az resource list -n ${aks} -g ${rG} \
2
    --resource-type Microsoft.ContainerService/managedClusters \
3
    --query [0].id -o tsv)
4

5
externalUserId=$(az ad user show -o tsv --query id \
6
    --id ${NAME}@${DOMAIN})

Impersonation#

Before performing impersonation, you may want to verify the type of AKS cluster you are using.

To check if your AKS cluster is AAD-enabled, use the command below:

1
az aks show -n ${aks} -g ${rG} --query aadProfile

If the result is null (empty, nothing), this article is not applicable to your AKS cluster, as it is not AAD-enabled. If the result is anything else, then your AKS cluster is AAD-enabled.

To check if your AKS cluster is ABAC-enabled, use the command below:

1
az aks show -n ${aks} -g ${rG} --query aadProfile.enableAzureRbac

If the result is true, then your AKS cluster is ABAC-enabled; otherwise, it is ABAC-disabled.

After that, remember to retrieve your kubeconfig:

1
az aks get-credentials -n ${aks} -g ${rG}

1
az role assignment create --role "Azure Kubernetes Service RBAC Reader" \
2
    --assignee-object-id ${externalUserId} -o none \
3
    --scope ${aksId} --assignee-principal-type User

1
kubectl auth can-i get pod --as ${externalUserId} --as-user-extra oid=${externalUserId}
2
kubectl auth can-i get secret --as ${externalUserId} --as-user-extra oid=${externalUserId}

1
yes
2
no - User does not have access to the resource in Azure. Update role assignment to allow access.

1
<<EOF kubectl apply -f -
2
apiVersion: rbac.authorization.k8s.io/v1
3
kind: ClusterRole
4
metadata:
5
  name: pod-access-role
6
rules:
7
- apiGroups: [""]
8
  resources: ["pods"]
9
  verbs: ["get", "list"]
10
---
11
apiVersion: rbac.authorization.k8s.io/v1
12
kind: ClusterRoleBinding
13
metadata:
14
  name: access-to-pod
15
subjects:
16
- apiGroup: rbac.authorization.k8s.io
17
  kind: User
18
  name: ${externalUserId}
19
roleRef:
20
  apiGroup: rbac.authorization.k8s.io
21
  kind: ClusterRole
22
  name: pod-access-role
23
EOF

1
kubectl auth can-i get pod --as ${externalUserId}
2
kubectl auth can-i get secret --as ${externalUserId}

1
yes
2
no

Audit the impersonation actions#

Auditing impersonation actions in Kubernetes is vital for security, as it tracks user actions on behalf of others, allowing administrators to detect unauthorized access and analyze behavior. In this section, we will use Log Analytics Workspace and resource logs to retrieve control plane logs.

1. Enable control plane logs for ingestion

Follow the section “Enable Control Plane Logs for Ingestion” in this documentation.
In this article, only KubernetesAudit and KubernetesControlPlane will be utilized. You can adjust these options based on your environment.

2. Ingestion

The impersonation logs will only appear in the AKSControlPlane table. Use the query below to view the messages:

1
AKSControlPlane
2
| where TimeGenerated > ago(10m)
3
| where Category == "kube-apiserver" and Level =~ "info"
4
| where Message contains "impersonating"
5
| project TimeGenerated, Message
6
| take 3

Output:

In the output:

• 00000000-0000-0000-0000-000000000000 is representing the person who is impersonating.
• 11111111-1111-1111-1111-111111111111 is representing the person who is being impersonated.
• 22222222-2222-2222-2222-222222222222 is representing the group name of “system:authenticated”.

NOTE

The actual output of TimeGenerated should be in the format like “2026-01-15T10:43<06>.536207Z”. Here, the output like “1/15/2026, 10:43<06>.536 AM” is formatted by the Log Analytics Workspace Web.

To combine the message with the actual action, use the following Kusto query:

1
// Set your time range
2
let TimeRange = ago(10m);
3
let binSize = 1ms;
4

5
let apiServer = AKSControlPlane
6
| where TimeGenerated > TimeRange
7
| where Category == "kube-apiserver" and Level =~ "info"
8
| where Message contains "impersonating"
9
| project TimeGenerated, Message, PodName
10
| extend TimeBin = bin(TimeGenerated, binSize);
11

12
let auditLog = AKSAudit
13
| where TimeGenerated > TimeRange
14
| where Level =~ "RequestResponse" and User contains "oid"
15
| project RequestReceivedTime, Verb, RequestUri, User, SourceIps, UserAgent, ObjectRef, ResponseStatus, RequestObject, ResponseObject, Annotations, PodName
16
| extend TimeBin = bin(RequestReceivedTime, binSize);
17

18
apiServer
19
| join kind=leftouter (auditLog) on TimeBin, PodName
20
| where TimeGenerated >= RequestReceivedTime
21
    and TimeGenerated <= (RequestReceivedTime + binSize)
22
| project-away TimeBin, TimeBin1, PodName, PodName1
23
| take 2

Output:

NOTE

It may take up to 30 minutes for data in AKSAudit to be collected.

Afterword#

The article starts with a user asking why kubectl auth can-i doesn’t work in the AKS GitHub repository. Following that, the Kubernetes SIG CLI team introduced a new feature that allows users to input --as-user-extra, making it possible to impersonate other users in ABAC-enabled AKS using just the CLI, without modifying any files. This feature was released about a month ago.

Now, I’ve decided to write this article to address the issue. I’ve also included a method for auditing impersonation actions, which lets users review their activities while impersonating others, adding some extra depth to the discussion.

And here’s the article I’ve put together.