After Entra ID integration and Azure RBAC for Kubernetes are live, the old admin kubeconfig certificate still works on the canal AKS cluster. What follow-through should the security engineer perform?
Select an answer to reveal the explanation.
Short Explanation
Entra and Azure RBAC are live, but that old --admin kubeconfig still opens the door. Disable local accounts and shut the certificate back door.
Full Explanation
After Entra ID integration and Azure RBAC for Kubernetes are live, disable local accounts on the canal AKS cluster so the certificate-based admin kubeconfig back door stops working. Otherwise the old admin credential remains a valid authentication path alongside modern Entra identities, which means a leaked or shared --admin kubeconfig can still delete lock-gate workloads even though reviewers believe “everyone uses Entra now.” Closing local accounts is the required follow-through that makes the identity conversion real.
Deleting and recreating the entire cluster whenever an admin kubeconfig is suspected is unnecessary destruction when local accounts can be disabled in place. Activating eligible Owner in Privileged Identity Management each time someone needs the local admin kubeconfig preserves the back door as a normal workflow instead of closing it. Rotating only the cluster’s HTTPS ingress certificate leaves local Kubernetes accounts enabled and does not address API-server admin kubeconfig risk at all.
Exam caveat: disable local accounts only after Entra sign-in and Azure RBAC for Kubernetes are verified for break-glass admins, or you can lock operators out of the API. Operational check: attempt kubectl with the old admin kubeconfig and confirm authentication fails after local accounts are disabled; confirm Entra-based cluster admins still succeed against the canal AKS API.