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.

This is how to "upload" the certificate by CLI when web GUI doesn't accept it.

 Technical Note: Upload Certificate using PEM forma... - Fortinet Community

Fortinet get your paired devices back in sync

<!-- Google tag (gtag.js) --> <script async src="https://www.googletagmanager.com/gtag/js?id=G-6ZMZ3S49YN"></script> <script> window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'G-6ZMZ3S49YN'); </script>

It's a Kuhlua in your coffee first thing in the morning when you suddenly find your paired Fortinet devices out of sync and the FortigateSDN down and certain dynamic addresses just bling with red exclamation marks. Like what in the world?

Well for one thing, the secondary is still showing green. However, it's not an actual full fail because the Policies with hard-coded IP addresses so traffic is still going through, so it was hard to see right away.

1. Get the FortigateSDN Connector with Azure with the correct secret, check in the GUI.

Use the CLI to check if information about the SDN Connectors is there, though obviously it is.

show full | grep -f FortigateSDN

diag debug enable

diag debug app azd -1

I don't like using the config command just to show, but you can hit end right away

config sys sdn-connector

show full

end

(or edit each item as needed)

 

2. some CLI commands to check the health status.

get system ha status

diag debug console timestamp enable

diag debug application hatalk -1

diag debug application hasync -1

diag sys ha checksum cluster

 

Forcing a sync again maybe

di deb app hasync-1

di deb app hatalk -1

exec ha sync start 

(exec ha sync stop) why?

(dia deb disable) makes it stop writing to the screen

di deb reset

diag sys ha checksum recalculate

3. can look at probes

show sys probe-response

show full-config sys probe-response

show full-conf sys interface 

4. Comparing working flows

diag debug reset

(diag debug enable)

diag debug flow filter dport 8008

diag debug flow show function-name enable

diag debug flow trace start 100

 diag debug enable

Type that one last or you'll have too many things pop up all over the screen!

 

5. here's to get rid of an annoying startup banner

 set gui-firmware-upgrade-warning <enable | disable>

 

 

 

Cisco Enterprise Core Technologies

During the ongoing months of COVID lockdown, and being sent to work from home for most of the week, I decided to gear up on some Cisco training.

I recently completed the Cisco Certified Network Administrator bootcamp course! I'm not sure if I have the intention of actually going through with the certification exam, but why not. However I went straight to the next course on the schedule and it was Cisco Enterprise Core Technologies.  It was the perfect combo because it refreshes and expands the material that was already covered in CCNA and makes things more practical. Of course we had the best instructor ever for both courses, gotta love Patrice and Raj.

I will post some of the links to other great topics we uncovered and also some great screen shots. I call this one, hot tips for fast subnetting and finding your address space. Boom. 4 seconds and no binary required. Can you see it? I will explain this later.