Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Network security provides an additional layer of defense for your Kubernetes clusters. This article discusses how to use network policies, infrastructure configuration, and Azure-specific features to control traffic flow, segment workloads, and help protect communications. Implementing these measures helps reduce the attack surface and limit unauthorized access to your resources.
Configure Kubernetes network policy to control access to/from your workloads
In addition to helping to protect your cluster's workload data traffic via TLS, you can help further protect it by creating network policies. These policies control the pods, namespaces, and IP addresses from which ingress requests can be received, and to which egress requests can be sent. You need to deploy a Network Policy Engine to enforce these policies. Evaluate if you can use the Calico or Cillium engines in your cluster.
References
- CIS Kubernetes Benchmark - Sections 1, 2, and 4
- NIST Application Container Security Guide - Section 4.5.1-3
- NSA Kubernetes Hardening Guidance - "Network policies"
- Kubernetes Security - OWASP Cheat Sheet Series - "Use Kubernetes network policies to control traffic"
Use Azure Private Link (preview) to access Azure resources
In addition to helping protect your traffic to Azure with TLS and Workload Identity Federation, also consider using Azure Private Link for Arc-enabled clusters (preview). This feature sets up private endpoints inside your cloud virtual network for Azure Arc, and other services such as Azure Key Vault. This network itself can then be connected to your premises using site-to-site VPN or ExpressRoute circuit. Evaluate the advantages and current limitations to decide if this solution works for you.
Next steps
- Return to the top of this security book