W dzisiejszych czasach łatwo zauważyć, że Kubernetes przejął wiodącą rolę pośród systemów orkiestracji kontenerów. Pomimo bardzo wielu jego zalet, podobnie jak wszystkie inne systemy, wymaga zwrócenia odpowiedniej uwagi na zagadnienia związane z bezpieczeństwem. Coroczne statystyki prowadzone przez Cloud Native Computing Foundation wskazują, że w roku 2022 aż 40% respondentów, którzy wykorzystują kontenery w środowiskach produkcyjnych, uważało bezpieczeństwo jako największe wyzwanie podczas wdrażania i konfiguracji swoich usług. Taki wybór wydaje się bardzo zasadny, biorąc pod uwagę złożoność zagadnień związanych z bezpieczeństwem, jak również ich obecność na wszystkich poziomach systemu, od konfiguracji serwerów aż po implementację aplikacji.

W przypadku Kubernetesa zapewnienie odpowiednich zabezpieczeń może wydawać się jeszcze trudniejsze, głównie z powodu złożoności tego środowiska. Kubernetes nie jest systemem prostym we wdrożeniu i, co najważniejsze, nie zapewnia domyślnie wszystkich koniecznych zabezpieczeń. Odpowiednia konfiguracja infrastruktury wdrożeniowej, zagadnień sieciowych czy samego klastra w celu zminimalizowania ryzyka ataku wymaga odpowiedniej ilości pracy specjalistów, co jest szczególnie istotne w przypadku rozwiązań tzw. On-premise, czyli we własnej infrastrukturze serwerowej. Pozytywnym aspektem jest fakt, iż w usługach dostarczanych przez dostawców chmurowych, takich jak GCP czy AWS, wiele z tych zagadnień jest już rozwiązanych.

Niezależnie od wybranego modelu wdrożenia klastra, praca specjalistów od bezpieczeństwa nie kończy się na konfiguracji środowiska. Przeciwnie, dynamicznie zmieniający się ekosystem, składający się ze stale aktualizowanych aplikacji, usług czy narzędzi, jest ciągle narażony na różnego typu podatności.

W rankingu największych zagrożeń bezpieczeństwa OWASP Kubernetes Top Ten to właśnie niepoprawna konfiguracja wdrożonych usług (Insecure Workload Configurations) plasuje się na niechlubnym pierwszym miejscu. Reguła ta odnosi się w szczególności do uruchamiania kontenerów z odpowiednimi prawami dostępu do zasobów serwera. Dla przykładu, dodanie jednej z pozoru niegroźnej instrukcji (runAsUser: 0) do konfiguracji usługi, spowoduje uruchomienie procesu kontenera jako administrator systemu. Takie ustawienia mogą sprawić, że potencjalny hacker po zdobyciu dostępu do kontenera będzie w stanie uruchomić złośliwe oprogramowanie w systemie operacyjnym. Oczywiście, istnieją przypadki, gdzie wykorzystanie uprawnień użytkownika administratora będzie wymagane (np. w celu dostępu do przestrzeni dyskowej), jednak powinno się tego unikać, kiedy tylko jest to możliwe. Sposobem na uniknięcie problemu podatności na błędy w konfiguracji wdrożonych usług jest między innymi dostosowanie się do ustanowionych globalnych wymagań polityki bezpieczeństwa w klastrze.

Na kolejnej pozycji w rankingu OWASP znajdują się podatności w łańcuchu dostaw oprogramowania (Supply Chain Vulnerabilities). W tym punkcie zawierają się wszystkie zagrożenia dotyczące procesu dostarczania nowych wersji aplikacji, między innymi zależności od zewnętrznych pakietów mogących zawierać złośliwy kod. Problem złośliwych zależności może być szczególnie dotkliwy w przypadku korzystania z obrazów dostępnych w publicznych rejestrach takich jak Docker Hub. W celu zminimalizowania ryzyka, wszystkie obrazy kontenerów używane we wdrożonych aplikacjach (również obrazy pośrednie) powinny być w trybie ciągłym analizowane pod kątem występowania pakietów lub aplikacji systemowych, zawierających podatności. Może to być zrealizowane między innymi poprzez rozszerzenie procesów CI/CD o automatyczne skanowanie obrazów z wykorzystaniem istniejących narzędzi (np. kube-bench).

Trzecim ryzykiem bezpieczeństwa wymienionym w rankingu są zbyt liberalne reguły dostępu do zasobów (Overly Permissive RBAC). Domyślny mechanizm do zarządzania rolami dostępu poszczególnych użytkowników do zasobów w klastrach Kubernetes jest narzędziem pozwalającym na znaczne zwiększenie bezpieczeństwa systemu. Jednak w sytuacjach, gdy jest niepoprawnie skonfigurowany, może zwiększyć podatność na przełamanie obrony systemu. Kubernetes w celu zarządzania dostępami wykorzystuje role z przypisanymi listami operacji, które można wykonywać na wybranych zasobach. W każdym klastrze tworzone są też role domyślne, takie jak rola administratora klastra, pozwalająca na wykonywanie wszelkich możliwych operacji na wszystkich zasobach. Nadużywanie tej roli jest zdecydowanie niewskazane. Dużo lepszym rozwiązaniem jest tworzenie dedykowanych ról z minimalnym zakresem dostępów, co znacznie minimalizuje ryzyko nadużyć.

Na kolejnych pozycjach rankingu wymieniane są między innymi: źle skonfigurowane narzędzia do zbierania logów i monitoringu, błędy w zarządzaniu hasłami, jak również źle skonfigurowane komponenty klastra i przestarzałe oprogramowania klastra.

W celu odpowiedniego zaadresowania wszystkich aspektów bezpieczeństwa w ekosystemie Kubernetesa, z pewnością potrzeba odpowiednio dużego nakładu pracy wykwalifikowanego zespołu specjalistów. Szczególnym wyzwaniem mogą wydawać się kwestie bezpiecznej konfiguracji całej infrastruktury, środowiska wdrożeniowego czy samego klastra. Jednak poprzez przytoczone publikacje omawiające najczęściej występujące zagrożenia, jak i wiele narzędzi wspomagających proces weryfikacji konfiguracji jesteśmy w stanie wdrożyć bezpieczną infrastrukturę wykorzystującą Kubernetsa. Takie podejście pozwoli zminimalizować ryzyko wielu podatności.