Czynniki zagrożeń zarządzanego rozwiązania Kubernetes

Ukończone

W zarządzanym środowisku Kubernetes rozwiązywanie problemów z zabezpieczeniami obejmuje zrozumienie i ograniczenie zagrożeń w różnych wystąpieniach. Oto podział czynników zagrożeń w określonych wystąpieniach:

Naruszone konto

• Threat Factor: osoba atakująca uzyskuje dostęp do klastra Kubernetes za pośrednictwem skradzionych poświadczeń, tokenów interfejsu API lub kluczy. Może to prowadzić do nieautoryzowanego dostępu, kradzieży danych i złośliwych wdrożeń.
• Środki zaradcze: Zaimplementuj mechanizmy silnego uwierzytelniania, uwierzytelnianie wieloskładnikowe (MFA), regularną rotację poświadczeń i zasady dostępu do najniższych uprawnień.

Obrazy podatne na zagrożenia lub błędnie skonfigurowane

• Threat Factor: obrazy kontenerów z lukami w zabezpieczeniach lub błędami konfiguracji mogą być wykorzystywane przez osoby atakujące po wdrożeniu. Te luki w zabezpieczeniach mogą obejmować nieaktualne oprogramowanie, niezabezpieczone ustawienia domyślne lub osadzone wpisy tajne.
• Środki zaradcze: użyj narzędzi do skanowania obrazów, aby wykryć luki w zabezpieczeniach przed wdrożeniem, wymusić zasady pochodzenia obrazów i wdrożyć proces podpisywania obrazu kontenera.

Błędna konfiguracja środowiska

• Czynnik zagrożenia: błędy konfiguracji w ustawieniach platformy Kubernetes lub deskryptory wdrażania mogą uwidaczniać klastry atakom. Typowe problemy obejmują uwidocznione interfejsy pulpitu nawigacyjnego, nadmiernie permisywne ustawienia kontroli dostępu opartej na rolach i niezabezpieczone punkty końcowe.
• Środki zaradcze: Postępuj zgodnie z najlepszymi rozwiązaniami dotyczącymi bezpiecznej konfiguracji, regularnie przeprowadzaj inspekcję konfiguracji za pomocą zautomatyzowanych narzędzi i zatrudniaj kontrolery przyjęć w celu wymuszania zgodności z zasadami.

Poziom ataku aplikacji

• Threat Factor: aplikacje działające w kontenerach mogą być narażone na tradycyjne wektory ataków internetowych, takie jak wstrzyknięcie kodu SQL lub wykonywanie skryptów między witrynami (XSS), które mogą naruszyć bezpieczeństwo kontenera lub prowadzić do dalszego wykorzystania klastra.
• Środki zaradcze: Stosowanie najlepszych rozwiązań w zakresie zabezpieczeń aplikacji, takich jak walidacja danych wejściowych i kodowanie danych wyjściowych oraz używanie zapór aplikacji internetowych (WAFs). Zaimplementuj zabezpieczenia w potoku ciągłej integracji/ciągłego dostarczania i wdrażania (CD), w tym narzędzia do analizy statycznej i dynamicznej.

Atak na poziomie węzła

• Czynnik zagrożenia: jeśli osoba atakująca uzyska dostęp do węzła Kubernetes, może eskalować uprawnienia w celu kontrolowania całego klastra. Luki w zabezpieczeniach mogą wynikać z nieaktualnych systemów operacyjnych lub składników platformy Kubernetes.
• Środki zaradcze: zachowaj aktualizacje węzłów przy użyciu najnowszych poprawek zabezpieczeń, ogranicz dostęp do węzłów przy użyciu zasad sieciowych i zapór oraz zastosuj systemy wykrywania nieautoryzowanego dostępu do hosta (HIDS).

Nieautoryzowany ruch

• Czynnik zagrożenia: Nieautoryzowany dostęp do lub z klastra może wystąpić, jeśli zasady sieciowe nie są poprawnie skonfigurowane, co umożliwia atakującym eksfiltrację danych, dostarczanie złośliwego oprogramowania lub wykorzystywanie uwidocznionych usług.
• Środki zaradcze: Zaimplementuj ścisłe zasady sieciowe, aby kontrolować ruch przychodzący i wychodzący, segregować poufne obciążenia przy użyciu przestrzeni nazw i monitorować ruch pod kątem nietypowych wzorców.

Rozwiązanie tych zagrożeń w zarządzanym środowisku Kubernetes wymaga warstwowego podejścia zabezpieczeń, które obejmuje zarówno rozwiązania specyficzne dla platformy Kubernetes, jak i tradycyjne środki zabezpieczeń. Ciągłe monitorowanie, regularne inspekcje i przestrzeganie zasady najniższych uprawnień we wszystkich aspektach klastra to podstawowe składniki niezawodnej strategii zabezpieczeń platformy Kubernetes.

Typowe techniki ataków

• Wykorzystanie obrazów podatnych na zagrożenia — publiczna aplikacja podatna na zagrożenia w klastrze, która umożliwia początkowy dostęp do klastra. Niesławne przypadki: SolarWinds, Log4j
  
• Dostęp do uwidocznionych aplikacji — poufny interfejs uwidoczniony w Internecie stanowi zagrożenie bezpieczeństwa. Niektóre popularne struktury nie były przeznaczone do uwidocznienia w Internecie i dlatego domyślnie nie wymagają uwierzytelniania. W związku z tym uwidacznianie ich w Internecie umożliwia nieuwierzytelniony dostęp do poufnego interfejsu, który może umożliwić uruchamianie kodu lub wdrażanie kontenerów w klastrze przez złośliwego aktora. Przykłady takich interfejsów, które zostały wykorzystane, to Apache NiFi, Kubeflow, Argo Workflows, Weave Scope i pulpit nawigacyjny Kubernetes.
  
• Wdrażanie kontenerów backdoor — osoby atakujące uruchamiają złośliwy kod w kontenerze w klastrze. Korzystając z kontrolerów Kubernetes, takich jak DaemonSets lub Deployments, osoby atakujące upewniły się, że stała liczba kontenerów jest uruchamiana w jednym lub wszystkich węzłach w klastrze.
  
• Nadużycie w przypadku ról permissive SA — konto usługi (SA) reprezentuje tożsamość aplikacji na platformie Kubernetes. Domyślnie program SA jest instalowany dla każdego utworzonego zasobnika w klastrze. Za pomocą programu SA kontenery w zasobniku mogą wysyłać żądania do serwera interfejsu API Kubernetes. Osoby atakujące, które uzyskują dostęp do zasobnika, uzyskują dostęp do tokenu sa i wykonują akcje w klastrze zgodnie z uprawnieniami administratora. Jeśli kontrola dostępu oparta na rolach nie jest włączona, program SA ma nieograniczone uprawnienia w klastrze. Jeśli kontrola dostępu oparta na rolach jest włączona, jego uprawnienia są określane przez skojarzone z nim elementy RoleBindings i ClusterRoleBindings.
  
• Ucieczka do hosta — wolumin hostPath instaluje katalog lub plik z hosta do kontenera. Osoby atakujące, które mają uprawnienia do utworzenia nowego kontenera w klastrze, mogą utworzyć jeden z zapisywalnym woluminem hostPath i uzyskać trwałość na hoście bazowym. Na przykład ten ostatni można osiągnąć, tworząc zadanie cron na hoście.