Zagadnienia dotyczące sandboxingu podów

W przypadku wdrożeń piaskownicy zasobników w usłudze Azure Kubernetes Service (AKS) istnieje kilka aspektów do rozważenia w odniesieniu do zarządzania zasobami, zarządzania pamięcią, zarządzania CPU i zabezpieczeń.

Zarządzanie zasobami

Zarządzanie pamięcią i procesorem przy użyciu piaskownicy podów może być nieznane niektórym użytkownikom. Te zagadnienia są istotne podczas określania zasobów we wdrożeniu, zwłaszcza w przypadku większych i wrażliwych na zasoby obciążeń.

Składniki kata

W przypadku wdrożenia Kata, zazwyczaj wdrażane są dwie rodziny komponentów. Masz składniki hosta i składniki gościa.

• Główne składniki hosta obejmują Kata shim, Cloud Hypervisor i virtiofsd.
  • Kata shim zarządza cyklem życia maszyny wirtualnej pod.
  • Cloud Hypervisor jest monitorem maszyn wirtualnych (VMM) używanym przez warstwę pośrednią Kata.
  • virtiofsd to demon używany do udostępniania plików między każdą maszyną wirtualną Pod a hostem kontenera.
• Główne komponenty gościa obejmują obciążenia użytkownika, jądro maszyny wirtualnej pod oraz agenta Kata.
  • Agent Kata zarządza kontenerami wewnątrz maszyn wirtualnych (VM) Podów.

Zarządzanie pamięcią

Zasobniki Kata umożliwiają określenie ilości pamięci maszyny wirtualnej Podu, która obsługuje twoje obciążenia. Ważne jest, aby odpowiednio skonfigurować wartości tak, aby zasobnik miał wystarczające zasoby, ale nie powoduje przydzielenia nieużywanej pamięci do zasobnika.

Rozmiar pamięci maszyny wirtualnej podu

Dla każdego podu, który uruchamia kontener, przydzielana jest pewna ilość pamięci VM. Rozmiar pamięci tej maszyny wirtualnej obejmuje całą pamięć niezbędną do działania składników gościnnych Kata. Użytkownicy powinni zadbać o to, aby zabuforować dodatkową pamięć ponad oczekiwane zużycie obciążeń, aby uwzględnić zużycie innych składników gościa, takich jak agent Kata lub jądro maszyny wirtualnej. W dalszej części tego artykułu podano przykłady typowych wartości pamięci.

Rozmiar pamięci maszyny wirtualnej podu jest równy limitowi pamięci podu Kubernetes, który określa użytkownik. Użytkownik może zmienić wartość, zmieniając limit pamięci zasobnika; Jeśli nie określono żadnych wartości, zostanie zastosowany domyślny rozmiar 512Mi. Po uruchomieniu poda ten rozmiar staje się stały.

W miarę zwiększania rozmiaru pamięci maszyny wirtualnej zasobnika obciążenie pamięci klasy środowiska uruchomieniowego powinno wzrosnąć wraz z nim.

Obciążenie pamięci klasy środowiska uruchomieniowego

Obciążenia korzystające z technologii sandboxing dla zasobników są dostarczane z domyślną klasą środowiska uruchomieniowego kata (kata-vm-isolation), co wiąże się z domyślnymi narzutami na zasoby. Użytkownicy, którzy chcą bardziej precyzyjnej kontroli nad limitami przydziałów zasobów, mogą skonfigurować niestandardową klasę środowiska uruchomieniowego z określonymi obciążeniami zasobów. W takim przypadku użytkownicy powinni upewnić się, że wartość obciążenia pamięci klasy środowiska uruchomieniowego jest wystarczająca, aby obejmowało wszystkie oczekiwane użycie składników hosta wdrożenia kata. Obciążenie pamięci klasy środowiska uruchomieniowego nie musi uwzględniać oczekiwane zużycie pamięci komponentów gościa.

Możesz utworzyć wyspecjalizowane środowisko uruchomieniowe i określić obciążenie pamięci w klasie środowiska uruchomieniowego za pomocą overhead pola w RuntimeClass manifeście. Załóżmy na przykład, że chcę utworzyć środowisko uruchomieniowe dla obciążeń, których użycie będzie mniejsze:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: small-kata-pods
handler: kata
overhead:
  podFixed:
    memory: "120Mi"

Określanie zasobów nie jest wymagane, ale sugerowane, jeśli chcesz mieć lepszą kontrolę nad tym, ile zasobów jest przeznaczane na Twoje obciążenia. Jeśli używasz domyślnej kata-vm-isolation klasy środowiska uruchomieniowego i nie określisz żadnych obciążeń w języku YAML, obciążenie rozmiaru maszyny wirtualnej zasobnika domyślnie wynosi 512Mi i domyślnie obciążenie klasy środowiska uruchomieniowego wynosi 600Mi. To domyślne obciążenie środowiska uruchomieniowego jest obliczane przy użyciu domyślnego rozmiaru maszyny wirtualnej zasobnika (512Mi) oraz przybliżonej pamięci wymaganej przez składniki hosta dla takiego rozmiaru maszyny wirtualnej (~88Mi).

