Tożsamość i uprawnienia
- RBAC
- Roles / ClusterRoles
- service accounts
- tokeny
- dostęp do secrets
- uprawnienia operatorów i controllerów
- ryzyka eskalacji uprawnień
Kubernetes Security Assessment
Audyt bezpieczeństwa Kubernetes dla firm cloud-native
Sprawdzamy Kubernetes, OpenShift, Rancher, RKE2 i K3s tak, jak patrzyłby na nie atakujący: RBAC, service accounty, sekrety, ingressy, NetworkPolicies, CI/CD, registry, workloady i node’y.
Łączymy pentest Kubernetes, audyt klastra Kubernetes i hardening Kubernetes w jeden konkretny proces: od konfiguracji i uprawnień po wpływ na produkcyjne deploymenty.
Dostajesz raport techniczny, wersję zarządczą i plan hardeningu 30/60/90 dni. Materiał możesz wykorzystać przy przeglądzie bezpieczeństwa u klienta, NIS2/KSC albo rozmowie z audytorem.
RBAC → secrets → CI/CD
mapa realnych ścieżek ataku
CTO / DevOps / zarząd
jedna praca, dwa poziomy raportu
NIS2 / KSC / wymagania klientów
materiał do przeglądu i wymagań klientów
01
Dla kogo
Najczęściej pomagamy zespołom, które mają Kubernetes, OpenShift, Rancher, RKE2 albo K3s na produkcji i chcą uporządkować bezpieczeństwo bez zatrzymywania pracy.
software house’y
SaaS B2B
firmy z Kubernetes on-prem/private cloud
zespoły DevOps i Platform Engineering
firmy migrujące z public cloud do infrastruktury lokalnej
firmy przygotowujące się do przeglądu bezpieczeństwa u dużego klienta
organizacje potrzebujące technicznych dowodów pod NIS2/KSC
firmy z CI/CD, GitOps, registry i kontenerami na produkcji
02
Co sprawdzamy
Sieć i ekspozycja
- ingress
- usługi publiczne
- NetworkPolicies
- namespace isolation
- lateral movement
- ekspozycja API server
- ekspozycja kubelet
- TLS i brzegowe punkty wejścia
Workloady i node’y
- privileged containers
- hostPath
- hostNetwork
- Linux capabilities
- Pod Security Standards
- seccomp / AppArmor
- hardening node’ów
- podatne obrazy i konfiguracje workloadów
CI/CD i supply chain
- GitLab CI
- GitHub Actions
- Jenkins
- ArgoCD / Flux
- registry
- image scanning
- SBOM
- podpisywanie obrazów
- sekrety w pipeline
- ścieżka pipeline → registry → cluster
Metodyka i standardy
Assessment oparty o uznane przewodniki, ale opisany pod realne ryzyko
Łączymy manualny assessment z odniesieniem do uznanych standardów i przewodników. Nie przepisujemy checklisty 1:1 — mapujemy ustalenia na realne ścieżki ataku, wpływ biznesowy i kolejność napraw.
CIS Kubernetes BenchmarkNSA/CISA Kubernetes Hardening GuidanceOWASP Kubernetes Security Testing GuideOWASP Kubernetes Top 10MITRE ATT&CKKubernetes Security Checklist
- CIS Kubernetes Benchmark pomaga uporządkować bezpieczną konfigurację klastra.
- NSA/CISA guidance wzmacnia tematy hardeningu, least privilege, separacji sieciowej i audytu logów.
- OWASP KSTG i OWASP Kubernetes Top 10 pomagają prowadzić techniczną ocenę klastra i typowych ryzyk.
- MITRE ATT&CK traktujemy jako język mapowania taktyk i technik atakującego.
Bezpieczny przebieg testów
Assessment bez niepotrzebnego ryzyka dla produkcji
Pracujemy na uzgodnionym zakresie, z zasadami ROE, oknami testowymi i kanałem eskalacji. Możemy zacząć od read-only configuration review, stagingu albo ograniczonego zakresu produkcyjnego. Nie wykonujemy działań destrukcyjnych bez osobnej zgody. Ustalenia dokumentujemy z dowodami, wpływem i rekomendowaną kolejnością napraw.
- zakres i zasady ROE przed startem
- okna testowe i kanał eskalacji
- read-only review, staging albo kontrolowany zakres produkcyjny
- brak działań destrukcyjnych bez osobnej zgody
03
Pakiety
od 12 000 zł netto
Kube Quick Review
Krótki przegląd jednego klastra Kubernetes, OpenShift, Rancher, RKE2 albo K3s. Skupiamy się na miejscach, które najczęściej robią różnicę: RBAC, service accounty, sekrety, ingress, NetworkPolicies, wybrane workloady i połączenie CI/CD z klastrem.
Dostajesz listę najważniejszych ryzyk, krótki raport techniczny, rekomendacje i 60–90 minut omówienia z CTO albo zespołem DevOps.
od 29 000 zł netto
Kubernetes Security Assessment
Pełny przegląd bezpieczeństwa klastra i otoczenia cloud-native. Analizujemy uprawnienia, sekrety, NetworkPolicies, ingress, ekspozycję usług, workloady, node’y, registry, logowanie, monitoring i podstawy supply chain security.
Wynikiem jest raport techniczny, podsumowanie zarządcze, mapa ścieżek ataku, priorytety naprawcze i plan działań na 30/60/90 dni.
od 45 000 zł netto
K8s + CI/CD + AppSec Review
Szerszy przegląd dla firm SaaS, software house’ów i zespołów platformowych. Łączymy Kubernetes, CI/CD, registry, GitOps, API i podstawowy AppSec, żeby zobaczyć cały przepływ od kodu do produkcji.
Powstaje materiał dla CTO, DevOps, zarządu, dużego klienta albo odpowiedzi na ankietę bezpieczeństwa.
od 4 900 zł/mies. netto
Monthly Kube Security Delta
Comiesięczne sprawdzenie zmian w bezpieczeństwie klastra. Patrzymy na nowe uprawnienia, ekspozycje, zmiany RBAC, nowe workloady, ryzyka w ingressach i status poprawek.
Zamiast kolejnego dużego audytu dostajesz krótki raport zmian, priorytety na kolejny okres i bieżącą kontrolę po assessmentcie.
04
Mapa ścieżek ataku
Pojedynczy błąd w konfiguracji rzadko mówi całą historię. Ważniejsze jest to, czy kilka słabszych miejsc da się połączyć w scenariusz z realnym skutkiem.
Taki opis pomaga zespołowi technicznemu naprawiać rzeczy w sensownej kolejności, a zarządowi zrozumieć, dlaczego dany temat jest ważny.
od pojedynczego błędu do skutku
Zobacz, jak pojedyncze błędy łączą się w realny scenariusz.
Anonimizowany scenariusz oparty na typowych błędach
Przykładowe ustalenie z audytu
Ścieżka ataku
Podatna aplikacja → workload → token service account → nadmiarowy RBAC → odczyt secrets → dostęp do registry → możliwość wpływu na deployment produkcyjny.
Wpływ
Możliwość odczytu sekretów i wpływu na deployment produkcyjny. To realna ścieżka przejęcia części środowiska, a nie tylko pojedynczy alert ze skanera.
Priorytet
Critical / High, zależnie od zakresu dostępu.
Naprawa
Ograniczenie RBAC, wyłączenie automount tokenów tam, gdzie nie są potrzebne, rotacja sekretów, NetworkPolicy default deny, admission policy oraz weryfikacja dostępu CI/CD do registry i namespace’ów produkcyjnych.
To przykład labowy, ale oparty na błędach, które regularnie pojawiają się w prawdziwych środowiskach Kubernetes.
Rezultat końcowy
Co zawiera raport
Klient nie płaci za samą aktywność testową. Najważniejszy jest materiał, który pozwala podjąć decyzje, zaplanować poprawki i pokazać dowody techniczne klientowi, audytorowi albo zarządowi.
- Executive summary dla zarządu
- Zakres i ograniczenia testów
- Mapa ścieżek ataku
- Krytyczne ryzyka i ich wpływ biznesowy
- RBAC, service accounts i eskalacja uprawnień
- Sekrety, registry i CI/CD
- Ingress, NetworkPolicies i ruch east-west
- Workload/node hardening
- Logging, monitoring i ślady audytowe
- Plan naprawczy 30/60/90 dni
- Retest checklist
Dowody techniczne pod NIS2 i przegląd klienta
Polityki i procedury to za mało, gdy klient albo audytor pyta o faktyczny stan środowiska. Przygotowujemy materiał pokazujący, jak wyglądają dostępy, sekrety, logowanie, podatności, retesty i plan napraw.
konfiguracja dostępu
separacja środowisk
bezpieczeństwo sekretów
monitoring i logowanie
podatności i retesty
plan naprawczy 30/60/90 dni
Nie tylko checklisty — publikujemy realne CVE w projektach open-source i produkcyjnym software
To ważny trust asset CertRank. Publiczne podatności w Gitea, Traefik, rclone, SimpleSAMLphp i ProxySQL pokazują, że pracujemy blisko kodu, umiemy ocenić wpływ błędu i opisać go w sposób przydatny dla zespołów utrzymujących systemy.
Gitea
critical CVSS 9.9
Traefik
HTTP/3 mTLS bypass
rclone
critical CVSS 9.8
SimpleSAMLphp
SAML binding bypass
ProxySQL
pre-auth heap overflow CVSS 9.8
Szkolenia po raporcie
Jeżeli po assessmentcie zespół chce wejść głębiej w konkretne obszary, możemy zrobić warsztat zamknięty albo dobrać szkolenia z Kubernetes Security, CKS, CI/CD Security, API, AppSec i AI/LLM Security.
Przejdź do AcademyFAQ
Czy to jest formalny audyt NIS2?
Nie. To techniczna ocena środowiska Kubernetes, CI/CD i usług powiązanych. Raport może być jednak dobrym załącznikiem do pracy nad NIS2/KSC, przeglądu bezpieczeństwa u klienta albo ankiety bezpieczeństwa.
Czy dostaniemy tylko wynik ze skanera?
Nie. Automatyzacja pomaga zebrać dane, ale najważniejsze ustalenia są sprawdzane ręcznie i opisane w kontekście Waszego środowiska.
Czy testujecie produkcję?
Tak, jeżeli ustalimy zakres, okna testowe i zasady bezpieczeństwa. Możemy też zacząć od stagingu albo samej analizy konfiguracji.
Co dostaje zarząd?
Krótkie podsumowanie: najważniejsze ryzyka, możliwy wpływ biznesowy, priorytety i decyzje, które warto podjąć.
Co dostaje DevOps?
Raport techniczny z dowodami, rekomendacjami, priorytetami i kolejnością napraw. Bez lania wody i bez przepisywania alertów jeden do jednego.
Czy pomagacie po raporcie?
Tak. Możemy zrobić retest, warsztat techniczny albo szkolenie zespołu w Academy.