Network Policies w Kubernetes – kontrola ruchu sieciowego między kontenerami

Jednym z częstych błędnych założeń dotyczących Kubernetes jest przekonanie, że skoro aplikacje działają w osobnych Podach, to automatycznie są od siebie odizolowane.

W rzeczywistości domyślna komunikacja w Kubernetes jest bardzo otwarta.

Jeżeli dwa Pody znajdują się w tym samym klastrze, często mogą komunikować się ze sobą bez żadnych ograniczeń.

Przykład domyślnej sytuacji:

                 Kubernetes Cluster

        +---------------------------+

        Pod Frontend

              ↕

        Pod Backend

              ↕

        Pod Database

              ↕

        Pod Monitoring

        +---------------------------+

Problem?

Jeżeli atakujący przejmie jeden kontener, może próbować poruszać się dalej:

Compromised Pod

        ↓

Network Discovery

        ↓

Database Access

        ↓

Credential Theft

        ↓

Lateral Movement

Rozwiązaniem są Network Policies.

Czym są Network Policies?

Network Policy to mechanizm Kubernetes pozwalający definiować:

• kto może komunikować się z Podem,
• z jakich źródeł,
• na jakie porty,
• w jakim kierunku.

Można je traktować jako firewall dla ruchu pomiędzy kontenerami.

Model:

Source Pod

      |

      ↓

Network Policy

      |

      ↓

Destination Pod

Domyślne zachowanie Kubernetes

Standardowo:

Pod A  ─────────►  Pod B

ALLOW

Nie ma automatycznej izolacji.

Dlatego atakujący po przejęciu aplikacji może próbować:

• skanować inne Pody,
• łączyć się z bazami danych,
• wyszukiwać usługi wewnętrzne.

Network Policy działa na poziomie Podów

Network Policy nie działa jak klasyczny firewall IP.

Nie definiujemy:

192.168.1.20 → 192.168.1.30

Zamiast tego używamy:

• labels,
• namespaces,
• portów,
• selektorów.

Przykład:

Frontend

label:
app=frontend


Backend

label:
app=backend

Polityka mówi:

frontend

↓

może komunikować się z

↓

backend

Wymagany jest CNI z obsługą Network Policies

Samo Kubernetes API nie filtruje ruchu.

Potrzebny jest plugin sieciowy CNI.

Popularne rozwiązania:

• Calico,
• Cilium,
• Weave Net,
• Antrea.

Przykład:

Kubernetes

        ↓

NetworkPolicy API

        ↓

CNI Plugin

        ↓

Firewall Rules

Podstawowa Network Policy

Przykład:

Pozwól frontendowi komunikować się z backendem.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy

metadata:
  name: allow-frontend-to-backend

spec:

  podSelector:
    matchLabels:
      app: backend

  policyTypes:
  - Ingress

  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

    ports:
    - protocol: TCP
      port: 8080

Co oznacza?

Pod:

app=backend

akceptuje ruch:

app=frontend

na:

TCP 8080

Default Deny – najważniejsza praktyka

W produkcji często zaczyna się od:

Najpierw blokuj wszystko, potem otwieraj tylko potrzebny ruch.

Przykład:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy

metadata:
  name: default-deny

spec:

  podSelector: {}

  policyTypes:
  - Ingress
  - Egress

Efekt:

Pod A

X

Pod B

Cały ruch jest blokowany.

Następnie dodajemy wyjątki.

Izolacja warstw aplikacji

Przykład typowej aplikacji:

                 Internet

                    |

                    ↓

              Ingress Controller

                    |

                    ↓

              Frontend Pod

                    |

                    ↓

              Backend Pod

                    |

                    ↓

             Database Pod

Reguły:

Frontend:

Internet → Frontend
ALLOW

Backend:

Frontend → Backend
ALLOW

Database:

Backend → Database
ALLOW

Ale:

Frontend → Database

DENY

Namespace Isolation

Network Policies mogą ograniczać ruch między Namespace.

Przykład:

Mamy:

namespace:

production

development

testing

Bez zabezpieczeń:

development

↓

production database

jest możliwe.

Z Network Policy:

development

X

production

Komunikacja między Namespace

Przykład:

Pozwól tylko namespace:

frontend-team

łączyć się z:

backend

Policy:

from:

- namespaceSelector:

    matchLabels:

      team: frontend

Kontrola ruchu wychodzącego (Egress)

