"Headless" az login, serverside

[giuliohome]

Is there a way to print/get also the client id or - in other words - is there a reason why it is omitted from the console log?

I mean, I've not yet looked at the code, but I assume it's calling the browser via a complete URL with the client id as a query parameter, so I wonder why it's not logged as well. Before thinking about forking the repo and possibly changing the code, I thought I'd rather start asking here first.

My goal is to run az loginand kubectl on a pure server (hopefully without any X gui) and open the browser on another workstation, eventually coming back to the server.

[giuliohome]

I see that the interactive module calls an oauth client that returns the token. I guess the browser can't be opened on a different machine, because the result must be returned from the internal api call...

Otherwise one would follow a different flow (maybe the device code or a non interactive flow). In particular I've noticed that one can perform:

• az login interactive with browser and produce kubeconfig on a machine
• kubecectl with previously produced kubeconfig on a different machine
• authorize the above required device code on another machine

[giuliohome]

Btw, this is the az login prompt I'm talking about. For the sake of it, could one derive and show the client id at that point?
Nope, the client id comes from the access token that in turn is obtained after logging in with username and password: that finally explains why it is not in the az login log (before the browser is opened and the user is logged)!
From the README:

If there is no suitable token in the cache, or you choose to skip this step, now we can send a request to AAD to obtain a token.

[giuliohome]

hey guys there,

it looks to me that Azure AD federated identity credentials solve the issue Enable authentication via environment variables, don't they?

(they're also non-interactive, hence "better" from the point of view of my scenario here)

[weinong]

if you want to have non-ineteractive login, you should use service principal.

[weinong]

when you do az login, it defaults to interactive web login as I described earlier. It results in a refresh token and an access token stored in encrypted form on the filesystem. when you use kubelogin with -l azurecli, it basically does az account get-access-token --resource ${SERVER_APP_ID} where ${SERVER_APP_ID} is what is specified in kubelogin get-tokon --server-id ${SERVER_APP_ID}. This command will use the refresh token to mint a new access token issued for ${SERVER_APP_ID}, and kubelogin returns this token to kubectl to send to api-server.

[giuliohome]

So, are you saying that those instructions are wrong somehow? (however following those instructions, I can login eventually) Instead of saying "az login" at step 2, should they say instead kubelogin with -l azurecli? Btw in your readme, I see " -l azurecli" ony mentioned in the Azure CLI token login (non interactive), which is not what you are writing here: I think you are writing about https://github.com/Azure/kubelogin#web-browser-flow-default and what is this

kind: Config
preferences: {}
users:
  - name: user-name
    user:
      exec:
        apiVersion: client.authentication.k8s.io/v1beta1
        args:
        - get-token
        - --login
        - interactive
        - --server-id
        - <AAD server app ID>
        - --client-id
        - <AAD client app ID>
        - --tenant-id
        - <AAD tenant ID>
        - --environment
        - AzurePublicCloud
        command: kubelogin

(with no explanation) from the readme? A kubeconfig to be manually prepared? The readme doesn't explain how to get there, how to retrieve the values and prepare that kubeconfig. Or is it the az login that ultimately does it? And is it simpler and correct or should we really be using a different kubelogin command to prepare such a kubeconfig? If I look at the kubeconfig generated at the step 3 (following the instructions 1,2,3, I mentioned before) it is very similar to the above!
well, not exactly, under the tenant-id I see

      - --login
      - devicecode

So, it looks like we do both az cli before and then also device code (only the first time)!
So the instructions 2 az login and 3 az aks get-credentials ... blablabla ... > kubeconfig.yaml appear to be the correct! (except, maybe, the further step with the device code, is it a further security check?) And again, aside all this, I've also experimented that one can bring the kubeconfig.yaml on another machine (e.g. a pure server without a browser)

[weinong]

what doc are you referring to?
this is how I will go about it

az login
az aks get-credentials ...
kubelogin convert-kubeconfig -l azurecli
kubectl ...

[giuliohome]

An internal doc, that we use...
Well, so indeed I see you are adding a step with kubelogin convert-kubeconfig -l azurecli that is not in our doc.
In fact I was wondering about it and I asked them (should I insist that this step is missing?).
I don't know if our doc is wrong or incomplete. I'm not sure if that kubelogin convert-kubeconfig -l azurecli is necessary or what it is exactly doing. I assume you would redirect the previous az aks get-credential into a kubeconfig and then do you need to convert that kubeconfig?

[weinong]

AKS will return exec format kubeconfig with devicecode login for any 1.24+ clusters.
So, if you want to use azurecli login, kubelogin convert-kubeconfig -l azurecli will be required.

For any < 1.24 clusters, kubelogin convert-kubeconfig is required if you want to use kubelogin