Czy Twój klaster Kubernetes jest bezpieczny, czy po prostu działa?Domyślne konfiguracje Kubernetes przedkładają łatwość obsługi nad bezpieczeństwo. Bez celowego zabezpieczenia klastry są podatne na ucieczki kontenerów, eskalację uprawnień, ruchy boczne i kradzież danych. Ta lista kontrolna obejmuje wszystkie mechanizmy bezpieczeństwa, które należy wdrożyć w środowiskach produkcyjnych Kubernetes.
Kluczowe wnioski
- Domyślny Kubernetes nie jest bezpieczny:Gotowe konfiguracje umożliwiają uprzywilejowane kontenery, nieograniczony dostęp do sieci i szerokie uprawnienia serwera API.
- RBAC to Twoja pierwsza obrona:Ogranicz dostęp do serwera API do minimum wymaganego dla każdego konta usługi i użytkownika.
- Zasady sieciowe zapobiegają ruchom bocznym:Bez zasad sieciowych każdy pod może komunikować się z każdym innym pod — płaska sieć wewnątrz klastra.
- Standardy bezpieczeństwa kapsuł zastępują PSP:Dopuszczenie zabezpieczeń podów (PSA) wymusza ograniczenia bezpieczeństwa na wszystkich podach.
- Bezpieczeństwo łańcucha dostaw ma znaczenie:Weryfikuj pochodzenie obrazów, skanuj pod kątem luk w zabezpieczeniach i egzekwuj zasady dotyczące obrazów poprzez kontrolę dostępu.
Kubernetes Lista kontrolna bezpieczeństwa
API Bezpieczeństwo serwera
- Włącz RBAC i wyłącz uwierzytelnianie anonimowe
- Używaj silnego uwierzytelniania (OIDC, opartego na certyfikatach) — a nie podstawowego uwierzytelniania lub tokenów statycznych
- Ogranicz dostęp serwera API do znanych zakresów adresów IP (zarządzany Kubernetes: korzystaj z autoryzowanych sieci)
- Włącz rejestrowanie audytu dla wszystkich żądań serwera API
- Wyłącz funkcje alfa/beta w klastrach produkcyjnych
- Skonfiguruj kontrolery dostępu: PodSecurity, ResourceQuota, LimitRange
Najlepsze praktyki RBAC
- Postępuj zgodnie z najniższymi uprawnieniami: brak powiązań ClusterAdmin dla kont usług
- Jeśli to możliwe, używaj ról z przestrzenią nazw zamiast ClusterRoles
- Regularnie przeprowadzaj audyty RBAC za pomocą narzędzi takich jak kubectl-who-can i rbac-lookup
- Nigdy nie udzielaj uprawnień wieloznacznych (czasowniki: ["*"], zasoby: ["*"])
- Ogranicz dostęp do sekretów — zezwalaj na pobieranie/listę sekretów tylko tym zasobnikom, które ich potrzebują
- Użyj oddzielnych kont usług dla każdej aplikacji (nie domyślnego konta usługi)
Bezpieczeństwo sieci
- Zaimplementuj zasady sieciowe z domyślną odmową we wszystkich przestrzeniach nazw
- Zezwalaj tylko na wymagany ruch przychodzący i wychodzący na aplikację
- Użyj CNI obsługującego NetworkPolicies (Calico, Cilium, Antrea)
- Szyfruj komunikację między kapsułami za pomocą usługi mesh mTLS (Istio, Linkerd)
- Ograniczanie ruchu wychodzącego do znanych zewnętrznych punktów końcowych (zapobieganie wyciekaniu danych)
- Izoluj wrażliwe obciążenia w dedykowanych przestrzeniach nazw przy użyciu rygorystycznych zasad
Bezpieczeństwo kapsuły
- Włącz dostęp do Pod Security na poziomie przestrzeni nazw (wymuszaj „ograniczony” profil)
- Uruchamiaj kontenery jako użytkownik inny niż root (runAsNonRoot: true)
- Użyj głównego systemu plików tylko do odczytu (readOnlyRootFilesystem: true)
- Porzuć wszystkie możliwości, dodaj tylko to, co jest potrzebne (upuść: ["ALL"])
- Wyłącz eskalację uprawnień (allowPrivilegeEscalation: false)
- Ustaw limity zasobów (procesor, pamięć) na wszystkich kontenerach, aby zapobiec nadużywaniu zasobów
- Nie montuj tokena konta usługi, jeśli nie jest to konieczne (automountServiceAccountToken: false)
Bezpieczeństwo obrazu
- Przed wdrożeniem przeskanuj wszystkie obrazy pod kątem luk w zabezpieczeniach (Trivy, Snyk)
- Użyj minimalnych obrazów podstawowych (distroless, Alpine), aby zmniejszyć powierzchnię ataku
- Podpisuj obrazy kontenerów i weryfikuj podpisy przy przyjęciu (cosign, notacja)
- Zezwalaj tylko na obrazy z zaufanych rejestrów (wymuszaj poprzez kontrolę dostępu)
- Nigdy nie używaj tagu :latest — przypinaj do konkretnych skrótów obrazów, aby zapewnić ich powtarzalność
- Regularnie przebudowuj i aktualizuj obrazy podstawowe, aby uwzględnić poprawki zabezpieczeń
Zarządzanie tajemnicami
- Nie przechowuj wpisów tajnych w zmiennych środowiskowych lub ConfigMaps
- Użyj zewnętrznego zarządzania sekretami (HashiCorp Vault, AWS Menedżer sekretów, Azure Key Vault)
- Jeśli używasz sekretów Kubernetes, włącz szyfrowanie w stanie spoczynku (EncryptionConfiguration)
- Regularnie zmieniaj sekrety dzięki automatycznej rotacji za pośrednictwem zewnętrznych tajnych operatorów
- Ogranicz dostęp RBAC do sekretów — większość podów nie powinna być w stanie wyświetlić listy wszystkich sekretów
Monitorowanie i wykrywanie
- Włącz rejestrowanie audytu Kubernetes i przekaż do SIEM
- Wdróż monitorowanie bezpieczeństwa środowiska wykonawczego (Falco, Sysdig)
- Monitoruj: nieoczekiwane wykonanie procesu, połączenia sieciowe, modyfikacje plików, eskalację uprawnień
- Powiadomienie dotyczące: nowego utworzenia ClusterRoleBinding, tajnego dostępu przez nieoczekiwane zasobniki, poleceń wykonywania kontenerów
- Implementuj naruszenia zasad bezpieczeństwa kapsuły jako alerty SIEM
Punkt odniesienia CIS Kubernetes
Centrum Bezpieczeństwa Internetowego (CIS) publikuje szczegółowe testy porównawcze bezpieczeństwa dla Kubernetes. Użyj kube-bench, aby automatycznie ocenić klaster pod kątem testów porównawczych CIS. Przed wdrożeniem produkcyjnym zajmij się wszystkimi krytycznymi i wysokimi wynikami. Zarządzane usługi Kubernetes (EKS, AKS, GKE) automatycznie obsługują niektóre elementy testu porównawczego, ale elementy odpowiedzialne za klienta nadal wymagają konfiguracji.
Jak Opsio zabezpiecza Kubernetes
- Ocena bezpieczeństwa klastra:Oceniamy Twoje klastry Kubernetes pod kątem testów porównawczych CIS i najlepszych praktyk dostawców usług w chmurze.
- Implementacja hartowania:Wdrażamy wszystkie elementy listy kontrolnej, w tym RBAC, zasady sieciowe, bezpieczeństwo podów i monitorowanie.
- Monitorowanie czasu wykonania:Nasz SOC monitoruje klastry Kubernetes pod kątem zdarzeń związanych z bezpieczeństwem i nietypowego zachowania.
- Egzekwowanie zasad:Wdrażamy OPA/Gatekeeper lub Kyverno, aby automatycznie egzekwować zasady bezpieczeństwa.
- Bieżące zarządzanie:Regularne przeglądy bezpieczeństwa, ponowna ocena testów porównawczych CIS i aktualizacje konfiguracji zabezpieczeń.
Często zadawane pytania
Jaka jest najważniejsza kontrola bezpieczeństwa Kubernetes?
Zasady sieciowe z domyślną odmową. Bez zasad sieciowych każdy pod może komunikować się z każdym innym pod — zaatakowana aplikacja internetowa może uzyskać bezpośredni dostęp do pod bazy danych, stosu monitorowania i serwera Kubernetes API. Zasady sieciowe „domyślna odmowa” natychmiast zmniejszają promień wybuchu każdego naruszenia bezpieczeństwa kontenera.
Czy powinienem używać siatki usług dla bezpieczeństwa?
Usługa mesh (Istio, Linkerd) dodaje mTLS pomiędzy usługami, zapewniając szyfrowanie i uwierzytelnianie dla całej komunikacji między kapsułami. Jeśli przetwarzasz wrażliwe dane lub musisz spełnić wymagania dotyczące szyfrowania podczas przesyłania, siatka usług jest cenna. W prostszych środowiskach same zasady sieciowe mogą być wystarczające.
Jak bezpiecznie obsługiwać sekrety w Kubernetes?
Użyj zewnętrznego menedżera wpisów tajnych (HashiCorp Vault, AWS Menedżer wpisów tajnych, Azure Key Vault) z operatorem kluczy tajnych Kubernetes (Operator kluczy zewnętrznych, Operator sekretów skarbca). Dzięki temu tajemnice nie dostaną się do Gita, zapewniają rejestrowanie inspekcji, umożliwiają rotację i centralizują zarządzanie sekretami w obciążeniach Kubernetes i innych niż Kubernetes.