NetworkPolicy
最后更新于
最后更新于
With the rise of microservices, an increasing number of cloud service platforms are becoming dependent on network communication between numerous modules. Introduced in Kubernetes 1.3, Network Policy provides policy-based network control to isolate applications and reduce attack surfaces. It employs label selectors to simulate traditional segmented networks, controlling traffic between them and managing incoming traffic from external sources.
When working with Network Policy, keep in mind:
Version 1.6 and earlier require extensions/v1beta1/networkpolicies to be enabled in kube-apiserver.
As of version 1.7, Network Policy has reached General Availability (GA) with the API version networking.k8s.io/v1.
Version 1.8 introduced support for Egress and IPBlock.
Version 1.21 adds endPort support for setting the port range (requires configuration --feature-gates=NetworkPolicyEndPort=true).
Network plugins such as Calico, Romana, Weave Net, and trireme that support Network Policy are needed. Refer here for more details.
| Kubernetes Version | Networking API Version |
|---|---|
By default, all Pods can freely communicate with each other. Each Namespace can configure an independent network policy to isolate traffic between Pods.
On v1.7+ versions, creating a Network Policy that matches all Pods serves as the default network policy, such as the default rejection of all Ingress communication between Pods.
On the flip side, v1.6 uses Annotations to isolate traffic between all the Pods in a namespace from all Pods' external traffic to the namespace and traffic between Pods within the namespace.
It is possible to manage traffic between Pods using label selectors, including namespaceSelector and podSelector. For instance, the following Network Policy does the following:
Allows Pods with the role=frontend label in the default namespace to access TCP port 6379 of Pods with the role=db label in the default namespace.
Allows all Pods in namespaces with the project=myprojects label to access TCP port 6379 of Pods with the role=db label in the default namespace.
To see Network Policy in action, let's utilize calico as an instance.
First, configure kubelet to use the CNI network plugin.
Install the calico network plugin.
Then, deploy an nginx service. At this point, nginx can be accessed by other Pods.
When we enable the DefaultDeny Network Policy for the default namespace, other Pods (including those outside of the namespace) can't reach nginx anymore:
At last, by implementing a network policy that allows access from Pods labelled with access=true, only authorized Pods are able to communicate with the nginx service.
The network policy denies every other Pod from sending traffic to the appointed service.
The network policy allows only specified Pods to send traffic to the appointed service.
Disables the ability for Pods within the same namespace to communicate with each other.
The network policy restricts all Pods outside the namespace from reaching an assigned service.
The network policy allows only certain namespaces to send traffic to the designated service.
The applied network policy allows traffic from the external network to reach a specific service within the Kubernetes cluster.
While Network Policy covers a wide spectrum of applications, there are certain scenarios it does not support, including:
Forcing intra-cluster traffic to pass through a common gateway.
Situations related to Transport Layer Security (TLS).
Policies specific to nodes.
Policies that identify targets based on names.
Generating network security event logs.
Blocking localhost access or access requests from the hosting node.
Here are some resources that provide more information on Network Policies in Kubernetes:
v1.5 - v1.6
extensions/v1beta1
v1.7+
networking.k8s.io/v1