Dostęp kontenera zabezpieczeń do zasobów przy użyciu wbudowanych funkcji zabezpieczeń systemu Linux

Z tego artykułu dowiesz się, jak zabezpieczyć dostęp kontenera do zasobów dla obciążeń usługi Azure Kubernetes Service (AKS).

Omówienie

W taki sam sposób, jak należy przyznać użytkownikom lub grupom wymagane minimalne uprawnienia, należy również ograniczyć kontenery tylko do niezbędnych akcji i procesów. Aby zminimalizować ryzyko ataku, należy unikać konfigurowania aplikacji i kontenerów, które wymagają eskalowanych uprawnień lub dostępu głównego.

Możesz użyć wbudowanych kontekstów zabezpieczeń zasobnika Kubernetes, aby zdefiniować więcej uprawnień, takich jak użytkownik lub grupa do uruchomienia jako, możliwości systemu Linux do uwidocznienia lub ustawienia allowPrivilegeEscalation: false w manifeście zasobnika. Aby uzyskać więcej informacji na temat najlepszych praktyk, odwiedź Bezpieczny dostęp zasobnika do zasobów.

Aby poprawić izolację hosta i zmniejszyć ruch boczny w systemie Linux, możesz użyć przestrzeni nazw użytkownika.

Aby uzyskać jeszcze bardziej szczegółową kontrolę nad akcjami kontenera, możesz użyć wbudowanych funkcji zabezpieczeń systemu Linux, takich jak AppArmor i seccomp.

1. Zdefiniuj funkcje zabezpieczeń systemu Linux na poziomie węzła.
2. Wdrażanie funkcji poprzez manifest pod.

Wbudowane funkcje zabezpieczeń systemu Linux są dostępne tylko w węzłach i zasobnikach systemu Linux.

Przestrzenie nazw użytkowników

Zasobniki systemu Linux działają domyślnie przy użyciu kilku przestrzeni nazw: przestrzeni nazw sieci w celu odizolowania tożsamości sieciowej i przestrzeni nazw PID w celu odizolowania procesów. Przestrzeń nazw użytkownika izoluje użytkowników wewnątrz kontenera od użytkowników na hoście. Ogranicza to również zakres możliwości oraz interakcje poda z resztą systemu.

Identyfikatory UID i GID w kontenerze są mapowane na nieuprzywilejowanych użytkowników na hoście, więc wszystkie interakcje z resztą hosta odbywają się z użyciem tych nieuprzywilejowanych identyfikatorów UID i GID. Na przykład użytkownik root wewnątrz kontenera (UID 0) może być przypisany do użytkownika 65536 na hoście. Platforma Kubernetes tworzy mapowanie, aby zagwarantować, że nie nakłada się na inne zasobniki, korzystając z przestrzeni nazw użytkownika w systemie.

Implementacja platformy Kubernetes ma pewne kluczowe korzyści:

• Zwiększona izolacja hosta: jeśli kontener przekracza granice kontenera, nawet jeśli działa jako użytkownik root wewnątrz kontenera, nie ma żadnych uprawnień na hoście. Powodem jest to, że identyfikatory UID i GID kontenera są mapowane na użytkowników bez uprawnień na hoście. Jeśli dojdzie do przełamania kontenera, przestrzenie nazw użytkownika znacznie chronią, które pliki na hoście kontener może odczytywać/zapisywać i do których procesów może wysyłać sygnały. Przyznane możliwości są prawidłowe tylko wewnątrz przestrzeni nazw użytkownika, a nie na hoście.

• Zapobieganie ruchom bocznym: ponieważ identyfikatory UID i GID dla różnych kontenerów są mapowane na różne, nienakładające się identyfikatory UID i identyfikatory GID na hoście, kontenerom jest trudniej zaatakować się nawzajem. Załóżmy na przykład, że kontener A działa z różnymi identyfikatorami UID i GID na hoście niż kontener B. W przypadku wyłamania kontenera operacje, które może wykonywać na plikach i procesach kontenera B, są ograniczone: tylko odczyt/zapis, tylko to, co plik pozwala innym. Ale nawet to nie jest możliwe, ponieważ istnieje dodatkowa blokada na katalogu nadrzędnym głównego woluminu poda, aby upewnić się, że tylko GID poda ma dostęp.

