Your Kubernetes control plane deserves the same scrutiny as your identity tenant.
An AKS cluster can be wired into Microsoft Entra ID with Azure RBAC governing every role assignment, its own local admin certificates switched off, its API server locked down to a private network or a specific IP allow-list, and a real network policy engine keeping compromised pods from reaching everything else. Or it can be running with none of that: local accounts still active as a permanent bypass around Entra ID, a fully public API server, and every pod able to talk to every other pod. Both configurations are silent on the surface -- the cluster runs the same either way. ID Posture checks which one you actually have, cluster by cluster, across every connected subscription.
Six findings, checked on every scan
Ask your ID Posture contact to enable Compute for your tenant.
Why it matters
Entra ID integration and Azure RBAC mean cluster access is governed by the same identity controls -- Conditional Access, MFA, PIM -- as everything else in your tenant, and every role assignment is visible in Azure's own access reviews, not buried in Kubernetes-native RoleBindings only the cluster itself can see. Local accounts are a permanent, unmonitored bypass around all of that: a leaked local credential grants access no Entra ID control can revoke. The API server is the single most sensitive endpoint in the cluster, and a network policy engine is the only thing stopping one compromised pod from reaching every other workload on the same cluster. ID Posture checks all six on every scan.
Part of ID Posture’s broader Azure resource coverage. See the full product overview, or explore AI Agent Identity and Tenant Health.
It's optional, per tenant, and off by default until you ask for it.