Azure Kubernetes Service (AKS) delivers Kubernetes as a managed service in Azure and is popular among organizations looking for a hassle-free Kubernetes solution in the cloud. This blog post explores the details of securing your Azure Kubernetes Service (AKS) architecture, providing a holistic overview of critical considerations and best practices. Let’s get started.
Security considerations for AKS architecture
Though Microsoft handles many aspects of AKS security, there are important security elements that fall under the purview of customers in the shared responsibility model. Microsoft manages the security of underlying infrastructure, but customers should implement necessary guardrails to protect applications, data, and access configurations within the clusters. The proactive measures your teams take should include:
Proper RBAC configuration
Robust network policies
Usage of secure container images
Control-plane and data-plane security measures
Secured communication between microservices on the data plane
Multi-tenancy is common in AKS deployments as multiple applications or teams could end up using the same cluster. In such cases, adequate measures should be taken to avoid cross-proliferation. In the next section, we’ll take a closer look at these strategies and their associated best practices.
Actionable Kubernetes Security Best Practices [Cheat Sheet]
Since we’ve already covered the essential Kubernetes security best practices in the CloudSec Academy, we’ve gone a step further and put together a cheat sheet of some advanced steps you can take to safeguard your Kubernetes clusters.
Download now
The essential 8 AKS security best practices
To deploy your workloads securely in AKS clusters, there are few non-negotiable security practices. Let’s take a deeper dive into the top eight AKS security practices and the actionable steps you can take to mitigate risks:
1. Integrate with Microsoft Entra ID for identity access management (IAM)
AKS clusters can be integrated with Microsoft Entra ID (formerly known as Azure AD), the managed identity service from Azure for authentication and authorization. You can create Kubernetes Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings and integrate them with Microsoft Entra ID users and groups to define access permissions. AKS is also fully interoperable with Kubernetes role-based access control (RBAC). You have the option to create a role in Kubernetes RBAC and then create a role binding to map it to an Azure Entra ID user or group. Using roles and bindings helps with logical separation and access control to resources.
For AKS cluster resource access, use Azure RBAC and leverage the principle of least privilege to provide controlled access to the AKS resources included in your subscription. Kubernetes API access can be controlled either through traditional Kubernetes RBAC or by integrating it with Azure RBAC for unified management and access control.
To access any Azure resources from within services deployed in AKS, leverage pod-managed identity integration (currently in preview), where the access is routed through Microsoft Entra ID.
2. Configure cluster security
Kubernetes API server actions service requests for all activities within a cluster and therefore should always be secured through the principle of least privilege. This is especially important in multi-tenant deployments. Best practice for centralized management is to use Microsoft Entra ID’s enterprise-ready identity management capabilities.
For environments where you don’t want the Kubernetes API to be exposed to the internet, deploy a private AKS cluster where the control plane uses an internal IP address. Any traffic between the API server and AKS node pools will stay within a private VNet. You can control access to the control plane through options like bastion VMs, virtual network peering, VPN, and private endpoints. Along with these measures, manage your network through a load balancer.
When it comes to cluster security, one of the most important security best practices is ensuring that your AKS cluster is using the latest stable version of Kubernetes. Use the following command to upgrade AKS to the latest version:
az aks upgrade --resource-group <<resourcegroupname>> --name <<AKS clustername>>--kubernetes-version <<KUBERNETES_VERSION>>Because Kubernetes does not upgrade automatically, it’s a good idea to implement a governance policy to test the compatibility of the latest version with your workloads in a development environment before deploying to production.
And because multiple containers will be deployed in a cluster, it’s also important to restrict the type of activities that the container can perform, especially through privileged root access. Implement privileged root access by setting the allowPrivilegeEscalation flag to “false” in the pod manifest. Additionally, you can use the Linux kernel security modules called AppArmor and seccomp (secure computing) to implement file-system and process-level access restrictions for containers.
3. Implement pod security and credential protection
To ensure secure pod access to resources, specify pod security context settings and assign the minimum amount of permissions required to run as a different user or group other than root. This will restrict access to the underlying node processes and services.
Leverage the workload identity feature from Microsoft Entra ID to facilitate secure access to other Azure resources from AKS pods using a service account token volume projection mechanism. Add these settings to an API model JSON file to enable service account token volume projection:
{
"kubernetesConfig": {
"apiServerConfig": {
"--service-account-api-audiences": "api,istio-ca",
"--service-account-issuer": "kubernetes.default.svc",
"--service-account-signing-key-file": "/etc/kubernetes/certs/apiserver.key"
}
}
}Another important area of consideration is the risk of exposing credentials in your code. The recommended best practice is to use Azure Key Vault to store and retrieve keys and credentials used by applications.
In the event your clusters require access to Azure cloud workloads, you can limit pod retrieval of node managed-identity access tokens by first enabling Azure AD workload identity. Then, grant only minimal permissions to each user-assigned managed identity linked to a K8s service account. Since the workload identity does not restrict network access to the node’s IMDS endpoint, you should also apply a Kubernetes Network Policy to block metadata access for pods running in a specific namespace.
4. Implement namespace isolation
Kubernetes native isolation features can be used to isolate teams and clusters and provide least-privilege access to resources required by users and applications. Namespaces offer logical isolation for resources and workloads and help achieve higher pod density.
When you need to support a multi-tenant architecture, use Kubernetes RBAC to implement the principle of least privilege and avoid infiltration. When there are hostile workloads, it’s best to use physically isolated clusters for maximum security.
In AKS clusters, pod security admission is turned on by default. (Pod security admission uses labels to enforce the security standards policy for pods that are deployed to a namespace.) For single-cluster deployments, pod security admission is available out of the box; however, to establish an enterprise-grade policy and centralized management, you need to configure Azure policies.
Kubernetes Security Report
In this report - which is based on our scans of over 200,000 cloud accounts - we dive into the state of Kubernetes security, providing statistics that shed light on the prevalence of threats in Kubernetes environments and uncovering risks that often go unnoticed.
Download report
5. Deploy secure container images
Integrate tools like Trivy or Clair with your continuous integration/continuous deployment (CI/CD) workflow to ensure that the container images deployed to the AKS clusters are scanned for vulnerabilities and verified to be safe.
It’s also important to put a process in place that will update base images, including any downstream container images linked to the base image, when security fixes are released. Integrate validation steps in your deployment pipeline to ensure that only the updated images get deployed to AKS clusters.
6. Enhance network security through CNI and network policies
While Azure supports both kubenet networking and Azure CNI plugin-based networking, it’s better to use the latter as it offers smoother integration with Azure Vnets as well as on-prem networks. Azure CNI offers a vendor-neutral network protocol where pods receive IP from Azure VNet and can offer segregation of control and management, especially when there are multiple teams involved.
In addition to implementation of Azure CNI, you should use Kubernetes-native network policies to manage and restrict the traffic that can flow between pods, based on defined namespaces, labels, ports, and other granular controls. To avoid the possibility of attackers exploiting the host node from a compromised pod, create a network policy that blocks egress access from pods in all namespaces to the node metadata endpoint.
All incoming traffic to the pods should be front-ended by a Web Application Firewall (WAF), which could be the native Azure application gateway or a third-party solution, to protect from threats and infiltrations. For remote management tasks on the AKS nodes, use a jump box or SSH bastion host for secure access rather than exposing them via direct connectivity.
Managed clusters have become a go-to way to deploy and operate production Kubernetes workloads. This is partially due to the built-in services and features cloud service providers (CSPs) pack into their Kubernetes offerings. Our internal numbers show that about 83% of customers with Kubernetes have clusters managed by AKS, EKS, or GKE. Little is known, however, about the risks these additional services and features bring to the table. Whereas a vanilla Kubernetes distribution has been subject to a series of security assessments and threat models, CSP-specific cluster components remain overlooked by the security community. We call these components managed cluster middleware (MCM).
7. Integrate Azure Key Vault for secrets management
A distributed key-value store called etcd is used for Kubernetes secrets. In AKS, the etcd store is fully managed by Azure, and the data is encrypted at rest using Microsoft-managed encryption. However, if you want additional security, you can also opt for customer-managed encryption keys.
With the Azure Key Vault provider for Secrets Store CSI Driver, AKS clusters can be integrated with Azure Key Vault as a secrets store via a Container Storage Interface (CSI) volume. This driver supports synchronization of secrets as well as autorotation of mounted contents. Here’s how to integrate an AKS cluster with the Key Vault provider for Secrets Store CSI Driver:
az aks enable-addons --addons azure-keyvault-secrets-provider --name <<AKSClustername>> --resource-group <<ResourceGroupname>>
\8. Enable comprehensive monitoring and logging through Azure Monitor
AKS generates metrics and logs that you can analyze using native integration with Azure Monitor. Regularly review the information collated by Azure Monitor both on the data plane and control plane for any anomalies, especially logs such as AKSAudit, AKSAuditAdmin, and AKSControlPlane. Log Analytics facilitates detailed analysis of these logs. Configure security alerts based on metrics and logs to learn about issues right away.
AKS security beyond native solutions
All of the steps we’ve discussed provide first-level defense against possible attack vectors that could impact AKS clusters. However, enterprise-scale deployments demand more specialized solutions, such as those offered by Wiz.
Wiz’s cloud-native Kubernetes security solution can be used to scan your AKS clusters, providing full visibility into vulnerabilities associated with clusters, hosts, and pods. Wiz’s suite of tools helps correlate risk information from the cloud and runtime to provide a prioritized view of vulnerabilities, threats, and misconfigurations and also helps you early in the software development lifecycle to by scanning code and container images and additional guardrails to avoid deploying unsigned or untrusted images or misconfigured applications.
As the last line of defense, Wiz assists with both risk prevention and threat detection. Wiz uses a sensor to monitor each worker node and detect anomalies associated with executed commands, enumeration, and more. You can combine this information with Azure Audit and Entra ID logs from Azure to get a full context of threats and their proliferation, such as access to containers, used IMDS, and unauthorized data extraction.
In addition to ensuring deployment of signed containers, it is equally important to eliminate code-level vulnerabilities. Our Kubernetes security posture management (KSPM) solution can be used to scan YAML files to identify code-level vulnerabilities. Wiz covers the end-to-end spectrum from IaC to app code, with its scans of Docker files, Kubernetes manifest files, and Helm charts for misconfigurations as well as scans of application code and dependencies for vulnerabilities. And if you have compliance standards such as PCI DSS, HIPAA, and NIST, you can leverage the Wiz CIS benchmarking solution to implement CIS best practices using our automated out-of-the-box controls and rules—or create your own custom rules.
Schedule a Wiz demo to learn more about how we can help you secure your clusters with our unified, easy-to-use platform!
Detect real-time malicious behavior in Kubernetes clusters
Learn why CISOs at the fastest growing companies choose Wiz to secure their Kubernetes workloads.
Other security best practices you might be interested in:
