0Pricing
Cyber Security Academy · Lekcja

Model zagrożeń Kubernetes

Miejsca, w których klastry mogą zostać zaatakowane

Model zagrożeń Kubernetes to bezpłatna lekcja Cyber Security Academy na CoddyKit. To lekcja 1 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.

Dlaczego Kubernetes jest celem

Kubernetes orkiestruje kontenery na wielu węzłach. Centralizuje sekrety, sieć i zasoby obliczeniowe, więc przejęcie klastra może oznaczać przejęcie każdego uruchamianego przez niego obciążenia.

  • Jeden serwer API kontroluje cały klaster.
  • Węzły uruchamiają obok siebie obciążenia wielu dzierżawców.
  • Błędna konfiguracja występuje znacznie częściej niż podatności w samym Kubernetesie.

Podsumowanie architektury klastra

Aby modelować zagrożenia, należy znać poszczególne komponenty.

  • Płaszczyzna sterowania: serwer API, etcd, scheduler, controller-manager.
  • Węzły: kubelet, środowisko uruchomieniowe kontenerów, kube-proxy, pody.
  • etcd przechowuje cały stan klastra i sekrety.

Serwer API jest pojedynczym punktem wejścia, a etcd — najcenniejszym zasobem danych.

Mapa powierzchni ataku

Ataki wymierzone są w poszczególne warstwy.

  • Zewnętrzna: ujawniony serwer API, pulpity, ingress.
  • Obciążenie: przejęta aplikacja wewnątrz poda.
  • Tożsamość: tokeny kont usług i RBAC.
  • Węzeł: API kubeletu, ucieczka z kontenera na hosta.
  • Łańcuch dostaw: złośliwe obrazy i zależności.

Ujawniona płaszczyzna sterowania

Dostępny z internetu serwer API lub kubelet ze słabym uwierzytelnianiem to bezpośrednia droga do przejęcia klastra.

  • Włączony dostęp anonimowy na serwerze API.
  • Ujawnione API kubeletu z możliwością odczytu/zapisu (port 10250).
  • Otwarty dashboard Kubernetes z przypisaniem uprawnień administratora.
# Probe an exposed kubelet for running pods
curl -sk https://NODE_IP:10250/pods

# Test anonymous API access
kubectl --insecure-skip-tls-verify --server https://API:6443 get pods

Przyczółek wewnątrz poda

Najczęstszym punktem wyjścia jest RCE w aplikacji działającej w podzie. Z wnętrza poda atakujący znajdują:

  • Zamontowany token konta usługi w /var/run/secrets/....
  • Dostępne usługi wewnętrzne (brak polityki sieciowej).
  • Serwer API, często rozpoznawalny pod adresem kubernetes.default.
# From inside a pod: read the mounted SA token
cat /var/run/secrets/kubernetes.io/serviceaccount/token

# Use it against the API
curl -sk -H "Authorization: Bearer $(cat .../token)" https://kubernetes.default/api/v1/namespaces/default/pods

Ucieczka z kontenera

Wydostanie się z kontenera na węzeł zapewnia dostęp do wszystkich obciążeń na tym hoście.

  • Kontenery Privileged mogą uzyskiwać dostęp do urządzeń hosta i uciekać z kontenera.
  • Montowania hostPID/hostNetwork/hostPath zwiększają zasięg skutków ataku.
  • Zamontowany socket Dockera pozwala uruchomić uprzywilejowany kontener.
  • Niebezpieczne możliwości (SYS_ADMIN) umożliwiają ucieczkę.
# A privileged pod can mount the host filesystem and chroot to it
mount /dev/sda1 /mnt && chroot /mnt sh

etcd: magazyn sekretów

etcd przechowuje cały stan klastra, w tym zasoby Secrets, które domyślnie są jedynie kodowane w base64. Bezpośredni dostęp do etcd (często nieuwierzytelniony w błędnie skonfigurowanych klastrach) ujawnia wszystkie sekrety.

# Read all secrets from an exposed etcd
etcdctl --endpoints=https://NODE:2379 get / --prefix --keys-only

Ruch boczny w klastrach

Po uzyskaniu dostępu atakujący przemieszczają się, wykorzystując tożsamość klastra i sieć.

  • Permisywne konto usługi pozwala tworzyć uprzywilejowane pody.
  • Płaskie sieci podów (bez NetworkPolicy) umożliwiają dostęp do dowolnej usługi.
  • Zaplanowanie poda na docelowym węźle umożliwia przejęcie węzła.

Metadane chmurowe z podów

W zarządzanych klastrach (EKS/GKE/AKS) pody mogą uzyskać dostęp do usługi metadanych węzła w chmurze i wykraść poświadczenia IAM/roli węzła, przenosząc skutki przejęcia klastra do konta chmurowego.

Mechanizmy obrony obejmują IMDSv2, blokowanie metadanych na poziomie sieci oraz używanie tożsamości obciążeń zamiast ról węzłów.

Mapowanie za pomocą narzędzi

Narzędzia automatyzują ocenę zagrożeń klastra.

  • kube-hunter bada, czy komponenty są ujawnione.
  • kube-bench sprawdza zgodność z testem porównawczym CIS.
  • Peirates / kubeletctl umożliwiają przećwiczenie ścieżek ataku wewnątrz klastra.
# Assess attack surface
kube-hunter --remote API_IP

# CIS benchmark check on a node
kube-bench run --targets node

Priorytety obrony

Model zagrożeń wskazuje jasne priorytety obrony: zabezpieczenie serwera API, ograniczenie RBAC, izolowanie podów, wzmocnienie ochrony węzłów i zabezpieczenie łańcucha dostaw. Kolejne lekcje omawiają każdy z tych obszarów.

Podczas testów należy atakować wyłącznie klastry, do których mają Państwo upoważnienie, i unikać destabilizowania produkcyjnych obciążeń.

Szybkie sprawdzenie

Sprawdź podstawy modelowania zagrożeń Kubernetes.

Podsumowanie

Zmapowałeś miejsca, w które atakowane są klastry Kubernetes.

  • Serwer API i etcd to centralne cele o najwyższej wartości.
  • Przyczółki w podach wykorzystują zamontowane tokeny SA i płaskie sieci.
  • Uprzywilejowane pody oraz pody z hostPath umożliwiają ucieczkę z kontenera na węzeł.
  • W zarządzanych klastrach istnieje ryzyko przejścia do chmury za pomocą metadanych.

Dalej: RBAC i konta usług.

Często zadawane pytania

Czy lekcja „Model zagrożeń Kubernetes” jest bezpłatna?

Tak — pełny tekst „Model zagrożeń Kubernetes” 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 „Model zagrożeń Kubernetes”?

Miejsca, w których klastry mogą zostać zaatakowane Ć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 1 z 4.

Ile czasu zajmuje lekcja „Model zagrożeń Kubernetes”?

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