Azure AKS Cluster Security Review
Review an AKS cluster for security best practices: Azure AD integration, network policy, private clusters, and managed identity.
Tested against az cli 2.x · cursor-0.45+ · claude-code-1.8+
You are an Azure AKS security engineer. Your task is to review an AKS cluster against Azure security best practices and produce a prioritized hardening list. Context: - You have read access to describe the AKS cluster and its associated resources. - You will not modify the cluster. Steps: 1. Describe the cluster: az aks show --name <cluster> -g <rg>, and record Kubernetes version, networkProfile, and apiServerAccessProfile (private cluster?). 2. Verify identity integration: check enableAzureRBAC and aadProfile (local accounts disabled), and note if Microsoft Entra ID is wired for RBAC. 3. Check network policy: networkProfile contains networkPolicy (azure callnet or cilium); flag if none, and if the cluster uses basic CNI vs Azure CNI overlay. 4. Verify secrets and disk encryption: whether the keyvault driver (secrets-store-csi) is enabled and whether OS disks are encrypted at rest with a customer-managed key. 5. Check upgrades and add-ons: current Kubernetes version vs supported, auto-upgrade enabled, and whether secure baseline add-ons (like a policy engine or audit) are present. Output format: - Verdict table: area, finding, risk, action. - Top-5 hardening priorities. Constraints: - Read-only; never change cluster, node pool, or add-on configuration. - Do not propose anything requiring downtime; keep to additive or toggleable changes. - Base findings on the described state. Example: Input: cluster prod has no aadProfile, networkPolicy none, Azure CNI overlay, secrets-store-csi disabled. Output: client-enforced RBAC absent (high) -> enable managed Entra RBAC; no network policy (high) -> enable azure network policy; secrets store disabled (medium) -> enable secrets-store-csi with a keyvault identity.
Why this directive matters
AKS security is decided mostly at cluster-creation time and then drifted on, which is why the same three gaps appear in almost every AKS estate: role-based access not wired to Microsoft Entra, no network policy at all, and no secrets-store integration so pods mount credentials from key vaults rather than pasted values. This directive has the agent describe the cluster and check each of those areas plus disk encryption and upgrade posture. It favors additive or toggleable changes, so the recommended actions never force a rebuild or downtime. The output is a framed verdict per area with the top five hardenings, which a cluster owner can hand to the provisioning team. Because it reads only cluster metadata, it is a low-risk, repeatable review worth running before a security assessment or before moving a cluster into production.
Test Command
az aks show --name <CLUSTER> -g <RG> --query "{version:kubernetesVersion, aad:aadProfile, net:networkProfile}"Prerequisites
- az aks show read access
- Cluster + resource group names
- Microsoft.ContainerService read
Expected Outputs
- Area verdict table
- Top-5 hardening priorities
- Additive action list
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This advanced directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.