Azure Kubernetes Service (AKS) is Microsoft’s popular, cloud-based, managed Kubernetes service. As with any Kubernetes service, as a user of AKS you still have to devise a Kubernetes security and observability plan for your clusters.
To secure an AKS deployment, you should make use of built-in security features in AKS, and follow basic security best practices, of which the main ones are covered below. In addition, you should be aware of secure configurations recommended by security research bodies, such as the Center for Internet Security (CIS) Kubernetes Benchmark.
Microsoft provides, manages, and maintains the Kubernetes master components as part of the AKS managed service. AKS clusters each have their own single-tenant Kubernetes master that provide features such as the API Server and Kubernetes Scheduler.
In AKS, the Kubernetes API server has a public IP and domain name. If you need to restrict API access, you can limit access to specific IP ranges, or create private clusters inside an Azure Virtual Network. Direct control over the API server is managed via Azure role-based access control (RBAC) and Kubernetes RBAC.
In AKS, Kubernetes worker nodes run on Azure VM. In an AKS cluster, nodes are deployed automatically with the latest OS security configurations and updates. When Kubernetes clusters require more capacity, AKS scales up automatically by adding more nodes.
Linux nodes are automatically updated with OS security patches every night. However, if a security update requires the host to be rebooted, the reboot won’t be automatic. You can reboot the Linux nodes manually or, alternatively, use Kured (a reboot daemon that monitors nodes and performs reboot automatically when required).
You can schedule upgrades for your Windows Server node pool in an AKS cluster based on the normal Windows Update release cycle, with a validation process that you define. This process involves creating nodes with the latest patches and removing nodes running the previous Windows Server version.
Azure offers tools for orchestrating upgrades of AKS clusters and components to the latest version of Kubernetes. This can help you maintain compliance and security and gain access to the latest Kubernetes features. Both Kubernetes masters and agents are included in this upgrade orchestration.
To initiate the upgrade process, you specify an available Kubernetes version and Azure then drains and upgrades each AKS node.
If you have existing Azure Virtual Network subnets connected to your on-premises network, you can deploy AKS clusters to the same subnets, to enable secure connectivity with on-premises resources. Azure Virtual Networks connect to your on-premises network via Azure Site-to-Site VPN or ExpressRoute. If you want to ensure services can only access addresses in your internal network, you can set ingress controllers to allow only internal IP addresses.
Azure Virtual Networks (VNets) filter traffic flows using security groups, which either allow or disallow IP ranges and ports you define. By default, all traffic to and from the API Server is encrypted using Transport Layer Security (TLS). You can create services with port mappings, ingress routes, or load balancers.
Here are five best practices that can help you enhance security for your AKS clusters.
Limit network traffic using AKS network policies. Define ingress and egress traffic rules based on label selectors and namespaces.
When AKS clusters are created, network security groups and route tables are automatically created by default. AKS automatically connects network security groups to virtual network interface cards (NICs) on worker nodes. The Azure Container Networking Interface (CNI) plugin is required to use network policies, and must be enabled when a cluster is created.
The Azure Application Gateway includes a Web Application Firewall (WAF), which you can use to identify and block malicious traffic to your web application. It provides a set of rules that can prevent attacks like cross-site scripting (XSS), cookie poisoning, and other common web application attacks.
Azure API Management, Microsoft’s API gateway service, can help authenticate, authorize, and monitor APIs. API gateways make it easier to handle administrative and security tasks common to all your APIs.
Ensure you have an audit trail for the Kubernetes control plane, by enabling audit logs for kube-apiserver and kube-controller-manager. It is highly recommended to use kube-audit as well.
Export the logs to a storage platform like Azure Monitor’s Log Analytics. Azure Monitor can help you analyze historical logs. Use Azure Storage accounts to manage long-term storage and ensure you use archival storage tiers to reduce the cost of log storage.
Related content: Read our guide to Kubernetes observability
Regularly review AKS configuration templates—you can export these in JSON format from Azure Resource Manager (ARM). It is important to review security policies for all AKS instances and define custom policies that meet your security requirements.
You can start from definitions built into Azure Policy aliases in the “Microsoft.ContainerService” namespace. Make sure you enforce HTTPS ingress in Kubernetes clusters and apply RBAC. Also ensure you implement recommendations from Azure Security Center.
Use a vulnerability scanner to ensure that the containers you use are free of known software vulnerabilities. You can use the Azure scanner or another paid or open-source scanner. Choose a solution that covers the languages your software uses.
Scan any third-party container images you deploy in your cluster, as well as your own custom images, to avoid tampering or unintentional use of vulnerable components.
The scanner should regularly scan all images deployed to your clusters and keep an updated database of Common Vulnerabilities and Exposures (CVEs). Establish a policy for addressing CVEs when they are discovered, with alerts for fixable CVEs built into your CI/CD pipeline.
Related content: Read our guide to recent Kubernetes vulnerabilities
A typical cloud-native application might run on any combination of Windows containers, Linux containers, public and private clouds—each of which uses a different approach to network policy and security. As the Kubernetes ecosystem grows, this siloed, fragmented approach cannot scale, making it harder for developers, service owners, and cluster operators to secure, observe, and troubleshoot these heterogeneous environments.
With Calico Cloud and Calico Enterprise for AKS, organizations can leverage the power and simplicity of Calico to enable a single solution for security and observability that works uniformly across cloud and on-premises environments, running Windows and Linux based container workloads.
This means users can deploy and manage a consistent set of security policies across both Windows and Linux servers hosting Kubernetes clusters on the Microsoft Azure cloud and AKS.
With Microsoft and Tigera, you can address most common use cases for Kubernetes networking, security, and observability in Microsoft Azure and AKS for both Windows and Linux environments.
Get updates on blog posts, workshops, certification programs, new releases, and more!
