Implementacja polityk sieciowych

In Kubernetes, by default, all pods can communicate with each other. While convenient, this 'flat' network model can be a security risk, especially in multi-service environments.

Network Policies act like firewalls for your pods, allowing you to define rules for how they can communicate both internally and externally.

Imagine a backend database pod that only your API service should access. Without Network Policies, any other pod in the cluster could potentially connect to it.

• Isolation: Prevent unauthorized access between services.
• Security: Enforce least privilege, allowing only necessary connections.
• Compliance: Meet security standards by segmenting network traffic.

A Network Policy is a Kubernetes resource that uses labels to select pods and then defines rules specifying what network traffic is allowed to and from those selected pods.

These policies are enforced by the Container Network Interface (CNI) plugin installed in your cluster (e.g., Calico, Cilium, Weave Net).

A Network Policy is defined using a YAML manifest, just like other Kubernetes resources. Here's a basic structure:

• apiVersion and kind: Identifies it as a Network Policy.
• metadata: Contains its name and optional labels.
• spec: Where the actual policy rules are defined.

The spec.podSelector field is crucial. It defines which pods this policy will apply to. It uses label selectors to match pods within the same namespace where the policy is created.

An empty podSelector: {} selects all pods in the namespace.

The spec.policyTypes field specifies whether the policy applies to incoming (Ingress), outgoing (Egress), or both types of traffic for the selected pods.

• Ingress: Controls traffic coming into the selected pods.
• Egress: Controls traffic going out of the selected pods.

If omitted, it defaults to Ingress.

The spec.ingress section defines rules for incoming traffic. Each rule specifies allowed sources, which can be:

• Other pods (using podSelector).
• Namespaces (using namespaceSelector).
• IP CIDR blocks (using ipBlock).
• Specific ports (using ports).

If a pod is selected by a Network Policy with policyTypes: [Ingress], all incoming traffic is denied by default, unless explicitly allowed by an ingress rule.

Similarly, the spec.egress section defines rules for outgoing traffic from the selected pods. It specifies allowed destinations, using the same selectors as ingress rules (to.podSelector, to.namespaceSelector, to.ipBlock, and ports).

If a pod is selected by a Network Policy with policyTypes: [Egress], all outgoing traffic is denied by default, unless explicitly allowed by an egress rule.

Let's create a policy to isolate a pod labeled app: backend. This policy will deny all incoming traffic to it by default.

By just specifying policyTypes: [Ingress] and an empty ingress: [] array, we explicitly deny all incoming connections.

Now, let's refine the previous policy. We still want to deny all ingress to our app: backend pod, but we'll add a rule to allow incoming traffic specifically from pods labeled app: frontend.

You have an application pod labeled app: data-processor. You need to ensure it can only initiate connections to an external logging service at 192.168.1.10/32 on port 514, and no other outgoing traffic is allowed. Which key parts of a Network Policy would you configure?

You've learned how Kubernetes Network Policies provide crucial security and isolation for your applications!

• Network Policies act as internal firewalls for pods.
• They use podSelector to target specific pods.
• policyTypes defines if rules apply to Ingress, Egress, or both.
• ingress and egress sections define the actual allow rules, implicitly denying everything else.

By implementing Network Policies, you can significantly enhance the security posture of your Kubernetes applications.