Kubernetes jest dostarczany z elastycznością, a nie bezpieczeństwem jako domyślnym stanem. Każdy otwarty port, permisywna rola RBAC i nieograniczony pod to zaproszenie. Wzmacnianie klastra oznacza systematyczne zamykanie tych luk bez przerywania obciążeń, które od nich zależą. To nie jest ćwiczenie na liście kontrolnej—to bieżąca dyscyplina, która obejmuje warstwy tożsamości, sieci, obciążenia i łańcucha dostaw.
Najpierw zabezpiecz płaszczyznę kontroli
Serwer API to najcenniejszy cel w każdym klastrze. Zacznij od wyłączenia uwierzytelniania anonimowego i egzekwowania silnych metod uwierzytelniania—integracja OIDC z dostawcą tożsamości jest preferowana zamiast tokenów statycznych lub certyfikatów klienta, które nigdy nie wygasają. Ogranicz dostęp do magazynu danych etcd, ponieważ przechowuje każdy obiekt tajny i konfiguracyjny w postaci zwykłego tekstu, chyba że jest włączone szyfrowanie w spoczynku. Włącz szyfrowanie tajemnic za pomocą dostawcy KMS zamiast polegać na kodowaniu base64, które nie oferuje żadnej rzeczywistej ochrony. Rejestrowanie audytu powinno być włączone od pierwszego dnia; bez niego nie masz śladu kryminalistycznego, gdy coś pójdzie nie tak.
RBAC: Najmniejszy przywilej, a nie wygoda
Najczęstszym błędem konfiguracji w produkcyjnych klastrach są zbyt szerokie powiązania RBAC—cluster-admin przyznany kontom usług, które muszą tylko odczytywać pody w jednej przestrzeni nazw. Buduj role wokół rzeczywistych funkcji zawodowych i ograniczaj je do przestrzeni nazw, gdziekolwiek jest to możliwe. Unikaj symboli wieloznacznych i zasobów w definicjach Role i ClusterRole. Regularnie kontroluj powiązania za pomocą narzędzi takich jak kubectl auth can-i --list lub rbac-lookup, aby złapać przyrosty uprawnień. Konta usług zasługują na tę samą kontrolę co użytkownicy—wyłącz automatyczne montowanie tokenów konta usługi dla podów, które nie potrzebują dostępu do API.
Bezpieczeństwo podów: Założ kompromis
Pod Security Admission (które zastąpiło przestarzałe PodSecurityPolicy) pozwala na egzekwowanie profilów bazowych lub ograniczonych na poziomie przestrzeni nazw. Co najmniej zabroń uprzywilejowanych kontenerów, współdzielenia przestrzeni nazw hosta i eskalacji uprawnień. Ustaw runAsNonRoot: true i upuść wszystkie możliwości Linux domyślnie, dodając z powrotem tylko to, co jest wyraźnie wymagane. Systemy plików główne tylko do odczytu uniemożliwiają atakującym pisanie złośliwych plików binarnych do uruchomionego kontenera. Te kontrole mają znaczenie, ponieważ ucieczka kontenera lub luka w podatnym aplikacji nie powinna przełożyć się na pełny kompromis węzła.
Zasady sieciowe nie są opcjonalne
Domyślnie każdy pod w klastrze Kubernetes może komunikować się z każdym innym podem. Ten płaski model sieciowy to sen atakujących o ruchu bocznym. Zaimplementuj zasoby NetworkPolicy, aby egzekwować domyślny zakaz ruchu przychodzącego i wychodzącego, a następnie jawnie zezwalaj tylko na przepływy ruchu, które wymagają Twoje aplikacje. Wymaga to wtyczki CNI, która naprawdę obsługuje egzekwowanie NetworkPolicy—Calico, Cilium i inne pełnią tę rolę, ponieważ bazowy model sieciowy Kubernetes nic nie egzekwuje. Segmentacja przestrzeni nazw według granicy zaufania i warstwowanie zasad na górze daje ci rzeczywistą obronę w głębi.
Integralność obrazu i łańcucha dostaw
Wzmacnianie nie kończy się na konfiguracji czasu wykonywania—zaczyna się tym, co wdrażasz. Skanuj obrazy kontenerów pod kątem znanych luk w zabezpieczeniach, zanim dotrą do Twojego rejestru, i egzekwuj, że tylko podpisane, zweryfikowane obrazy mogą działać w Twoim klastrze za pomocą kontrolerów wstępu takich jak Kyverno lub OPA Gatekeeper. Przypinaj tagi obrazów do skrótów zamiast zmiennych tagów takich jak latest, które mogą się bezgłośnie zmienić pod Tobą. Ogranicz rejestry, z których pody mogą się pobierać, zamykając wspólną ścieżkę dla ataków na łańcuch dostaw, gdzie skompromitowane lub mylnie wpisane obrazy wkradają się do produkcji.
Zarządzanie tajemnicami poza domyślnymi ustawieniami Kubernetes
Natywne Kubernetes Secrets są lepsze niż nic, ale nie są prawdziwym rozwiązaniem do zarządzania tajemnicami. Rozważ integrację zewnętrznego menedżera tajemnic—Vault, AWS Secrets Manager lub podobny—i wstrzykuj tajemnice w czasie wykonywania zamiast przechowywać je jako obiekty klastra. Jeśli musisz używać natywnych Secrets, upewnij się, że szyfrowanie etcd jest włączone i RBAC ściśle ogranicza dostęp do odczytu, ponieważ każdy pod lub użytkownik z uprawnieniami get do tajemnic w przestrzeni nazw może eksfiltrować poświadczenia.
Ciągła weryfikacja, a nie jednorazowa konfiguracja
Konfiguracje wzmacniania się zmieniają w miarę upływu czasu, gdy wdrażane są nowe obciążenia i priorytety przesuwają się w kierunku szybkości niż bezpieczeństwa. Narzędzia takie jak kube-bench sprawdzają zgodność z CIS Kubernetes Benchmark, podczas gdy kube-hunter może symulować rozpoznawanie atakującego na twoim klastrze. Umieść te kontrole w potokach CI/CD, aby błędy konfiguracji zostały złapane, zanim dotrą do produkcji, zamiast podczas rozmowy dotyczącej reagowania na incydenty.
Wzmacnianie Kubernetes to mniej pojedyncze rozwiązanie, które rozwiązuje wszystkie problemy, a bardziej warstwowanie obrony w całej tożsamości, sieci, obciążeniu i łańcuchu dostaw—aby awaria w jednej warstwie nie kaskadowo przeniosła się na pełny kompromis. Aby dowiedzieć się więcej o wzorcach bezpieczeństwa infrastruktury chmury i narzędziach defensywnych, zapoznaj się z powiązanymi segmentami na platformie DEFENSE_GRID Korra Studio.
