Politiques réseau dans les conteneurs

In Kubernetes, Network Policies are like firewalls for your pods. They control how groups of pods communicate with each other and with external network endpoints.

Think of them as a security layer that defines which connections are allowed or denied, enhancing isolation and security.

Without Network Policies, all pods in a Kubernetes cluster can communicate with each other by default. This can be a significant security risk!

• Isolation: Prevent unauthorized access between different application tiers (e.g., frontend talking directly to a sensitive database).
• Security: Reduce the attack surface by only allowing necessary connections.
• Compliance: Help meet regulatory requirements for network segmentation.

Network Policies work by selecting specific pods and then defining rules for allowed inbound (ingress) and outbound (egress) traffic for those pods.

They are enforced by the cluster's Container Network Interface (CNI) plugin (like Calico or Cilium). If no policy selects a pod, all traffic to/from it is allowed by default.

A Network Policy is a Kubernetes resource defined in YAML. It specifies:

• podSelector: Which pods the policy applies to.
• policyTypes: Whether the policy affects ingress, egress, or both.
• ingress/egress rules: The specific allowed connections.

Here's the basic YAML structure:

The podSelector is crucial. It uses labels to identify the pods that this policy will apply to.

If podSelector is empty {}, the policy applies to ALL pods in its namespace. If omitted, the policy applies to no pods.

The policyTypes field specifies if the policy governs `Ingress`, `Egress`, or both. This helps the network plugin know which traffic directions to enforce.

Ingress rules define what traffic is allowed to enter the selected pods. If an ingress rule is present, only traffic matching that rule is permitted; all other ingress traffic is denied.

You can specify allowed traffic based on:

• from: The source of the traffic (e.g., IP block, namespace, or other pods).
• ports: Specific destination ports on the selected pods.

Egress rules define what traffic is allowed to leave the selected pods. Similar to ingress, if an egress rule is present, only traffic matching that rule is permitted; all other egress traffic is denied.

You can specify allowed traffic based on:

• to: The destination of the traffic (e.g., IP block, namespace, or other pods).
• ports: Specific source ports on the selected pods.

A common security practice is to implement a "default deny" policy. This means no traffic is allowed to a pod unless explicitly permitted.

To achieve this for ingress traffic, create a policy that selects the desired pods but has an empty ingress rule list. This explicitly denies all incoming traffic.

After a default deny, you can add more specific policies to allow necessary traffic. Here, we allow backend pods to receive traffic on port 80 from frontend pods.

This policy targets pods with app: backend and permits ingress from pods labeled app: frontend on TCP port 80.

Consider a pod with label app: database. You want to block all incoming traffic to it, except from pods with label app: backend.

You've learned about Kubernetes Network Policies!

• They provide firewall-like rules for pods.
• They use podSelector to target pods and define ingress/egress rules.
• By default, all pods can communicate; policies enforce restrictions.
• They are essential for securing and isolating containerized applications.

Keep practicing with different policy rules to master container security!