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.
