W projektach opartych o Kubernetes w chmurze Azure, jednym z częstszych błędów, które obserwujemy podczas audytów i wdrożeń, jest brak kontroli ruchu sieciowego między podami.

Domyślnie Kubernetes pozwala wszystkim komponentom komunikować się ze sobą, co w praktyce oznacza brak separacji logicznej, a tym samym potencjalny problem zgodności z regulacjami (RODO, NIS2, DORA, ISO 27001).

Z naszego doświadczenia wynika, że Network Policies w Azure Kubernetes Service (AKS) to nie tylko mechanizm techniczny, ale również realna warstwa kontroli security & governance.

W dobrze zaprojektowanym środowisku polityki sieciowe stają się częścią modelu Zero Trust i są bezpośrednim dowodem na egzekwowanie zasad bezpieczeństwa w audycie.

Dlaczego Network Policies mają znaczenie

Każdy, kto kiedykolwiek diagnozował ruch wewnętrzny w klastrze produkcyjnym wie, że bez odpowiednich reguł łatwo o sytuację, w której komponent frontendowy może skomunikować się z bazą danych lub usługą administracyjną, mimo że nie powinien.

W realnych wdrożeniach zauważam, że:

• – izolacja namespace’ów jest często pomijana,
• – ruch egress (na zewnątrz) nie jest w żaden sposób kontrolowany,
• – a same reguły bezpieczeństwa kończą się na poziomie Azure NSG.

Tymczasem Network Policies to mechanizm, który pozwala:

• – egzekwować zasady komunikacji pomiędzy mikroserwisami,
• – ograniczyć powierzchnię ataku,
• – wprowadzić warstwę audytowalności w procesie zgodności z ISO, NIST CSF, DORA, NIS2.

Praktyczne zasady projektowania polityk sieciowych

Domyślna izolacja – default deny

Każdy namespace powinien być domyślnie odizolowany od innych. Brak tej polityki to prosta droga do lateral movement w przypadku kompromitacji jednej aplikacji.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

To najprostszy możliwy manifest, a jednocześnie jedna z najczęściej pomijanych konfiguracji. W praktyce wprowadzamy go zawsze jako punkt wyjścia w każdym klastrze niezależnie od jego rozmiaru.

Kontrolowana komunikacja – whitelisting

Po wprowadzeniu izolacji, komunikację trzeba otworzyć tylko tam, gdzie jest to niezbędne. Przykład wdrożenia zasady „least privilege” w praktyce:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 8443
  policyTypes:
  - Ingress

Powyższa polityka precyzyjnie definiuje, że tylko aplikacja web może komunikować się z api przez port 8443. Zgodnie z kontrolą CIS 5.2.3, takie podejście zapewnia integralność sieci aplikacji i minimalizuje ryzyko przypadkowej ekspozycji danych.

Kontrola ruchu wychodzącego (egress)

Wielu administratorów pomija ten kierunek a w rzeczywistości brak kontroli egress to częsty wektor wycieku danych.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
  namespace: production
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          zone: dmz
    ports:
    - protocol: TCP
      port: 443

Tego typu polityka ogranicza ruch wychodzący tylko do wybranych segmentów. W kontekście DORA oraz NIS2 można ją traktować jako techniczny dowód na kontrolę przepływu danych i ograniczenie ryzyka wycieku.

Network Policies w kontekście Compliance

Z perspektywy audytu, każda reguła sieciowa to nie tylko konfiguracja YAML, ale artefakt kontrolny – zapisany, wersjonowany i możliwy do odtworzenia.

W praktyce polityki sieciowe stają się częścią systemu zarządzania ryzykiem, a nie tylko konfiguracją techniczną.

GitOps i Infrastructure as Code

Najlepszym podejściem do zarządzania politykami jest pełna automatyzacja i audytowalność w modelu GitOps. Każda polityka powinna spełniać następujące zasady:

• – Wersjonowana w repozytorium Git,
• – Wdrażana przez narzędzia typu Jenkins, ArgoCD, Github,
• – Monitorowana w Azure Policy.

Wnioski z wdrożeń

Z wdrożeń w dużych środowiskach (od sektora finansowego po publiczny) widzimy kilka kluczowych wniosków:

• – Network Policies to governance, nie konfiguracja. Dobrze zaprojektowane stają się częścią struktury compliance a nie tylko technicznym zabezpieczeniem.
• – Segmentacja sieciowa realnie redukuje ryzyko lateral movement – w testach penetracyjnych izolacja namespace skutecznie zatrzymuje ataki.
• – Kubernetes nie potrzebuje więcej zabezpieczeń, potrzebuje więcej odpowiedzialności – najczęstsze problemy wynikają z braku zasad, nie z braku narzędzi lub braku funkcjonalności.

Podsumowanie

Network Policies w Azure AKS są jednym z najbardziej niedocenianych elementów bezpieczeństwa. Dla audytora: to dowód zgodności, dla zespołu DevOps: warstwa ochronna, a dla architekta: narzędzie egzekwowania zasad Zero Trust.

Jeśli chcesz aby Twój klaster AKS był naprawdę bezpieczny i zgodny z regulacjami, zacznij od prostego kroku:

Włącz default deny i zbuduj polityki komunikacji.

Autor

Łukasz Tabaczek
Cloud & Security Architect w Professnet

Od ponad dwóch dekad wspieram organizacje w projektowaniu bezpiecznych i skalowalnych środowisk chmurowych jak i on-premises. Specjalizuję się w technologiach Cloud, Kubernetes i DevSecOps, łącząc architekturę techniczną z praktycznym podejściem do zgodności i bezpieczeństwa.

Chcesz wiedzieć, jak wdrożyć polityki sieciowe zgodne z NIS2 i DORA?

Skontaktuj się z zespołem Professnet – pomagamy organizacjom projektować i utrzymywać środowiska AKS spełniające najwyższe standardy bezpieczeństwa i zgodności.