This is the first part of two blog posts on AKS network isolation. First, I’ll elaborate on how to protect AKS from a networking perspective. In part 2, I’ll describe how to still access your cluster for your own management e.g. for CI/CD. You’ll see me use Terraform, PowerShell, Azure CLI, Azure Pipelines, Kusto & Cloud init. The complete solution for part 1 is on GitHub: geekzter/azure-aks: Network Isolated AKS (github.com).
When you create an Azure Kubernetes Service (AKS) in the Azure Portal, or with tools such as the Azure CLI, the default configuration will be open in the sense of traffic (both application & management) traversing public IP addresses. This is a challenge in Enterprise, especially in regulated industries. Effort is needed to control all network paths, and in the case of AKS there are quite a few moving parts to consider.
AKS supports two networking ‘modes’. These modes control the IP address allocation of the agent nodes in the cluster. In short:
I won’t go into detail of these modes, as the network mode is largely irrelevant for the isolation controls you need to implement. Choosing one over the other does not make a significant difference for network isolation. I tested with Azure CNI.
#networking #kubernetes #ak #terraform #security