AKS aad rbac enabled user impersonation

Question

Hi,

This question is partially related to k8s and azure authentication. The answer might very well be "no" but at least then I'd know to look for a work around.

Is the impersonation api exposed on rbac enabled aks services? I'm writing infrastructure tests and I'd like to take advantage of:

kubectl auth can-i --as <user> --as-group <group> exec pod <pod> -n <namespace>

I am one of the cluster admins and kubectl auth can-i appears to work when I use it with my own credentials

kubectl auth can-i list pods -n <namespace>

However my user creds in ~/.kube/config are x509 client certificates given to me by

az aks get-credentials 

Since all of our role bindings are done against AAD using groups. I'd need the goid and the user would be (I assume) the credentials populated in the users ~/.kube/config. So without pulling the users credentials to my own kubeconfig, can I as an administrator impersonate that user via kubectl? Or do I have to write something that sits in the middle that can obtain user like credentails that would validate a test?

That is can I test that user A and user B only have access to resources in namespace A and namespace B respectively. Is the k8s rbac impersonation api the best way to do this? Is there a more azure focused solution that provides the same functionality?

I found these docs on user impersonation in k8s. Here's an example that partially explains support for unsupported authentication protocols where you can execute client side code in the auth flow in order to obtain credentials. I have no idea if this is relevant or not.

Edit:

As one of my colleagues pointed out the client cert credentials in our kubeconfs are handed out as we have system:master and are allowed to pull creds with

 az aks get-credentials --admin

However users that pull without --admin should have a kubeconf entry like this:

- name: cluster-name
  user:
    auth-provider:
      config:
        access-token: eyJ0eXAiOiJKV1Qi.........
        apiserver-id: <id>
        client-id: <id>
        environment: AzurePublicCloud
        expires-in: "3599"
        expires-on: "1600084217"
        refresh-token: 0.ASAATlaAafxBF025..........
        tenant-id: <id>
      name: azure

It's be good to know how these values can be mapped to impersonation if at all and what the request might look like.

Cheers
Iàsan

Answer 1

have you got the solution for this? If yes, Could you please update here? Thanks.