Artykuł pochodzi z wydania: Maj 2026
Kubernetes daje ogromną elastyczność, a potem z kamienną twarzą patrzy, jak ktoś uruchamia kontener z privileged=true, montuje hostPath i jeszcze dorzuca cluster-admin, bo trzeba „na szybko”. W tym artykule pokażemy, jak zabezpieczać platformę w sposób sensowny – bez udawania, że kolejny dashboard z zielonymi kafelkami rozwiązuje problem.
Kubernetes nie jest dziś niszowym narzędziem dla kilku entuzjastów platform engineeringu. To warstwa uruchomieniowa dla systemów krytycznych od bankowości, e-commerce, poprzez logistykę, po obronę przeciwlotniczą. To oznacza, że bezpieczeństwo nie dotyczy już wyłącznie klastra, ale całego modelu dostarczania i uruchamiania oprogramowania.
Problem polega na tym, że Kubernetes jest bardzo bezpieczny i niebezpieczny jednocześnie. Bezpieczny, bo daje do dyspozycji RBAC, admission control, audyt, mechanizmy izolacji workloadów, polityki sieciowe, service accounty, szyfrowanie danych i całą resztę. Niebezpieczny, bo nic nie stoi na przeszkodzie, żeby te mechanizmy skonfigurować źle, połowicznie albo wyłączyć je „na chwilę”, która dziwnym trafem trwa w spontanicznej produkcji do pierwszego włamu.
W tradycyjnym świecie infrastruktury można było jeszcze długo żyć iluzją, że granica bezpieczeństwa biegnie gdzieś na firewallu przy brzegu. W świecie Kubernetes to myślenie po prostu się rozpada. Workloady są krótkowieczne, adresy IP się zmieniają, deployment potrafi przeorać stan środowiska w kilka minut, a tożsamość aplikacji nie powinna zależeć od numeru serwera czy nazwy hosta. Ochrona nadal ma znaczenie, ale nie wystarczy. Trzeba myśleć o tożsamości, uprawnieniach, pochodzeniu artefaktów, politykach wdrożeniowych i obserwowalności zdarzeń bezpieczeństwa.
Dobra wiadomość? Większość potrzebnych mechanizmów już istnieje. Zła jest z kolei taka, że trzeba je jeszcze sensownie połączyć. Sam Kubernetes nie przychodzi i nie mówi: „tu masz bezpieczny model operacyjny, niczego nie da się zepsuć”. Wręcz przeciwnie: daje dużo swobody, a ta w IT bardzo często oznacza przestrzeń do popełniania drogich błędów.
Trend a konferencyjna mgła
W dyskusji o bezpieczeństwie Kubernetesa łatwo pomylić modne hasła z realną zmianą praktyki. Aby nie wpaść w tę pułapkę, warto rozdzielić to, co rzeczywiście stało się standardem, od tego, co dobrze wygląda na slajdzie.
Pierwszy realny trend to przesunięcie uwagi z samego skanowania podatności na integralność i pochodzenie artefaktów. Kilka lat temu rozmowa zwykle kończyła się na pytaniu o to, ile CVE ma nasz obraz? Dziś sensowniejsze jest zastanowienie się, kto ten obraz zbudował, z jakiego pipeline’u, z jakich zależności, czy został podpisany i czy klaster potrafi to zweryfikować przed uruchomieniem. To już nie jest temat dla kilku purystów od supply chain. Mówimy o praktycznej odpowiedzi na ataki wykorzystujące podmianę zależności, przejęcie pipeline’u albo dystrybucję fałszywych artefaktów.
Drugi trend to policy-as-code, czyli przeniesienie zasad bezpieczeństwa z dokumentu Security Standard v17 FINAL_final2.pdf do mechanizmu, który rzeczywiście potrafi coś zablokować. W Kubernetesie naturalnym miejscem jest admission control. Tam należy zdecydować, czy wolno wdrożyć pod z latest, z kontenerem uprzywilejowanym, bez seccomp, bez runAsNon-Root albo z obrazem spoza zatwierdzonego rejestru. Jeżeli polityka nie jest egzekwowana przez platformę, to jest głównie prośbą. A prośby, jak wiadomo, świetnie działają do momentu pierwszego kryzysu związanego z wydaniem.
Trzeci trend to krótkotrwałe tożsamości workloadów. Coraz mniej sensowne jest opieranie bezpieczeństwa na statycznych sekretach i tokenach żyjących miesiącami, bo „nikt ich nie zna”. Historia branży uczy, że zna je zwykle więcej osób, niż ktokolwiek chciałby przyznać. Dlatego rośnie znaczenie krótkotrwałych tokenów service accountów, projected tokens oraz modeli workload identity opartych na federacji tożsamości.
Czwarty trend to ograniczanie uprawnień domyślnych. To brzmi banalnie, ale przez lata platformy Kubernetes były pełne aplikacji działających na default service account, z rozbuchanym RBAC i z siecią niczym EEG płaskoziemców. Dziś dojrzalsze organizacje przechodzą na podejście zero trust wobec workloadów, gdzie intensywnie wdrażane są osobne service accounty, jawne role, polityki egress, ograniczanie capabilities, seccomp, read-only root filesystem, admission policy i audyt.
Piąty trend to wykrywanie nadużyć na podstawie telemetrii z API, runtime’u i sieci. Nie chodzi już tylko o chroniczne sprawdzanie, czy coś się wywaliło, ale o monitoring obejmujący również wydarzenia niepasujące do zwykłego wzorca działania tej aplikacji albo operatora. Przykładowo próba odczytu tajemnic w nietypowym namespace, nagły wzrost operacji exec do podów, tworzenie tokenów serwisowych poza pipeline’em czy modyfikacja ról administracyjnych po godzinach – to sygnały, które trzeba zauważyć. Inaczej zostaje nam stara i mało imponująca strategia bezpieczeństwa polegająca na rozpoznaniu problemu, gdy będzie już bardzo duży.
[…]
Maciej Lelusz
Autor jest blogerem i niezależnym konsultantem z wieloletnim doświadczeniem w branży IT, specjalizującym się w wirtualizacji i cloud computingu. Posiada tytuły MCP, MCTS, VPC oraz VMware vExpert.
