Generator Kubernetes NetworkPolicy

Generator NetworkPolicy dla Kubernetes

Domyślnie wszystkie pody w klastrze mogą się komunikować. NetworkPolicy pozwala to ograniczyć — działa jak zapora sieciowa dla podów.

Struktura polityki

Biała lista

Polityka działa jak lista dozwolonych — jeśli ją ustawisz, cały ruch nieujęty w regułach zostanie zablokowany. Samotna polityka bez reguł blokuje wszystko.

Przykład

Pody app: web przyjmują ruch na porcie 80 tylko od podów app: frontend. Reszta ruchu przychodzącego jest odrzucana.

Jak działa izolacja ruchu w NetworkPolicy

NetworkPolicy to obiekt przypisany do namespace, który najpierw wybiera pody za pomocą podSelector (dopasowanie po etykietach), a następnie opisuje, jaki ruch jest dla nich dozwolony. Sam generator nie filtruje niczego — produkuje manifest, który wtyczka sieciowa (Calico, Cilium, Weave) zamienia na reguły po stronie węzłów. Jeśli wtyczka nie obsługuje NetworkPolicy, obiekt zapisze się w API, ale ruch pozostanie niefiltrowany.

Kluczowa jest zależność między policyTypes a domyślnym zachowaniem. Wpisanie Ingress włącza blokowanie całego ruchu przychodzącego do wybranych podów i przepuszcza wyłącznie to, co pasuje do reguł w sekcji ingress. Wpisanie Egress robi to samo dla ruchu wychodzącego. Kierunek, którego nie ma w policyTypes, nie jest przez tę politykę ograniczany, choć nadal mogą go ograniczać inne polityki dotyczące tego samego poda.

Dopasowanie wewnątrz reguły działa dwupoziomowo. Reguła ingress składa się z listy from oraz listy ports. Ruch pasuje wtedy, gdy źródło pasuje do któregokolwiek elementu z listy from (podSelector, namespaceSelector lub ipBlock) ORAZ port pasuje do któregokolwiek wpisu z listy ports. Wiele reguł w jednej polityce oraz wiele polityk obejmujących ten sam pod sumuje się: wystarczy, że warunek spełni jedna z nich.

Przykład krok po kroku: web przyjmuje ruch tylko z frontendu

1. W generatorze w polu podSelector wpisujesz etykietę app: web. Ta etykieta decyduje, które pody w namespace obejmuje polityka — pozostałe pody zostają bez zmian.
2. W policyTypes zaznaczasz dwa kierunki: Ingress i Egress. Od tego momentu cały ruch przychodzący i wychodzący wybranych podów jest blokowany, dopóki nie dodasz reguł.
3. Dodajesz regułę ingress: w polu from wybierasz podSelector app: frontend, a w polu ports wpisujesz port 80 i protokół TCP. Zezwolenie dotyczy tylko podów z etykietą frontend w tym samym namespace.
4. Dodajesz regułę egress ze namespaceSelector wskazującym namespace, w którym działa DNS klastra. Bez tej reguły pody nie rozwiążą nazw, bo zapytania DNS są ruchem wychodzącym.
5. Generujesz manifest i sprawdzasz wynik: jedna polityka, 1 wartość w podSelector, 2 wpisy w policyTypes, 1 reguła ingress i 1 reguła egress. Ruch na port 80 z podów app: frontend przechodzi.
6. Każdy inny ruch przychodzący do podów app: web jest odrzucany, a ruch wychodzący poza wskazany namespace również. Po zapisie manifestu weryfikujesz to testowym połączeniem z poda frontend i z poda spoza reguły — drugie zakończy się przekroczeniem czasu.

Pola manifestu i ich wpływ na wynik

Praktyczne wskazówki przy generowaniu polityki

• Zacznij od jednego namespace. Wdrożenie domyślnej blokady w całym klastrze naraz utrudnia znalezienie reguły, która odcięła ruch — testuj politykę najpierw w wyizolowanym namespace.
• Nie zapomnij o DNS w egress. Gdy ustawiasz Egress, dodaj regułę zezwalającą na ruch do DNS, inaczej pody nie rozwiążą nazw usług i awarie będą wyglądać jak problem z aplikacją.
• Rozróżniaj brak sekcji od pustej listy. Brak sekcji ingress przy policyTypes z Ingress daje tę samą blokadę co pusta lista — wybierz jawnie tę wersję, którą łatwiej odczytać w przeglądzie kodu.
• Etykietuj pody przed wdrożeniem. Selektor to zwykły tekst; jeśli pody nie mają pasującej etykiety, polityka nie obejmie niczego i nie zobaczysz żadnego efektu.
• Trzymaj polityki blisko aplikacji. Manifest dla danego zespołu usług umieszczaj w tym samym repozytorium co jego wdrożenie, żeby zmiana etykiet nie zostawiła polityki bez podów.

Czego narzędzie nie uwzględnia

• Brak wiedzy o wtyczce sieciowej. Generator nie sprawdza, czy klaster obsługuje NetworkPolicy — na klastrach bez wsparcia manifest zostanie zapisany, ale ruch nie będzie filtrowany.
• Nie weryfikuje etykiet w klastrze. Narzędzie nie łączy się z API, więc literówka w nazwie etykiety daje politykę, która nie obejmuje żadnego poda.
• Nie analizuje pozostałych polityk. Rzeczywisty wynik dla poda to suma wszystkich polityk, które go obejmują — generator opisuje tylko tę jedną tworzoną politykę.
• Tylko porty i protokoły. Reguły warstwy 7, nazwy domenowe czy tożsamości usług nie są uwzględniane, nawet jeśli używana wtyczka potrafi je obsłużyć.

Najczęstsze pytania