Obciążenia użytkowników

Gdy użytkownik wdraża obciążenie Kata, może używać pamięci do skonfigurowanego rozmiaru pamięci maszyny wirtualnej zasobnika pomniejszonego o inne składniki gościa, takie jak agent Kata lub jądro maszyny wirtualnej gościa.

Jeśli chcesz uzyskać przybliżenie pamięci używanej przez następujące składniki:

1. Połącz się z maszyną wirtualną pod (za pośrednictwem kubectl exec lub kubectl debug), aby otworzyć terminal wewnątrz pod.
2. Uruchom polecenie free.
3. Sprawdź kolumnę "used" w danych wyjściowych, aby uzyskać informacje o pamięci używanej przez jądro gościa/kata agenta.

Grupy pamięci

Gdy zasobnik Kata zostanie zaplanowany do uruchomienia, kubelet przypisuje zasobnik do pamięci cgroup. To cgroup wymusza limity/żądania pamięci dla poda, co pozwala użytkownikowi na zdefiniowanie dostępnych dla poda kwot zasobów.

W pamięci cgroupistnieją dwa ważne pola, które należy wziąć pod uwagę:

• memory.current określa, ile bajtów pamięci jest przydzielane dla składników hosta oraz jakiego rozmiaru pamięci jest przydzielany dla maszyny wirtualnej zasobnika.
• memory.max opcjonalny, zdefiniowany przez użytkownika górny limit dla memory.current dla zasobników, w których użytkownicy chcą nałożyć limit pamięci.
  • Narzędzie kubelet oblicza tę wartość jako sumę limitu pamięci zasobnika i narzutu pamięci klasy środowiska uruchomieniowego.

Jeśli wartość memory.current kiedykolwiek przekracza wartość memory.max, to jądro może wyzwolić OOMKill na podzie, jeśli zostanie wykryte ciśnienie pamięci.

Odwołuj się do wartości użycia

Użytkownicy mogą używać tych wartości jako punktu odniesienia dla typowego użycia pamięci i wartości w różnych zmiennych, które zostały omówione. Rozmiary pamięci maszyny wirtualnej zasobnika poniżej 128Mi nie są obsługiwane.

Zarządzanie procesorem CPU

Podobnie jak w przypadku pamięci, można również przydzielić zasoby procesora do obciążeń Kata. Jest to zalecane; bez deklarowania limitu procesora dla podu Kata, składniki hosta Kata mogą używać dowolnej mocy obliczeniowej dostępnej na węźle.

Rezerwowanie CPU

W przypadku rezerwowania CPU dla obciążeń Kata masz dwa pola do ustawienia.

• Obciążenie CPU klasy środowiska uruchomieniowego
• Limit procesora CPU zasobnika

Po określeniu co najmniej jednej z dwóch wartości, płaszczyzna sterowania rezerwuje określoną liczbę procesorów na węźle na potrzeby twojego obciążenia. Inne pody na tym samym węźle nie mogą uzyskać dostępu do tej pojemności zarezerwowanej.

Limit CPU dla Pod

Limit CPU dla poda można zadeklarować w manifeście aplikacji. Określony limit CPU poda definiuje ograniczenie liczby procesorów, których mogą używać kontenery na skojarzonej maszynie wirtualnej poda.

Jeśli określisz ułamki procesorów dla limitu CPU zasobnika, te ułamki zostaną zaokrąglone w górę do następnej liczby całkowitej. Zaokrąglona w górę liczba staje się liczbą procesorów wirtualnych przydzielonych do maszyny wirtualnej Pod, ale cgroup ograniczy obciążenie do konsumpcji tylko części ułamkowej określonej w limicie CPU zasobnika.

Jeśli liczba nie zostanie zadeklarowana, jeden procesor wirtualny zostanie przydzielony do maszyny wirtualnej zasobnika, jeśli pojemność jest dostępna w węźle. Nie ma limitu użycia procesora dla składników hosta Kata.

Obciążenie procesora CPU klasy środowiska uruchomieniowego

Obciążenie klasy środowiska uruchomieniowego należy określić, jeśli chcesz z góry zarezerwować część pojemności węzła dla składników hosta Kata.

Możesz określić obciążenie pamięci w klasie środowiska uruchomieniowego za pomocą overhead pola w RunTimeClass manifeście. Przykład:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: custom-kata-runtime
handler: kata
overhead:
  podFixed:
    cpu: "250m"

Najlepsze rozwiązania

Zarządzanie pamięcią

