This is me having a chat with my friendly neighborhood Co-Pilot.

  

Could you summarize for me please, what's the scoop on this? Did anyone else get an email about device code flow being disabled? Isn't it the main auth method for Azure Kubernetes? I was directed towards these instructions and they do work: https://learn.microsoft.com/en-us/azure/aks/kubelogin-authentication?tabs=environment-variables&pivots=azure-cli Downside it that I need to run an az login before running my kubectl commands, as opposed to running the kubectl command and being directed towards the device code login for Azure. The az login works with using a device code (although you could force it with the appropriate argument).

Copilot said:

Copilot

Here’s the scoop, Deborah — and you’re definitely not the only one confused.

---

✅ Short Summary (What’s Going On)

Device code flow for AKS is not disabled, but the old “kubectl triggers device code login automatically” behavior has been removed because:

1. The legacy Azure auth provider in kubectl was fully deprecated and removed (Kubernetes 1.26+).
2. AKS now requires the newer kubelogin exec plugin, which does not trigger device-code flow automatically unless the kubeconfig is converted properly.
3. kubelogin ≥ v0.2.0 changed behavior, requiring an az login first in most cases.

You’re seeing exactly what others have hit when their kubelogin / kubeconfig wasn’t updated.

---

✅ Evidence from official sources

1. kubelogin ≥ v0.2.0 requires convert‑kubeconfig

Users reported that device code login seemed “gone” until they ran the required conversion step.
github

2. kubectl’s old built‑in Azure auth plugin only supported device code flow and is now removed

microsoftdev

3. Device code is still supported — it’s just the default mode after convert‑kubeconfig

github

---

🧩 Why you need az login now

With new kubelogin:

• kubectl no longer initiates device code auth directly.
• The recommended auth flow is:

az login
az account set --subscription <sub>
az aks get-credentials --resource-group <rg> --name <cluster> --overwrite-existing
kubelogin convert-kubeconfig -l azurecli
kubectl get pods

That convert-kubeconfig step rewrites your kubeconfig to use the exec plugin, which then uses the Azure CLI credential flow by default — hence the need for an az login.

This design is intentional and aligns AKS with standard client-go exec plugins.

---

🧩 Can you still use Device Code? Yes — here’s how

You can explicitly convert your kubeconfig to device code mode:

kubelogin convert-kubeconfig -l devicecode

Then your kubectl command will again trigger a device-code challenge:

kubectl get pods
# -> "use a browser to open https://microsoft.com/devicelogin and enter the code XXXX"

Device code mode is still supported, just not auto‑magically triggered without the conversion step.
github

---

🚨 Important Gotchas

• kubelogin device code mode fails if your tenant has Conditional Access — use web‑interactive instead.
  github
• The jump from kubelogin 0.1.9 → 0.2.x changed behavior and broke some setups until kubeconfig conversion was done.
  github

---

📝 So in plain terms…

You’re correct:

• Previously: kubectl → triggers device code automatically
• Now: kubectl → uses exec plugin → expects you to be logged in (Azure CLI) unless you configure your kubeconfig to use device code login mode explicitly.

This is because the internal Azure auth plugin is gone and kubelogin requires a more explicit and modern OAuth flow.