0Pricing
Cyber Security Academy · Lekcja

Bezpieczeństwo podów i zasady sieciowe

Izolowanie obciążeń

Bezpieczeństwo podów i zasady sieciowe to bezpłatna lekcja Cyber Security Academy na CoddyKit. To lekcja 3 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 Cyber Security Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

Izolowanie obciążeń

Dwa mechanizmy ograniczają możliwości przejętego poda: Pod Security ogranicza uprawnienia poda, a Network Policies ograniczają możliwość komunikacji między podami. Razem ograniczają promień rażenia.

  • Pod Security zapobiega ucieczkom na poziom węzła.
  • Network Policies zatrzymują ruch boczny między podami.

Niebezpieczne ustawienia podów

Niektóre pola specyfikacji poda znacznie zwiększają ryzyko, jeśli są dozwolone.

  • privileged: true zapewnia niemal pełny dostęp do hosta.
  • hostPID, hostNetwork, hostIPC przełamują izolację przestrzeni nazw.
  • Wolumeny hostPath montują katalogi węzła.
  • Dodane capabilities, takie jak SYS_ADMIN, umożliwiają ucieczkę.
  • Uruchamianie jako root (runAsUser: 0).

Pod Security Admission

Pod Security Admission (PSA) zastąpił PodSecurityPolicy. Wymusza stosowanie trzech wbudowanych standardów w każdym namespace.

  • Privileged: bez ograniczeń (należy unikać w przypadku obciążeń).
  • Baseline: blokuje znane eskalacje uprawnień.
  • Restricted: wzmocnione najlepsze praktyki (bez uruchamiania jako root, bez dodatkowych uprawnień, z usuniętymi capabilities).
# Enforce the restricted standard on a namespace
kubectl label namespace prod \
  pod-security.kubernetes.io/enforce=restricted

Wzmocniony securityContext

Najmniejsze niezbędne uprawnienia należy zdefiniować na poziomie poda i kontenera za pomocą securityContext.

  • Należy uruchamiać proces jako użytkownik inny niż root i używać tylko do odczytu głównego systemu plików.
  • Należy usunąć wszystkie capabilities systemu Linux, a następnie dodać tylko te, które są potrzebne.
  • Należy zablokować eskalację uprawnień.
# securityContext fields (YAML)
# runAsNonRoot: true
# readOnlyRootFilesystem: true
# allowPrivilegeEscalation: false
# capabilities: drop: [ALL]
kubectl apply -f hardened-deploy.yaml

Poza standardami: silniki zasad

Jeśli potrzebne są bardziej rozbudowane reguły niż te oferowane przez PSA, kontrolery admission mogą wymuszać niestandardowe zasady.

  • OPA Gatekeeper ocenia ograniczenia zapisane w Rego.
  • Kyverno używa zasad w YAML i może zarówno modyfikować zasoby, jak i je weryfikować.

Narzędzia te mogą blokować hostPath, wymagać podpisanych obrazów lub wymuszać stosowanie etykiet w całym klastrze.

# Apply a Kyverno policy that disallows privileged pods
kubectl apply -f disallow-privileged.yaml

Sieć domyślnie otwarta

Domyślnie wszystkie pody mogą komunikować się ze wszystkimi innymi podami we wszystkich namespace'ach. Segmentacja nie istnieje, dopóki nie zostaną dodane Network Policies. Ta płaska sieć sprawia, że pojedynczy przejęty pod może skanować cały klaster i atakować go.

# From a pod, the flat network lets you reach any service
curl http://internal-db.prod.svc.cluster.local:5432

Podstawy Network Policy

Network Policies to reguły obowiązujące w namespace, które wybierają pody i zezwalają na określony ruch przychodzący lub wychodzący. Działają addytywnie: zastosowanie dowolnej zasady do poda przełącza go na domyślną odmowę w objętym nią kierunku.

  • Selektory dopasowują pody na podstawie etykiet.
  • Reguły zezwalają na ruch z określonych podów, namespace'ów lub zakresów CIDR oraz do nich.
  • Wymagany jest interfejs CNI obsługujący zasady, taki jak Calico lub Cilium.

