This is Part 1 of a four-part series on Azure Kubernetes Service (AKS) security best practices. It covers what to consider when planning and creating AKS clusters, and how to build and maintain secure container images.
Microsoft’s Azure Kubernetes Service (AKS) has become one of the most widely used managed Kubernetes platforms. Like any infrastructure service, however, the responsibility for securing workloads is shared: Microsoft manages the control plane, but cluster operators must make critical security decisions — many of which cannot be changed after a cluster is created. Understanding these decisions upfront is essential to building a defensible AKS environment.
Cluster Design
Security-minded design should precede cluster creation, not follow it. Several important AKS security features can only be enabled at cluster creation time. If an existing cluster was not created with these features, the recommended approach is to provision a new cluster and migrate workloads rather than attempt to retrofit security controls.
Equally important is configuration consistency. All clusters — including those used for development and staging — should mirror the security settings of production. Identical environments allow you to validate your security posture and confirm that applications behave correctly under production-equivalent restrictions before they are promoted. Inconsistent configurations create dangerous assumptions and make automation unreliable.
Enable Kubernetes RBAC
Why it matters
Kubernetes Role-Based Access Control (RBAC) is the preferred authorization mechanism for the Kubernetes API. It controls what users and workloads can do within a cluster. AKS extends this by supporting integration with Azure Active Directory (Azure AD), allowing you to map Azure AD users and groups to Kubernetes roles. This integration can be enabled or updated at any time.
What to do
- RBAC must be enabled at AKS cluster creation time. It is enabled by default for new clusters — verify this has not been disabled in your provisioning scripts or infrastructure-as-code templates.
- Integrate Kubernetes RBAC with Azure Active Directory to centralise identity management and enforce least-privilege access for both human operators and service accounts.
- Audit RBAC bindings regularly to remove stale or overly permissive roles.
Enable Network Policies
Why it matters
By default, all pods in a Kubernetes cluster can communicate with each other without restriction. Kubernetes Network Policies act as firewall rules that control ingress and egress traffic between pods, namespaces, and external endpoints. Without network policies, a compromised workload can freely reach other services in the cluster.
What to do
Network Policy support can only be enabled at AKS cluster creation time. Your available options depend on the network plugin selected for the cluster:
- Kubenet (basic networking): Supports the Calico CNI for network policy enforcement.
- Azure CNI (advanced networking): Supports both Calico and Azure Network Policy Manager (azure-npm).
Both implementations honour standard Kubernetes NetworkPolicy manifest syntax, so you can use the same policy definitions regardless of the backend. Start with a default-deny posture and explicitly allow only the traffic each workload requires.
Use Private Clusters
Note: At the time of original publication (January 2020), private clusters were in preview. Check the current Azure documentation for the feature’s general availability status before using it in production.
Why it matters
Without private clusters, a cluster’s Kubernetes API server is reachable via a public IPv4 address, and all traffic to it — including traffic from the cluster’s own node pools — traverses public network space. A private AKS cluster places all control-plane components, including the API server, within a private RFC 1918 address space. This significantly reduces the attack surface and keeps API traffic entirely within Azure’s network fabric.
What to do
- Enable the private cluster option at cluster creation time — it cannot be added later.
- Plan for a bastion VM or Azure Bastion service, which is required to reach the API server from outside the cluster’s node pool VNet.
- Note that Azure charges for the Private Endpoint resource used to expose the Kubernetes API to connected VNets.
- Review current Azure documentation for any remaining limitations before adopting private clusters in production.
Container Images
Every Kubernetes workload is built on a container image. Securing those images is therefore foundational to the security of any AKS cluster. There are two complementary practices: building minimal, hardened images, and scanning images continuously for known vulnerabilities.
Build Secure Container Images
Why it matters
The tools and packages present in a container image directly determine its exploitability. Images that include Linux package managers, Unix shells, web clients like curl, or other general-purpose utilities give attackers far more options if they achieve code execution inside a container. Minimal images reduce the blast radius of a compromise.
What to do
- Use a minimal base image. Google’s Distroless images are purpose-built for this: they contain only the runtime dependencies for your application and exclude package managers, shells, and other exploitable tools.
- Install only what the application needs at runtime. Debugging tools, profilers, and test utilities should not appear in production images.
- Avoid embedding long-lived network tools. If you need a tool like
curlonly at pod start-up, use an init container instead of bundling it in the main image. Where possible, prefer Kubernetes-native delivery mechanisms such as ConfigMaps or Secrets. - Remove package managers after installation steps. If you must use a package manager to install dependencies during the image build, use multi-stage builds to ensure the package manager itself is not present in the final image layer.
- Pin and update base image versions. Monitor for new releases of your base image and third-party tools and rebuild images promptly when security patches are released.
- Run containers as a non-root user. Configure your Dockerfile with a dedicated, unprivileged user and set
USERaccordingly.
Scan Images for Vulnerabilities
Why it matters
Even a carefully built image can contain known vulnerabilities in OS packages or third-party libraries. Ongoing image scanning against an up-to-date CVE (Common Vulnerabilities and Exposures) database is the mechanism that makes this visible. Scanning must cover not only OS-level packages but also language-specific dependencies — for example, Java libraries, Python packages, and npm modules — because application-layer vulnerabilities such as the Apache Struts flaw exploited in the Equifax breach would not be detected by an OS-only scan.
What to do
- Integrate scanning into your CI/CD pipeline. Images with high-severity, fixable CVEs should fail the build and generate an alert — do not allow them to be pushed to production registries.
- Choose a scanner that covers both OS and language-level dependencies. Azure Container Registry has a built-in scanning capability (verify current availability and feature scope in the Azure documentation). Open-source alternatives include Trivy and Grype; commercial options are also available.
- Establish a remediation policy. Define an SLA for patching serious, fixable vulnerabilities in images that are already deployed to clusters, not just in the build pipeline.
- Scan third-party images too. If your cluster runs upstream or vendor-supplied images, scan those as well. If a third-party maintainer is slow to address critical vulnerabilities, consider building and maintaining your own version of that image.
- Re-scan images on a schedule. New CVEs are published continuously. An image that was clean at build time may become vulnerable weeks later; periodic re-scanning of images in your registry addresses this.
Summary
Securing an AKS cluster starts before the first node is provisioned. The decisions made at cluster creation — enabling RBAC, selecting a network plugin that supports network policies, and opting into private cluster mode — cannot easily be undone. Equally, the discipline of building minimal container images and scanning them continuously forms the foundation upon which all higher-level workload security depends. Part 2 of this series will cover cluster hardening and runtime security controls.
Original source: Security Boulevard.