DevOps Bootcamp · Lekcja

Network Policies zapewniające izolację

Kontroluj przepływ ruchu sieciowego między Podami i przestrzeniami nazw za pomocą obiektów Network Policies Kubernetes.

Network Policies zapewniające izolację to bezpłatna lekcja DevOps Bootcamp na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej DevOps Bootcamp, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs DevOps Bootcamp zawiera 4 lekcji w sumie.

Zasady sieciowe: policjanci ruchu

W Kubernetesie pody mogą domyślnie swobodnie komunikować się ze sobą. Zapewnia to dużą elastyczność, ale nie zawsze jest optymalne pod względem bezpieczeństwa.

Zasady sieciowe działają jak zapory sieciowe dla podów, kontrolując, jaki ruch sieciowy jest dozwolony przychodzący (ingress) i wychodzący (egress).

Domyślnie wszystkie pody mogą się komunikować

Domyślnie, gdy Pod zostanie wdrożony, może komunikować się z dowolnym innym podem w klastrze, niezależnie od przestrzeni nazw. Ten model „płaskiej sieci” upraszcza konfigurację, ale nie zapewnia izolacji.

W środowiskach produkcyjnych często trzeba ograniczyć komunikację, aby zwiększyć bezpieczeństwo i zapobiec nieautoryzowanemu dostępowi między komponentami aplikacji.

Reguły ruchu przychodzącego i wychodzącego

Zasady sieciowe definiują reguły określające, jak pody mogą się komunikować. Dotyczą przede wszystkim dwóch rodzajów ruchu:

Ingress: ruch przychodzący do poda.
Egress: ruch wychodzący z poda.

Reguły te są stosowane do określonych podów za pomocą etykiet i mogą wskazywać inne pody, przestrzenie nazw lub bloki adresów IP.

Wymagany wtyczka CNI

Zasady sieciowe nie działają automatycznie! Aby mogły działać, klaster Kubernetes musi mieć wtyczkę Container Network Interface (CNI), która je obsługuje.

Popularne wtyczki CNI, takie jak Calico, Cilium i Weave Net, zapewniają tę funkcjonalność. Bez obsługującej je wtyczki CNI zasady sieciowe nie będą miały żadnego efektu.

Budowa zasady

Zasady sieciowe definiuje się za pomocą YAML. Najważniejsze pola to:

metadata.name: unikatowa nazwa zasady.
spec.podSelector: wybiera pody, do których ma zastosowanie zasada.
spec.policyTypes: określa, czy zasada dotyczy Ingress, Egress, czy obu rodzajów ruchu.
spec.ingress/spec.egress: zawiera reguły dozwolonego ruchu.

Blokowanie całego ruchu przychodzącego

Utwórzmy zasadę odrzucającą cały ruch przychodzący do podów z etykietą app: backend w bieżącej przestrzeni nazw. To częsty punkt wyjścia dla podejścia „domyślnie odmawiaj” w zakresie bezpieczeństwa.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-backend-ingress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress: [] # An empty ingress list denies all incoming traffic

Zezwalanie na ruch przychodzący z frontendu

Zmodyfikujmy teraz naszą zasadę tak, aby zezwalała na ruch przychodzący do naszych podów app: backend wyłącznie z podów oznaczonych etykietą app: frontend w tej samej przestrzeni nazw.

Zwróć uwagę na sekcję from, która określa pody źródłowe.

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

Kontrolowanie ruchu wychodzącego

Podobnie jak w przypadku ruchu przychodzącego można kontrolować ruch wychodzący (egress). Utworzymy tutaj zasadę, która pozwoli podom app: backend wysyłać żądania wyłącznie do podów oznaczonych etykietą app: database.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress-to-db
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database

Wskazywanie innych przestrzeni nazw

Co zrobić, jeśli frontend znajduje się w innej przestrzeni nazw, na przykład web-apps? Można użyć namespaceSelector, aby wskazywać pody w różnych przestrzeniach nazw.

Ta zasada zezwala na ruch przychodzący do podów app: backend z dowolnego poda w przestrzeni nazw web-apps.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-apps-ingress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: web-apps
      podSelector: {} # All pods in the selected namespace

Wyzwanie dotyczące zasad

Rozważ Pod z etykietami app: web i env: prod. Która zasada sieciowa zezwoli na wyłącznie ruch przychodzący z podów w przestrzeni nazw monitoring?

Podsumowanie: zabezpieczanie sieci

Świetna praca! Dowiedzieli się Państwo, jak zasady sieciowe Kubernetes zapewniają kluczową izolację sieciową aplikacji.

Działają jak zapory sieciowe dla podów.
Kontrolują zarówno ruch przychodzący (ingress), jak i wychodzący (egress).
Wymagają wtyczki CNI, która je obsługuje.
Są definiowane w YAML za pomocą podSelector, policyTypes i definicji reguł.
Mogą wskazywać pody na podstawie etykiet, a nawet całe przestrzenie nazw.

Używaj ich do egzekwowania modelu sieciowego opartego na zasadzie „minimalnych uprawnień”!

Często zadawane pytania

Czy lekcja „Network Policies zapewniające izolację” jest bezpłatna?

Tak — pełny tekst „Network Policies zapewniające izolację” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu DevOps Bootcamp, przejdź na CoddyKit PRO. Kurs DevOps Bootcamp zawiera 4 lekcji w sumie.

Co nauczysz się w „Network Policies zapewniające izolację”?

Kontroluj przepływ ruchu sieciowego między Podami i przestrzeniami nazw za pomocą obiektów Network Policies Kubernetes. Ćwiczysz DevOps Bootcamp z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć DevOps Bootcamp?

Nie wymagamy żadnego doświadczenia. DevOps Bootcamp w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.

Ile czasu zajmuje lekcja „Network Policies zapewniające izolację”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji DevOps Bootcamp?

Tak. Każda lekcja DevOps Bootcamp zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

Kontrola dostępu oparta na rolach (RBAC)
Network Policies zapewniające izolację
Standardy bezpieczeństwa Podów
Konta usług i tożsamość obciążeń

← Powrót do DevOps Bootcamp