Questão de Networking #019e3a4f

A NetworkPolicy in Kubernetes is a resource that controls traffic flow to and from pods. It allows you to define rules that specify which pods can communicate with each other and with external endpoints. The correct role is to classify pods as isolated or non-isolated. By default, pods are non-isolated and accept traffic from any source. When a NetworkPolicy selects a pod, that pod becomes isolated, and only traffic that matches the policy rules is allowed. This classification is fundamental to implementing network segmentation and security in a Kubernetes cluster.

How it Works

NetworkPolicies are implemented by a network plugin (e.g., Calico, Cilium, Flannel with network policy support). The policy uses label selectors to target pods and defines ingress and egress rules. For example, a policy can allow traffic only from pods with a specific label or from a specific IP range. The isolation concept is key: once a pod is selected by any NetworkPolicy, it is isolated and all traffic not explicitly allowed is denied.

Why the Correct Value is Right

The ability to classify pods as isolated or non-isolated is the core function of a NetworkPolicy. It enables fine-grained control over pod communication, which is essential for security and compliance in multi-tenant clusters.

Why the Incorrect Values are Wrong

• The ability to cryptic and obscure all traffic: NetworkPolicies do not encrypt or obscure traffic; they only filter it. Encryption is handled by other mechanisms like TLS or mTLS (e.g., with Istio).
• The ability to prevent loopback or incoming host traffic: NetworkPolicies operate at the pod network level, not on host interfaces or loopback. They cannot prevent traffic on the host network or loopback interface.
• The ability to log network security events: NetworkPolicies themselves do not generate logs. Logging is typically done by network plugins or monitoring tools (e.g., using audit policies or flow logs).