• Upewnij się, że określono rozmiary pamięci VM dla zasobnika (zdefiniowane w limits.memory manifeście) i odpowiednie kwoty zasobów dla wszystkich wdrożeń.
  • Upewnij się, że używasz niezerowego pod request, jeśli chcesz zapewnić, że część zasobów węzła jest zarezerwowana dla maszyny wirtualnej pod przed jej uruchomieniem. Żądanie powinno uwzględniać pod VM i kontenery, które mają być na nim uruchomione.
  • Upewnij się, że używasz niezerowego narzutu klasy uruchomieniowej, jeśli chcesz zarezerwować zasoby węzła dla składników hosta Kata przed uruchomieniem tych składników.
• Jeśli oczekujesz, że obciążenia zasobników będą szczególnie zasobochłonne, możesz odpowiednio określić limity dla VM zasobnika, aby upewnić się, że dostępne są wystarczające zasoby dla obciążeń.
• Zadeklaruj odpowiedni narzut pamięci klasy środowiska uruchomieniowego, aby zapewnić wystarczającą ilość pamięci dla składników hosta, ale nie przydzielaj zbyt wiele, aby uniknąć alokacji nieużywanej pamięci.

Zarządzanie procesorem CPU

• Jeśli węzeł zwykle ma dużo wolnych zasobów CPU, te rezerwacje mogą być niepotrzebne.

• Jeśli węzły zwykle działają na granicy zużycia CPU, rezerwacja większa niż zero zapewnia, że zasobniki mogą działać bardziej niezawodnie.

  • Możesz użyć żądań procesora CPU pod, aby upewnić się, że część pojemności procesora CPU na węźle jest zarezerwowana dla składników hosta Kata. Pojemność zarezerwowana dla określonego obciążenia nie jest dostępna dla innych obciążeń w węźle.

• Upewnij się, że określono żądania CPU, które Twoja infrastruktura może obsłużyć. Jeśli dostępna pojemność zbliża się do 0 lub żądanie jest za duże, obciążenia mogą się nie uruchomić.

• Dopasuj żądania CPU do jego limitów. Podkładka Kata nie ma wglądu w żądania. W związku z tym, jeśli nie zostanie zadeklarowany żaden limit CPU, maszyna wirtualna podu jest ograniczona do jednego procesora wirtualnego. Składniki hosta Kata, które mogą monitorować wartości żądań, wykorzystują pozostałą liczbę żądanych CPU i nie mają limitu zużycia CPU.

• Pojemność zarezerwowana dla określonego obciążenia nie jest dostępna dla innych obciążeń w węźle.

Przykładowe deklaracje

Zabezpieczenia

Pod Sandboxing oferuje użytkownikom atrakcyjną opcję izolacji ładunków od innych ładunków oraz hosta. Niemniej jednak należy wziąć pod uwagę ważne obawy dotyczące bezpieczeństwa.

Uprzywilejowane pody

Istnieją scenariusze, w których mogą być wymagane uprzywilejowane pody. Użytkownicy mogą uruchamiać uprzywilejowane zasobniki, ale żadne urządzenia hosta nie są dołączone do zasobnika.

Korzystanie z kontenerów uprzywilejowanych może prowadzić do dostępu do konta root na maszynie wirtualnej gościa, ale pozostaje odizolowane od hosta.

Uprzywilejowane zasobniki, nawet w piaskownicy zasobników, powinny być używane tylko w razie potrzeby. Zasobniki uprzywilejowane powinny nadal być zarządzane przez zaufanych użytkowników.

Woluminy pamięci wykorzystujące ścieżkę hosta

hostPath woluminy można zamontować w zasobnikach Kata. W przypadku sandboxingu Pod użycie hostPath woluminów może potencjalnie podważyć izolację zapewnianą przez Kata, ponieważ część systemu plików hosta jest widoczna bezpośrednio w kontenerze, co otwiera potencjalny wektor ataku. Ostrzeżenia stwarzane przez upstream powinny być również uznawane za istotne dla Pod sandboxingu.

Istnieją pewne wyjątki; pliki w obszarze /dev są instalowane w kontenerze z systemu gościa zamiast systemu hosta. Pomaga to zachować izolację kontenera w sytuacjach, w których ta ścieżka musi być zamontowana, aby działać.

Blokowanie hostPath przez Azure Policy

Usługa Azure Policy umożliwia użytkownikom stosowanie wymuszania na dużą skalę i zabezpieczeń w swoich składnikach klastra w sposób scentralizowany i spójny.

Istnieje zestaw wbudowanych zasad dla usługi AKS, które wymuszają najlepsze praktyki. Użytkownicy mogą korzystać z jednej z tych zasad, aby zablokować wdrożenia, które próbują zainstalować hostPaths.

Dalsze kroki

Gdy wszystko będzie gotowe, dowiedz się, jak wdrożyć piaskownicę podów w AKS.