Najpierw domyślna odmowa, potem zezwolenia

Zalecany wzorzec polega na ustanowieniu domyślnej odmowy dla każdego namespace, a następnie dodaniu jawnych reguł zezwalających na wymagane przepływy.

# Default-deny all ingress in a namespace (YAML)
# kind: NetworkPolicy spec: podSelector: {} policyTypes: [Ingress]
kubectl apply -f default-deny.yaml

# Then allow only frontend -> backend
kubectl apply -f allow-frontend.yaml

Ruch wychodzący i blokowanie metadanych

Zasady dotyczące ruchu wychodzącego są równie ważne jak zasady dotyczące ruchu przychodzącego.

  • Należy ograniczyć zewnętrzne punkty końcowe, z którymi mogą łączyć się pody (ogranicza to eksfiltrację danych i komunikację z serwerem C2).
  • Należy zablokować z podów dostęp do adresu IP metadanych chmury 169.254.169.254, aby zapobiec kradzieży poświadczeń węzła.
  • Należy ograniczyć DNS oraz wewnętrzny ruch w kierunku wschód-zachód.

Ochrona w czasie działania

Statyczne zasady uzupełnia wykrywanie zagrożeń w czasie działania.

  • Falco ostrzega o podejrzanych wywołaniach systemowych (powłoce uruchomionej w kontenerze, wrażliwych montowaniach).
  • Profile seccomp ograniczają wywołania systemowe, które może wykonywać kontener.
  • AppArmor/SELinux dodają na węźle obowiązkową kontrolę dostępu.
# Apply the runtime/default seccomp profile (securityContext)
# seccompProfile: type: RuntimeDefault
kubectl apply -f seccomp-deploy.yaml

Testowanie izolacji

Podczas weryfikowania izolacji należy próbować nawiązywać połączenia między podami i używać mechanizmów ucieczki z poda testowego, aby potwierdzić, że zasady je blokują. Należy robić to w kontrolowanym namespace, a następnie usunąć pody testowe.

Należy zgłosić każdy pod uruchomiony z uprawnieniami privileged oraz każdy namespace bez domyślnej odmowy, podając dokładną poprawkę w manifeście.

Szybki test

Sprawdź swoją wiedzę na temat izolacji.

Podsumowanie

Nauczyłeś się izolować obciążenia.

  • Pod Security Admission (restricted) i securityContext blokują ucieczki.
  • Gatekeeper/Kyverno wymuszają niestandardowe zasady admission.
  • Sieć jest domyślnie otwarta; należy zastosować domyślną odmowę, a następnie jawne zezwolenia.
  • Reguły dotyczące ruchu wychodzącego, blokowanie metadanych i Falco zapewniają dodatkową ochronę.

Następnie: zabezpieczanie łańcucha dostaw i sekretów.

Często zadawane pytania

Czy lekcja „Bezpieczeństwo podów i zasady sieciowe” jest bezpłatna?

Tak — pełny tekst „Bezpieczeństwo podów i zasady sieciowe” 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 Cyber Security Academy, przejdź na CoddyKit PRO. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Bezpieczeństwo podów i zasady sieciowe”?

Izolowanie obciążeń Ćwiczysz Cyber Security Academy 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ąć Cyber Security Academy?

Nie wymagamy żadnego doświadczenia. Cyber Security Academy 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 3 z 4.

Ile czasu zajmuje lekcja „Bezpieczeństwo podów i zasady sieciowe”?

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 Cyber Security Academy?

Tak. Każda lekcja Cyber Security Academy 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

  1. Model zagrożeń Kubernetes
  2. RBAC i konta usług
  3. Bezpieczeństwo podów i zasady sieciowe
  4. Zabezpieczanie łańcucha dostaw i sekretów
← Powrót do Cyber Security Academy