Description
Kubernetes network policies restrict communication between workloads. Both a network configuration that enforces policy and actual NetworkPolicy resources are needed; selecting an engine alone does not automatically restrict traffic.
Potential impact
- Unnecessary communication between pods can remain allowed.
- A compromised workload may be able to reach more services.
Remediation
- Choose a supported policy engine compatible with the network plugin and data plane. AzureRM supports
azure,calicoandcilium; check the requirements for the chosen combination. - Define pod selectors and ingress/egress rules while allowing required traffic such as DNS. Test that required communication works and unwanted communication is blocked.
Examples
These Azure CNI examples specify the required network_plugin. After selecting the Azure network policy engine, define separate NetworkPolicy resources for the workloads.
Before
hcl
resource "azurerm_kubernetes_cluster" "example" {
name = "example-aks1"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
dns_prefix = "exampleaks1"
default_node_pool {
name = "default"
node_count = 1
vm_size = "Standard_D2_v2"
}
identity {
type = "SystemAssigned"
}
network_profile {
network_plugin = "azure"
}
}
After
hcl
resource "azurerm_kubernetes_cluster" "example" {
name = "example-aks1"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
dns_prefix = "exampleaks1"
default_node_pool {
name = "default"
node_count = 1
vm_size = "Standard_D2_v2"
}
identity {
type = "SystemAssigned"
}
network_profile {
network_plugin = "azure"
network_policy = "azure"
}
}
Explanation:
- Before: No policy engine is specified. Check actual network capabilities and workload traffic restrictions.
- After: The Azure policy engine is selected. This setting alone does not define each pod’s allowed traffic.