• Zasada Honor Least-privilege: Ponieważ identyfikatory UID i GID są mapowane na nieuprzywilejowanych użytkowników na hoście, przywileje otrzymują tylko ci użytkownicy, którzy potrzebują przywilejów na hoście (i wyłączają przestrzenie nazw użytkowników). Bez przestrzeni nazw użytkowników nie ma separacji między użytkownikami kontenera a użytkownikami hosta. Nie można uniknąć nadawania uprawnień na hoście procesom, które nie są mu potrzebne, gdy potrzebują uprawnień tylko wewnątrz kontenera.

• Włączanie nowych przypadków użycia: przestrzenie nazw użytkowników umożliwiają kontenerom uzyskanie pewnych możliwości wewnątrz własnej przestrzeni nazw użytkownika bez wpływu na hosta. Możliwości ograniczone do poda odblokowują nowe opcje, takie jak uruchamianie aplikacji wymagających uprzywilejowanych operacji bez udzielania pełnych uprawnień głównego użytkownika na hoście systemu. Typowe nowe przypadki użycia, które można zaimplementować bezpiecznie, to: uruchamianie zagnieżdżonych kontenerów i tworzenie nieuprzywilejowanych kontenerów.

• Konfiguracja kontenera nieuprzywilejowanego: Większość procesu tworzenia oraz konfigurowania kontenera nie jest uruchamiana jako root użytkownik na hoście, co znacznie ogranicza wpływ wielu CVE.

Żadne z tych elementów nie jest prawdziwe, gdy przestrzenie nazw użytkownika nie są używane. Jeśli kontener działa jako root, gdy przestrzenie nazw użytkownika nie są używane, proces jest uruchamiany jako root na hoście, uprawnienia są prawidłowe na hoście, a konfiguracja kontenera jest wykonywana jako root na hoście.

Zanim rozpoczniesz

Przed rozpoczęciem upewnij się, że masz następujące elementy:

• Istniejący klaster AKS. Jeśli nie masz klastra, utwórz go przy użyciu interfejsu wiersza polecenia platformy Azure, programu Azure PowerShell lub witryny Azure Portal.
• Minimalna wersja Kubernetes 1.33 dla węzłów płaszczyzny sterowania i węzłów roboczych. Jeśli nie używasz platformy Kubernetes w wersji 1.33 lub nowszej, musisz uaktualnić wersję platformy Kubernetes.
• Węzły robocze z systemem Azure Linux 3.0 lub Ubuntu 24.04. Jeśli nie używasz tych wersji systemu operacyjnego, nie będziesz mieć minimalnych wymagań dotyczących stosu , aby włączyć przestrzenie nazw użytkowników. Należy uaktualnić wersję systemu operacyjnego.

Ograniczenia

• Przestrzenie nazw użytkownika (user-namespaces) to funkcja jądra systemu Linux, która nie jest obsługiwana dla pul węzłów systemu Windows.
• Nie wahaj się zapoznać z dokumentacją platformy Kubernetes dotyczącą przestrzeni nazw użytkowników, w szczególności w sekcji ograniczeń.

Włącz przestrzenie nazw użytkowników

Nie ma żadnych konfiguracji potrzebnych do korzystania z tej funkcji. Jeśli używasz wymaganej wersji usługi AKS, wszystko działa od razu.

1. Utwórz plik o nazwie mypod.yaml i skopiuj go w następującym manifeście:

   Aby używać przestrzeni nazw użytkownika, plik yaml musi mieć pole hostUsers: false.

   apiVersion: v1
   kind: Pod
   metadata:
     name: userns
   spec:
     hostUsers: false
     containers:
     - name: shell
       command: ["sleep", "infinity"]
       image: debian
   

2. Wdróż aplikację przy użyciu kubectl apply polecenia i określ nazwę manifestu YAML.

   kubectl apply -f mypod.yaml
   

3. Sprawdź stan wdrożonych zasobników za pomocą polecenia kubectl get pods.

   kubectl get pods
   

4. Uruchom polecenie exec w podzie, aby sprawdzić za pomocą polecenia :

   kubectl exec -ti userns -- bash
   # Now inside the pod run
   cat /proc/self/uid_map
   

Dane wyjściowe powinny mieć wartość 65536 w ostatniej kolumnie. Przykład:

0  833617920      65536

CVE, których wpływ został złagodzony

