AKS: Azure RBAC authorization webhook (guard) intermittently times out calling ARM checkAccess since 2026-11-06 07:14 UTC (West Europe)

Since 2026-11-06 07:14 UTC, the Azure RBAC for Kubernetes authorization webhook (guard) of two of our AKS clusters intermittently times out when it calls ARM checkAccess. When that happens, the API server rejects the operation with InternalError, and our deployment pipelines fail.

Environment

• Two clusters, each in a different subscription of the same tenant, both in West Europe.
• Kubernetes 1.36.4, Standard tier, managed Microsoft Entra ID with Azure RBAC, local accounts disabled.
• API Server VNet Integration, Azure CNI powered by Cilium (overlay), NAT Gateway.

Error seen by clients (kubectl, Pulumi)

Error from server (InternalError): an error on the server ("Internal Server Error: \"/apis/apps/v1/namespaces/<ns>/deployments/<name>\": Post \"https://guard.<id>.svc.cluster.local:443/subjectaccessreviews?timeout=3s\": net/http: request canceled (Client.Timeout exceeded while awaiting headers)")

What the guard logs show (diagnostic setting, category guard)

• The failing calls are POST https://management.azure.com/.../providers/Microsoft.Authorization/checkaccess?api-version=2018-09-01-preview, which end with context canceled / Client.Timeout exceeded while awaiting headers and giving up after 1 attempt(s).
• There were no such failures from 2026-11-01 until 2026-11-06 06:00 UTC. Since then they keep happening intermittently in both clusters, and they were still occurring at 16:30 UTC.
• The checkAccess calls that do answer take about 0.3 s (median) and return the expected decisions.
• We are not being throttled by ARM: remainingARMCalls stays around 247-249.
• Authentication works: tokenreviews succeed.
• The guard ReplicaSets have not changed since 2026-10-27.

What we have ruled out on our side

• No writes to the clusters, no Kubernetes or node image upgrade, and no relevant role assignment or network change in the last 72 hours.
• Guard-to-ARM traffic runs in the managed control plane anyway, outside our VNet.
• Resource Health shows both clusters as Available, and Service Health shows no event for AKS or ARM in these subscriptions.

Impact Every write to the clusters is unreliable, which blocks our production deployments. Running workloads are not affected.

Questions

1. Is there a known issue with ARM Authorization checkAccess latency from the AKS control plane in West Europe since 2026-11-06?
2. Is there any supported mitigation that does not mean disabling Azure RBAC, for example a longer webhook timeout or retries in guard?

We can share the cluster resource IDs and the correlation IDs of the failed checkAccess calls privately. Our subscriptions are on the Basic support plan, so we cannot open a technical support case.