The tugboat AKS cluster still hands every contractor the same cluster-admin kubeconfig certificate. How should the security engineer change authentication?
Select an answer to reveal the explanation.
Short Explanation
One shared cluster-admin kubeconfig is a master key passed around the pier. Hook AKS up to Microsoft Entra ID so each operator signs in as themselves.
Full Explanation
Microsoft Entra ID integration for AKS replaces the shared cluster-admin kubeconfig certificate with per-operator sign-in. Each contractor authenticates as their own identity to the tugboat cluster instead of passing around one master certificate—improving accountability and enabling centralized disablement when someone leaves the pier.
Embedding MSAL token acquisition in each microservice so pods authenticate to Entra fails by concept: that is workload-to-Entra patterns for apps, not changing how human operators authenticate to the Kubernetes API. Keeping the shared admin certificate in Key Vault with a ninety-day reminder still preserves a shared superuser credential; rotation reminders do not equal individual identities. Granting each contractor Global Administrator in the Entra tenant is grossly excessive and does not correctly implement AKS Entra integration for kubectl access.
Exam caveat: Entra integration addresses authentication (who you are); pair it later with Azure RBAC for Kubernetes authorization (what you can do)—identity alone may still over-privilege if local admin remains. Operational check: have a contractor sign in with Entra-based kubeconfig/kubelogin, confirm the shared admin cert is no longer the normal path, and revoke one user in Entra to prove access stops.