Poniżej przedstawiono niektóre CVE, które są całkowicie lub częściowo łagodzone przy użyciu przestrzeni nazw użytkowników.

Należy pamiętać, że lista nie jest wyczerpująca; jest to tylko wybór CVE o wysokim wyniku, które zostały zabezpieczone.

• CVE-2019-5736 — Wynik 8,6 (WYSOKI)
• CVE 2024-21262: Wynik 8,6 (WYSOKI)
• CVE 2022-0492: Wynik 7.8 (WYSOKI)
• CVE-2021-25741: Wynik: 8.1 (WYSOKI) / 8.8 (WYSOKI)
• CVE-2017-1002101: Wynik: 9.6 (KRYTYCZNY) / 8.8(WYSOKI)

Aby dowiedzieć się więcej, przeczytaj ten wpis w blogu z dodatkowymi informacjami na temat przestrzeni nazw użytkowników.

Ochrona aplikacji

Aby ograniczyć akcje kontenera, możesz użyć modułu zabezpieczeń jądra systemu Linux AppArmor . Aplikacja AppArmor jest dostępna w ramach bazowego systemu operacyjnego węzła usługi AKS i jest domyślnie włączona. Tworzone są profile AppArmor, które ograniczają akcje odczytu, zapisu lub wykonywania albo funkcje systemowe, takie jak instalowanie systemów plików. Domyślne profile AppArmor ograniczają dostęp do różnych lokalizacji /proc i /sys zapewniają metodę logicznego izolowania kontenerów od węzła bazowego. Aplikacja AppArmor działa w przypadku każdej aplikacji działającej w systemie Linux, a nie tylko zasobników Kubernetes.

Aby zobaczyć działanie AppArmor, poniższy przykład tworzy profil, który uniemożliwia zapisywanie w plikach.

1. SSH do węzła AKS.

2. Utwórz plik o nazwie deny-write.profile.