Network Policies mogą kontrolować również ruch wychodzący.

Przykład:

Aplikacja:

Backend Pod

nie powinna mieć dostępu do całego Internetu.

Możemy zezwolić tylko na:

api.payment.com

database.internal

logging.service

Przykład:

policyTypes:

- Egress

egress:

- to:
  - namespaceSelector:
      matchLabels:
        name: database

Dlaczego Egress jest ważny bezpieczeństwowo?

Wyobraźmy sobie przejęcie kontenera:

Attacker

↓

Compromised Pod

↓

Reverse Shell

↓

External Server

Jeżeli ruch wychodzący jest ograniczony:

Compromised Pod

↓

BLOCKED

atak jest znacznie trudniejszy.

Network Policies i DNS

Częsty problem:

Administrator blokuje cały Egress:

policyTypes:
- Egress

i nagle aplikacja przestaje działać.

Dlaczego?

Bo Kubernetes potrzebuje DNS.

Należy zezwolić na:

Pod

↓

CoreDNS

↓

DNS Resolution

Przykład:

ports:

- protocol: UDP
  port: 53

- protocol: TCP
  port: 53

Network Policies a bezpieczeństwo Zero Trust

Network Policies idealnie wpisują się w model:

Zero Trust

Zasada:

Nigdy nie ufaj domyślnie żadnemu komponentowi.

Schemat:

User

↓

Ingress

↓

Frontend

↓

Backend

↓

Database

Każde połączenie musi być jawnie dozwolone.

Network Policy vs klasyczny firewall

Cilium i eBPF – nowoczesne podejście

Nowoczesne klastry coraz częściej wykorzystują Cilium.

Wykorzystuje ono:

• eBPF,
• kernel Linux,
• zaawansowaną obserwowalność.

Schemat:

Application

↓

Network Policy

↓

eBPF Program

↓

Linux Kernel

↓

Packet Decision

Korzyści:

• większa wydajność,
• lepsza diagnostyka,
• widoczność ruchu.

Audyt Network Policies

Sprawdzenie:

kubectl get networkpolicy -A

Szczegóły:

kubectl describe networkpolicy policy-name

Sprawdzenie namespace:

kubectl get pods --show-labels

Najczęstsze błędy

❌ brak Network Policies w produkcji

❌ zezwolenie na cały ruch:

from:
- {}

❌ brak kontroli Egress

❌ zapomnienie o DNS

❌ brak izolacji Namespace

❌ używanie IP zamiast labeli

Najlepsze praktyki

✅ rozpocznij od Default Deny

✅ zezwalaj tylko na wymagany ruch

✅ kontroluj Ingress i Egress

✅ używaj labeli zamiast adresów IP

✅ izoluj środowiska produkcyjne

✅ monitoruj komunikację między Podami

✅ testuj polityki przed wdrożeniem

Bezpieczna architektura sieci Kubernetes

                 Internet

                    |

                    ↓

             Ingress Controller

                    |

              Network Policy

                    |

        +-----------------------+

        |       Frontend        |

        +-----------------------+

                    |

              Allowed Traffic

                    |

        +-----------------------+

        |       Backend         |

        +-----------------------+

                    |

              Allowed Traffic

                    |

        +-----------------------+

        |      Database         |

        +-----------------------+

Podsumowanie

Network Policies są jednym z fundamentów bezpieczeństwa Kubernetes.

Sam fakt, że aplikacja działa w kontenerze, nie oznacza, że jest odpowiednio odizolowana. Bez kontroli ruchu sieciowego przejęcie jednego Poda może stać się początkiem większego ataku.

Profesjonalny klaster Kubernetes powinien stosować:

• Default Deny,
• ograniczenie komunikacji między usługami,
• kontrolę Egress,
• izolację Namespace,
• polityki zgodne z zasadą Zero Trust.

Najważniejsza zasada:

W Kubernetes nie powinno istnieć połączenie sieciowe, którego nie potrafisz uzasadnić.

Polecane wpisy

Co to jest RAID?

RAID to w skrócie technologia pozwalająca na zwiększenie wydajności lub bezpieczeństwa przechowywanych danych. Skrót RAID oznacza Redundant Array of Independent Czytaj dalej

Jak zwiększyć FPS w grach Windows 10

Aby zwiększyć ilość klatek na sekundę (FPS) w grach na systemie Windows 10, można podjąć kilka kroków optymalizacyjnych. Oto kilka Czytaj dalej