NetworkPolicy to zasób Kubernetes definiujący, które pody mogą komunikować się ze sobą w ruchu wchodzącym i wychodzącym. Bez zdefiniowanych polityk domyślnie wszystkie pody w klastrze mogą swobodnie komunikować się między sobą — co jest wygodne na starcie, ale w produkcyjnym środowisku wielozespołowym staje się poważnym ryzykiem bezpieczeństwa.
Na skróty
Czego dowiesz się z artykułu:
- Czym są NetworkPolicy i dlaczego domyślny “flat network” w Kubernetes jest ryzykowny
- Kto w organizacji powinien pisać, przeglądać i utrzymywać polityki sieciowe
- Jak podzielić odpowiedzialność między platform team a zespoły aplikacyjne
- Jakich błędów unikać, żeby polityki nie stały się martwym, nieaktualizowanym YAML-em
Dla kogo ten artykuł: platform engineerzy, DevOps/SRE odpowiedzialni za klaster Kubernetes, tech leadzi zespołów aplikacyjnych korzystających z klastra współdzielonego.
Czas czytania: 6 minut
Polityki sieciowe NetworkPolicy w Kubernetes
Dokumentacja Kubernetes jasno wskazuje, że NetworkPolicy jest egzekwowana przez wtyczkę sieciową (CNI plugin) — sam obiekt NetworkPolicy w klastrze bez CNI wspierającego ten mechanizm (np. Calico, Cilium) nie ma żadnego efektu. To pierwszy błąd, jaki popełniają zespoły: piszą polityki, wdrażają je, a klaster i tak przepuszcza cały ruch, bo domyślny CNI (np. podstawowy flannel) ich nie egzekwuje.
Druga fundamentalna zasada: polityka NetworkPolicy działa na zasadzie “default deny, explicit allow”. Jeśli żadna polityka nie wybiera danego poda, cały ruch do niego jest dozwolony. Dopiero od momentu, gdy pierwsza polityka zaczyna go dotyczyć, obowiązuje reguła: wszystko, co nie jest jawnie dozwolone, jest zablokowane.
Kto powinien pisać i utrzymywać polityki sieciowe?
| Rola | Odpowiedzialność | Dlaczego |
|---|---|---|
| Platform / Infrastructure team | Polityki bazowe klastra (namespace izolacja, deny-all domyślny, dostęp do DNS/monitoringu) | Wymaga wiedzy o architekturze całego klastra i konsekwencjach globalnych |
| Zespół aplikacyjny | Polityki specyficzne dla swojego namespace (dostęp do konkretnych serwisów, portów) | Zna rzeczywisty ruch swojej aplikacji, nie musi znać całego klastra |
| Security / DevSecOps | Przegląd i audyt polityk, egzekwowanie standardu (np. przez OPA/Gatekeeper) | Zapewnia spójność i wyłapuje luki między namespace’ami |
Kluczowy podział: platform team dostarcza bazowy szablon “deny-all + wyjątki na DNS i monitoring” dla każdego nowego namespace, a zespół aplikacyjny dopisuje własne, szczegółowe reguły w ramach tego szkieletu. Bez tego podziału albo platform team staje się wąskim gardłem dla każdej zmiany, albo zespoły aplikacyjne zostawiają namespace całkowicie otwarty, bo “nikt nie ma czasu tego napisać”. Sprawdzonym rozwiązaniem pośrednim jest wspólny przegląd polityk w formie krótkiego cotygodniowego spotkania, na którym platform team i przedstawiciele zespołów aplikacyjnych wspólnie analizują odrzucony ruch i decydują, czy wymaga on nowej reguły, czy jest sygnałem błędu w aplikacji.
Krok po kroku: wdrożenie polityk w zespole wielozespołowym
- Zacznij od audytu — sprawdź, które CNI jest zainstalowane w klastrze i czy wspiera NetworkPolicy.
- Wdróż domyślne “deny-all” na poziomie namespace, z jawnymi wyjątkami dla DNS (port 53) i systemu monitoringu.
- Deleguj szczegóły do zespołów aplikacyjnych — dostarcz szablon polityki, który wypełniają własnymi regułami dostępu do serwisów.
- Wprowadź przegląd polityk w code review — traktuj plik NetworkPolicy tak samo jak kod aplikacji, z wymaganym zatwierdzeniem.
- Monitoruj odrzucony ruch — narzędzia takie jak Cilium Hubble pozwalają zobaczyć, co faktycznie zostało zablokowane, zanim wdrożysz politykę na produkcji.
Typowe błędy przy wdrażaniu
- Brak CNI wspierającego NetworkPolicy — polityka istnieje w klastrze, ale nic jej nie egzekwuje, co daje fałszywe poczucie bezpieczeństwa.
- Polityki pisane raz i zapominane — nowa wersja aplikacji dodaje nowy port lub serwis, a polityka nigdy nie zostaje zaktualizowana, więc ruch jest po prostu blokowany albo (gorzej) polityka jest usuwana “żeby zadziałało”.
- Brak testowania w trybie audytu — wdrożenie “deny-all” bez wcześniejszej analizy ruchu potrafi natychmiast zerwać komunikację między serwisami na produkcji.
- Traktowanie NetworkPolicy jako wyłącznie zadania platform teamu — bez wiedzy zespołu aplikacyjnego o rzeczywistym ruchu polityki są albo zbyt restrykcyjne, albo zbyt otwarte.
Warto też pamiętać, że polityki sieciowe to tylko jedna warstwa bezpieczeństwa klastra — działają najlepiej w połączeniu z RBAC ograniczającym dostęp do API oraz z politykami bezpieczeństwa podów. Traktowanie NetworkPolicy jako jedynej linii obrony jest samo w sobie błędem architektonicznym.
Przeczytaj również
Rozwiń kompetencje
Chcesz pogłębić wiedzę o Kubernetes w praktyce? Sprawdź nasze szkolenia prowadzone przez doświadczonych trenerów EITT.
➡️ Amazon EKS (AWS EKS) — Kubernetes w chmurze AWS — szkolenie EITT ➡️ Argo CD — ciągłe wdrażanie dla Kubernetes — szkolenie EITT
Najczęściej zadawane pytania
Czy NetworkPolicy działa od razu po utworzeniu obiektu w klastrze?
Nie zawsze. NetworkPolicy jest egzekwowana przez wtyczkę sieciową (CNI), więc jeśli klaster korzysta z CNI, który nie implementuje tego mechanizmu, sam obiekt NetworkPolicy istnieje w klastrze, ale nie ma żadnego efektu na ruch sieciowy. Zanim zaczniesz pisać polityki, sprawdź, czy Twój CNI je wspiera.
Kto powinien być właścicielem polityk sieciowych w organizacji z wieloma zespołami?
Najlepiej sprawdza się podział warstwowy: platform team dostarcza bazowy szablon “deny-all” z wyjątkami systemowymi dla każdego namespace, a zespoły aplikacyjne dopisują własne, szczegółowe reguły w ramach tego szkieletu. Centralizacja całości w jednym zespole tworzy wąskie gardło, a pełna decentralizacja bez standardu prowadzi do niespójności i luk bezpieczeństwa.
Co się stanie, jeśli wdrożę politykę “deny-all” bez wcześniejszego audytu ruchu?
Ryzykujesz natychmiastowe zerwanie komunikacji między serwisami, które wcześniej działały bez ograniczeń — łącznie z dostępem do DNS, co potrafi wyglądać jak awaria całej aplikacji. Zanim wdrożysz restrykcyjną politykę na produkcji, przetestuj ją w trybie audytu lub na środowisku staging i przeanalizuj rzeczywisty ruch narzędziem obserwowalności.
Jak często należy przeglądać i aktualizować polityki NetworkPolicy?
Polityki powinny być traktowane jak kod aplikacji — aktualizowane przy każdej zmianie architektury (nowy serwis, nowy port, zmiana zależności) i przechodzić przez code review na równi z resztą zmian w repozytorium. Warto też wprowadzić okresowy audyt kwartalny, żeby wyłapać polityki, które przestały odzwierciedlać rzeczywisty ruch aplikacji.