3. Skopiuj i wklej następującą zawartość:

   #include <tunables/global>
   profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
     #include <abstractions/base>
   
     file,
     # Deny all file writes.
     deny /** w,
   }
   

Profile AppArmor są dodawane przy użyciu apparmor_parser polecenia .

1. Dodaj profil do aplikacji AppArmor.

2. Określ nazwę profilu utworzonego w poprzednim kroku:

   sudo apparmor_parser deny-write.profile
   

   Jeśli profil został poprawnie przeanalizowany i zastosowany do aplikacji AppArmor, nie zobaczysz żadnych danych wyjściowych i wrócisz do wiersza polecenia.

3. Na komputerze lokalnym utwórz manifest zasobnika o nazwie aks-apparmor.yaml. Ten manifest:

   • Definiuje adnotację dla elementu container.apparmor.security.beta.kubernetes.
   • Odwołuje się do profilu deny-write utworzonego w poprzednich krokach.

   apiVersion: v1
   kind: Pod
   metadata:
     name: hello-apparmor
     annotations:
       container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
   spec:
     containers:
     - name: hello
       image: mcr.microsoft.com/dotnet/runtime-deps:6.0
       command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
   

4. Po wdrożeniu zasobnika uruchom następujące polecenie i sprawdź, czy zasobnik hello-apparmor ma stan Uruchomione :

   kubectl get pods
   
   NAME             READY   STATUS    RESTARTS   AGE
   aks-ssh          1/1     Running   0          4m2s
   hello-apparmor   0/1     Running   0          50s
   

Aby uzyskać więcej informacji na temat aplikacji AppArmor, zobacz Profile AppArmor na platformie Kubernetes.

Bezpieczne przetwarzanie (seccomp)

Podczas gdy aplikacja AppArmor działa dla dowolnej aplikacji systemu Linux, seccomp (secure computing) działa na poziomie procesu. Seccomp jest również modułem zabezpieczeń jądra systemu Linux i jest natywnie obsługiwany przez środowisko uruchomieniowe używane przez containerd węzły usługi AKS. Dzięki seccomp można ograniczyć wywołania systemowe kontenera. Seccomp ustanawia dodatkową warstwę ochrony przed typowymi lukami w zabezpieczeniach wywołań systemowych wykorzystywanymi przez złośliwych aktorów i umożliwia określenie domyślnego profilu dla wszystkich zadań w węźle.

Konfigurowanie domyślnego profilu seccomp (wersja zapoznawcza)

Domyślne profile seccomp można stosować przy użyciu niestandardowych konfiguracji węzłów podczas tworzenia nowej puli węzłów systemu Linux. W usłudze AKS są obsługiwane dwie wartości: RuntimeDefault i Unconfined. Niektóre obciążenia mogą wymagać mniejszej liczby ograniczeń wywołań systemowych niż inne. Oznacza to, że mogą one zakończyć się niepowodzeniem podczas wykonywania z profilem "RuntimeDefault". Aby uniknąć takiego błędu, możesz określić profil Unconfined. Jeśli twoje obciążenie wymaga profilu niestandardowego, zobacz Konfigurowanie profilu seccomp niestandardowego.

Ograniczenia

• SeccompDefault nie jest obsługiwanym parametrem dla pul węzłów systemu Windows.
• Funkcja SeccompDefault jest dostępna od 2024-09-02-preview API.

Zarejestruj flagę KubeletDefaultSeccompProfilePreview funkcji

1. Zarejestruj funkcję flagi KubeletDefaultSeccompProfilePreview przy użyciu polecenia az feature register.

   az feature register --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"
   

   Wyświetlenie stanu Zarejestrowane trwa kilka minut.

2. Sprawdź stan rejestracji przy użyciu az feature show polecenia .

   az feature show --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"
   

3. Gdy stan odzwierciedla Zarejestrowano, odśwież rejestrację dostawcy zasobów Microsoft.ContainerService za pomocą polecenia az provider register.

   az provider register --namespace Microsoft.ContainerService
   

Ograniczanie wywołań systemowych kontenera za pomocą polecenia seccomp

1. Wykonaj kroki, aby zastosować profil seccomp w konfiguracji narzędzia kubelet, określając wartość "seccompDefault": "RuntimeDefault".

RuntimeDefault używa domyślnego profilu seccomp kontenera, ograniczając niektóre wywołania systemowe w celu zwiększenia bezpieczeństwa. Ograniczone wywołania systemowe zakończą się niepowodzeniem. Aby uzyskać więcej informacji, zobacz domyślny profil seccomp containerD.

2. Sprawdź, czy konfiguracja została zastosowana.

Możesz potwierdzić, że ustawienia są stosowane do węzłów, łącząc się z hostem i sprawdzając, czy zmiany konfiguracji zostały wprowadzone w systemie plików.

3. Rozwiązywanie problemów z błędami obciążeń roboczych.

Gdy ustawienie SeccompDefault jest włączone, domyślny profil seccomp środowiska uruchomieniowego kontenera jest domyślnie używany dla wszystkich obciążeń zaplanowanych w węźle. Może to spowodować niepowodzenie obciążeń z powodu zablokowanych wywołań systemu. Jeśli wystąpił błąd obciążenia, mogą wystąpić błędy, takie jak:

• Obciążenie pojawia się niespodziewanie po włączeniu funkcji z błędem "odmowa uprawnień".
• Komunikaty o błędach seccomp można również zobaczyć w auditd lub dzienniku systemowym, zastępując SCMP_ACT_ERRNO na SCMP_ACT_LOG w domyślnym profilu.

Jeśli wystąpią powyższe błędy, zalecamy zmianę profilu seccomp na Unconfined. Unconfined nie nakłada żadnych ograniczeń na systemcalls, zezwalając na wszystkie wywołania systemowe, co zmniejsza bezpieczeństwo.

Konfigurowanie niestandardowego profilu seccomp

Dzięki niestandardowemu profilowi seccomp możesz mieć bardziej szczegółową kontrolę nad ograniczonymi syscallami. Dostosuj się do najlepszych praktyk przyznawania kontenerowi minimalnych uprawnień niezbędnych do uruchomienia:

• Definiowanie za pomocą filtrów, jakie akcje mają zezwalać lub odrzucać.
• Dodawanie adnotacji do skojarzenia z filtrem seccomp w manifeście YAML zasobnika.

Aby zobaczyć seccomp w akcji, utwórz filtr, który uniemożliwia modyfikację uprawnień pliku.

1. SSH do węzła AKS.

2. Utwórz filtr seccomp o nazwie /var/lib/kubelet/seccomp/prevent-chmod.

3. Skopiuj i wklej następującą zawartość:

   {
     "defaultAction": "SCMP_ACT_ALLOW",
     "syscalls": [
       {
         "name": "chmod",
         "action": "SCMP_ACT_ERRNO"
       },
       {
         "name": "fchmodat",
         "action": "SCMP_ACT_ERRNO"
       },
       {
         "name": "chmodat",
         "action": "SCMP_ACT_ERRNO"
       }
     ]
   }
   

   W wersji 1.19 lub nowszej należy skonfigurować:

   {
     "defaultAction": "SCMP_ACT_ALLOW",
     "syscalls": [
       {
         "names": ["chmod","fchmodat","chmodat"],
         "action": "SCMP_ACT_ERRNO"
       }
     ]
   }
   

4. Na komputerze lokalnym utwórz manifest zasobnika o nazwie aks-seccomp.yaml i wklej następującą zawartość. Ten manifest:

   • Definiuje adnotację dla elementu seccomp.security.alpha.kubernetes.io.
   • Odwołuje się do filtru prevent-chmod utworzonego w poprzednim kroku.

   apiVersion: v1
   kind: Pod
   metadata:
     name: chmod-prevented
     annotations:
       seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod
   spec:
     containers:
     - name: chmod
       image: mcr.microsoft.com/dotnet/runtime-deps:6.0
       command:
         - "chmod"
       args:
        - "777"
        - /etc/hostname
     restartPolicy: Never
   

   W wersji 1.19 lub nowszej należy skonfigurować:

   apiVersion: v1
   kind: Pod
   metadata:
     name: chmod-prevented
   spec:
     securityContext:
       seccompProfile:
         type: Localhost
         localhostProfile: prevent-chmod
     containers:
     - name: chmod
       image: mcr.microsoft.com/dotnet/runtime-deps:6.0
       command:
         - "chmod"
       args:
        - "777"
        - /etc/hostname
     restartPolicy: Never
   

5. Wdróż przykładowy zasobnik przy użyciu polecenia kubectl apply :

   kubectl apply -f ./aks-seccomp.yaml
   

6. Wyświetl status pody za pomocą polecenia kubectl get pods.

   • Moduł zgłasza błąd.
   • Polecenie chmod jest blokowane przez filtr seccomp, jak pokazano w przykładowych danych wyjściowych:

   kubectl get pods
   
   NAME                      READY     STATUS    RESTARTS   AGE
   chmod-prevented           0/1       Error     0          7s
   

Aby uzyskać pomoc dotyczącą rozwiązywania problemów z profilem seccomp, zobacz artykuł Rozwiązywanie problemów z konfiguracją profilu seccomp w usłudze Azure Kubernetes Service.

Opcje profilu zabezpieczeń seccomp

Profile zabezpieczeń Seccomp to zbiór zdefiniowanych wywołań systemowych, które są dozwolone lub ograniczone. Większość środowisk uruchomieniowych kontenerów ma domyślny profil seccomp, który jest podobny, jeśli nie jest taki sam, jak używany przez platformę Docker. Aby uzyskać więcej informacji na temat dostępnych profili, zobacz domyślne profile seccomp Docker lub containerD.

Usługa AKS używa domyślnego profilu seccomp containerD dla naszego środowiska RuntimeDefault podczas konfigurowania seccomp przy użyciu niestandardowej konfiguracji węzła.

Znaczące wywołania systemowe (syscalls) zablokowane w domyślnym profilu

Zarówno Docker, jak i containerD utrzymują listy bezpiecznych dozwolonych wywołań systemowych. Ta tabela zawiera listę znaczących (ale nie wszystkich) poleceń syscall, które są skutecznie blokowane, ponieważ nie znajdują się na liście dozwolonych. Jeśli którekolwiek z zablokowanych wywołań systemowych wymaga ich obciążenie, nie używaj profilu seccomp RuntimeDefault.

Po wprowadzeniu zmian w usłudze Docker i containerD usługa AKS aktualizuje domyślną konfigurację tak, aby odpowiadała. Aktualizacje tej listy mogą spowodować awarię obciążenia roboczego. Aby uzyskać aktualizacje dotyczące wydania, zobacz notatki o wydaniu AKS.

Następne kroki

Aby uzyskać informacje dotyczące skojarzonych najlepszych praktyk, zobacz Najlepsze praktyki dotyczące zabezpieczeń i uaktualnień klastra w usłudze AKS oraz Najlepsze praktyki dotyczące zabezpieczeń zasobników w usłudze AKS.