Testy bezpieczeństwa mikroserwisów i kontenerów
Dla zespołów utrzymujących platformy oparte na kontenerach, service mesh lub Kubernetes, gdzie jedno źle skonfigurowane powiązanie RBAC albo nieuwierzytelnione wywołanie east-west może odsłonić cały klaster. Testujemy warstwy, których pentest aplikacji webowej nigdy nie dotyka: zaufanie między usługami, warstwę sterowania, łańcuch dostaw obrazów i zarządzanie sekretami — i dowodzimy, którymi ścieżkami atakujący realnie może się przemieścić.
Co testujemy
AuthN/authZ między usługami (mTLS i zero-trust)
Weryfikujemy, czy ruch east-west wymusza wzajemny TLS (PeerAuthentication STRICT), odrzuca plaintext, a AuthorizationPolicy faktycznie domyślnie blokuje — a nie działa w trybie permissive bez reguł allow ani z podatną na podszycie tożsamością z X-Forwarded-For / bez JWT.
Przejęcie tożsamości workloadu i nadużycie tokenów
Próbujemy wykraść tokeny ServiceAccount z podów, odtworzyć je wobec API servera i testujemy walidację audience/issuer SPIFFE/JWT — wykrywając zbyt szerokie tokeny oraz brak weryfikacji `aud`/`exp` (NIST SP 800-204B, ABAC).
Eskalacja uprawnień w RBAC Kubernetes
Mapujemy każdy Role/ClusterRoleBinding pod kątem wildcardów, uprawnień `escalate`/`bind`/`impersonate`, listowania sekretów, `pods/exec` i node-proxy, które pozwalają tożsamości ograniczonej do namespace osiągnąć cluster-admin.
Network policies i segmentacja east-west
Domyślnego default-deny zwykle brak — dowodzimy płaskiej sieci podów, przemieszczając się z jednego przejętego poda do niepowiązanych namespace’ów, kubeleta (10250), etcd (2379) i metadanych chmury (169.254.169.254) w celu kradzieży poświadczeń IMDS.
Podatności CVE w obrazach i integralność SBOM
Generujemy SBOM (Syft/CycloneDX), skanujemy exploitowalne CVE w zależnościach OS i aplikacji, oznaczamy obrazy działające jako root/privileged, sekrety wbudowane w warstwy oraz niespięte `:latest` i niepodpisane obrazy (brak atestacji cosign/Notation).
Hartowanie podów (Pod Security Standards)
Polujemy na privileged pody, montowania hostPath/hostNetwork/hostPID, `allowPrivilegeEscalation`, brak seccomp/AppArmor oraz CAP_SYS_ADMIN — prymitywy ucieczki z kontenera mierzone względem CIS i Pod Security Standards `restricted`.
Ekspozycja zarządzania sekretami
Sprawdzamy sekrety w plaintext (base64 to nie szyfrowanie), sekrety w zmiennych środowiskowych i manifestach, brak szyfrowania at-rest dla etcd oraz czy zewnętrzne magazyny (Vault, KMS/CSI) faktycznie ograniczają dostęp, zamiast montować wszystko do każdego poda.
API gateway i łańcuch dostaw (CI/CD)
Testujemy ingress/API gateway pod kątem obejścia uwierzytelnienia, header smugglingu i luk rate-limitu oraz przeglądamy CI/CD pod kątem podatnych pipeline’ów, nadmiernie uprzywilejowanych runnerów i niezweryfikowanych artefaktów (OWASP Top 10 CI/CD, provenance SLSA).
Metodologia
- 1
Ustalenie zakresu i rekonesans architektury
Wspólnie mapujemy granice zaufania: namespace’y, service mesh (Istio/Linkerd), ingress, rejestry, CI/CD i IAM chmury. Model dostępu ustalamy z góry — black-box z zewnątrz, pod-przyczółek w klastrze i/lub kubeconfig read-only — wraz z zasadami działania na współdzielonym klastrze (PTES pre-engagement).
- 2
Testy zewnętrzne i API gateway
Spoza klastra enumerujemy wystawione usługi, ingress oraz przypadkowo opublikowane panele wewnętrzne (Kubelet, etcd, Dashboard, rejestry) i testujemy API gateway pod kątem obejścia authN/authZ — frontowe drzwi atakującego, zmapowane na OWASP API Security Top 10.
- 3
Ocena konfiguracji klastra
Uwierzytelniony przegląd RBAC, network policies, Pod Security, admission control (OPA/Gatekeeper/Kyverno), flag API-servera i szyfrowania etcd, wzorcowany względem CIS Kubernetes Benchmark i NIST SP 800-190 — oddzielając ustalenia teoretyczne od exploitowalnych.
- 4
Ruch east-west i eskalacja
Z poda-przyczółka w modelu assumed-breach ścigamy realne ścieżki ataku: kradzież tokenów, dostęp do poświadczeń node/metadata, ucieczkę z kontenera, ruch lateralny między namespace’ami i drogę do cluster-admin, zmapowane na MITRE ATT&CK for Containers.
- 5
Analiza łańcucha dostaw i obrazów
Generowanie SBOM, skan CVE i sekretów w obrazach, przegląd obrazów bazowych i provenance, weryfikacja podpisów/atestacji (cosign/Notation, SLSA) oraz ścieżki nadużycia pipeline’u CI/CD pozwalające kodowi trafić na produkcję bez weryfikacji.
- 6
Raport, omówienie i retest
Każde ustalenie zawiera dokładny manifest/komendę do odtworzenia, kontekst klastra, ocenę CVSS v3.1 i konkretną rekomendację (konkretna polityka, nie „utwardź RBAC”). Omówienie na żywo z zespołem platformowym i bezpłatny retest naprawionych podatności.
Standardy i odniesienia
Co otrzymujesz
- Raport techniczny z odtwarzalnymi PoC — Każde ustalenie z manifestem, komendą kubectl/curl i wynikiem do odtworzenia, oceną CVSS v3.1, dotkniętym namespace/workloadem i konkretną poprawką.
- Narracja ścieżki ataku — Kill chain w modelu assumed-breach — od poda-przyczółka do cluster-admin lub danych — zmapowany na MITRE ATT&CK for Containers, byś widział sekwencję, a nie odosobnione flagi.
- Lista luk konfiguracji CIS i Pod Security — Priorytetyzowane odchylenia od benchmarku dla RBAC, network policy, Pod Security Standards i stanu obrazów, oznaczone jako exploitowalne vs. zalecane do utwardzenia.
- Inwentarz SBOM i podatności obrazów — SBOM CycloneDX dla każdego skanowanego obrazu plus zdeduplikowana, uszeregowana wg exploitowalności lista CVE — nie surowy szum skanera.
- Streszczenie zarządcze i atest retestu — Jednostronicowe podsumowanie ryzyka dla kierownictwa/compliance oraz runda retestu i pismo potwierdzające, które ustalenia zamknięto.
FAQ
Czy potrzebujecie dostępu cluster-admin, żeby testować?+
Nie. Dostęp dopasowujemy do Waszej tolerancji ryzyka. Najbardziej realistyczny scenariusz to assumed-breach: dajecie nam pod-przyczółek o niskich uprawnieniach i/lub kubeconfig read-only, a my dowodzimy, dokąd dotrze atakujący, który przejmie jeden kontener. Dostępne są też warianty czysto zewnętrzny black-box i pełny przegląd konfiguracji — model ustalamy przy określaniu zakresu.
Czy test zakłóci nasz klaster produkcyjny?+
Testy są domyślnie niedestrukcyjne. Unikamy wyczerpywania zasobów, nie usuwamy workloadów, a każde potencjalnie zakłócające działanie (np. kontrolowany PoC ucieczki z kontenera) jest zapowiadane i uruchamiane wyłącznie na zatwierdzonym przez Was namespace lub klastrze staging. Zasady działania i plan wycofania ustalamy, zanim czegokolwiek dotkniemy.
Ile to trwa i ile kosztuje?+
Skupiony test pojedynczego klastra to zwykle 5–8 dni roboczych; większe środowiska multi-cluster lub multi-mesh to 2–3 tygodnie. Koszt zależy od liczby klastrów, liczby namespace’ów/usług oraz tego, czy w zakresie są łańcuch dostaw obrazów i CI/CD. Stałą wycenę otrzymujecie po krótkiej rozmowie zakresowej — bez otwartego rozliczenia.
Co musimy zapewnić, by zacząć?+
Notatki o architekturze/modelu zagrożeń, jeśli je macie, zakres celu (klastry, namespace’y, rejestry, adresy gateway), uzgodniony artefakt dostępu (specyfikacja poda-przyczółka lub kubeconfig) oraz podpisaną autoryzację. Jeśli w zakresie jest IAM chmury, poprosimy o rolę read-only. To zwykle wystarcza, by ruszyć w ciągu kilku dni.
Czy to raport ze skanera, czy testy manualne?+
Jedno i drugie, we właściwej kolejności. Narzędzia automatyczne (Trivy/Grype, kube-bench, kube-hunter, Syft) dają pokrycie, ale każde zgłoszone ustalenie jest ręcznie weryfikowane i łączone przez testera — odrzucamy false positive’y i, co ważniejsze, spinamy pojedynczo błahe błędy konfiguracji w realną ścieżkę do cluster-admin. Otrzymujecie exploitowalność, nie surowy wynik skanera.
Obejmujecie obrazy kontenerów i CI/CD, czy tylko działający klaster?+
Jedno i drugie, jeśli jest w zakresie. Generujemy SBOM-y i skanujemy obrazy pod kątem CVE oraz wbudowanych sekretów, przeglądamy obrazy bazowe i podpisy/atestacje (cosign, provenance SLSA) oraz oceniamy pipeline CI/CD pod kątem podatnych kroków i nadmiernie uprzywilejowanych runnerów — bo w mikroserwisach pipeline bywa najmiększą drogą na produkcję.