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 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.

Uwaga

Obecnie środowiska Kubernetes nie są całkowicie bezpieczne dla niebezpiecznego użytkowania w środowiskach wielodostępnych. Dodatkowe funkcje zabezpieczeń, takie jak Microsoft Defender for Containers, AppArmor, seccomp, Pod Security Admission lub Kubernetes RBAC dla węzłów, skutecznie blokują luki w zabezpieczeniach.

W celu zapewnienia prawdziwego bezpieczeństwa podczas uruchamiania wrogich obciążeń w środowisku wielodostępnym, należy ufać jedynie hiperwizorowi. Domena zabezpieczeń dla platformy Kubernetes staje się całym klastrem, a nie pojedynczym węzłem.

W przypadku tego rodzaju konfliktowych obciążeń wielodostępnych należy używać klastrów odizolowanych fizycznie.

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.

Ważne

Funkcje usługi AKS w wersji zapoznawczej są dostępne na zasadzie samoobsługi i rejestracji na życzenie. Wersje zapoznawcze są udostępniane w wersji "as is" i "jako dostępne" i są wykluczone z umów dotyczących poziomu usług i ograniczonej gwarancji. Wersje zapoznawcze usługi AKS są częściowo objęte pomocą techniczną dla klientów, świadczoną w miarę możliwości. W związku z tym te funkcje nie są przeznaczone do użytku produkcyjnego. Aby uzyskać więcej informacji, zobacz następujące artykuły pomocy technicznej:

• Zasady wsparcia technicznego AKS
• pomoc techniczna platformy Azure — często zadawane pytania

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.

Zablokowane wywołanie syscall	opis
acct	Wywołanie systemowe związane z księgowością, które może pozwolić kontenerom na wyłączenie własnych limitów zasobów lub ewidencjonowanie procesów. Również ograniczone przez CAP_SYS_PACCT.
add_key	Uniemożliwiaj kontenerom używanie pierścienia klucza jądra, który nie jest przestrzennie nazwiskowany.
bpf	Zabrania ładowania do jądra potencjalnie persistentnych programów bpf, co jest już ograniczone przez CAP_SYS_ADMIN.
clock_adjtime	Informacje na temat czasu/datownika nie są przypisane do żadnej przestrzeni nazw. Również ograniczone przez CAP_SYS_TIME.
clock_settime	Informacje na temat czasu/datownika nie są przypisane do żadnej przestrzeni nazw. Również ograniczone przez CAP_SYS_TIME.
clone	Odmów klonowania nowych przestrzeni nazw. Także ograniczone przez CAP_SYS_ADMIN for CLONE_* flagi, z wyjątkiem CLONE_NEWUSER.
create_module	Odmów dostępu do manipulacji i funkcji modułów jądra. Nieaktualne. Również ograniczone przez CAP_SYS_MODULE.
delete_module	Odmów dostępu do manipulacji i funkcji modułów jądra. Również ograniczone przez CAP_SYS_MODULE.
finit_module	Odmów dostępu do manipulacji i funkcji modułów jądra. Również ograniczone przez CAP_SYS_MODULE.
get_kernel_syms	Odmów pobierania wyeksportowanych symboli jądra i modułu. Nieaktualne.
get_mempolicy	Wywołanie systemowe, które modyfikuje pamięć jądra i ustawienia NUMA. Już ogrodzony przez CAP_SYS_NICE.
init_module	Odmów dostępu do manipulacji i funkcji modułów jądra. Również ograniczone przez CAP_SYS_MODULE.
ioperm	Uniemożliwiaj kontenerom modyfikowanie poziomów uprawnień we/wy jądra. Już ogrodzony przez CAP_SYS_RAWIO.
iopl	Uniemożliwiaj kontenerom modyfikowanie poziomów uprawnień we/wy jądra. Już ogrodzony przez CAP_SYS_RAWIO.
kcmp	Ogranicz możliwości inspekcji procesów, które są już zablokowane przez pominięcie polecenia CAP_SYS_PTRACE.
kexec_file_load	Syscall siostrzanej funkcji kexec_load, która robi to samo, ale z nieco innymi argumentami. Również ograniczone przez CAP_SYS_BOOT.
kexec_load	Odmów ładowania nowego jądra do późniejszego wykonania. Również ograniczone przez CAP_SYS_BOOT.
keyctl	Uniemożliwiaj kontenerom używanie pierścienia klucza jądra, który nie jest przestrzennie nazwiskowany.
lookup_dcookie	Śledzenie/profilowanie wywołania systemowego, które może prowadzić do wycieku informacji na komputerze hostującym. Również ograniczone przez CAP_SYS_ADMIN.
mbind	Wywołanie systemowe, które modyfikuje pamięć jądra i ustawienia NUMA. Już ogrodzony przez CAP_SYS_NICE.
mount	Odmów instalowania, już ogrodzony przez CAP_SYS_ADMIN.
move_pages	Wywołanie systemowe, które modyfikuje pamięć jądra i ustawienia NUMA.
nfsservctl	Odmów interakcji z demonem NFS jądra. Przestarzałe od systemu Linux 3.1.
open_by_handle_at	Przyczyna starego wybuchu kontenera. Również ograniczone przez CAP_DAC_READ_SEARCH.
perf_event_open	Śledzenie/profilowanie wywołania systemowego, które może prowadzić do wycieku informacji na komputerze hostującym.
personality	Uniemożliw włączanie emulacji BSD przez kontener. Nie jest z natury niebezpieczne, ale słabo przetestowane i istnieje potencjał wystąpienia podatności w jądrze systemu operacyjnego.
pivot_root	Odmowa pivot_root powinna być operacją uprzywilejowaną.
process_vm_readv	Ogranicz możliwości inspekcji procesów, które są już zablokowane przez pominięcie polecenia CAP_SYS_PTRACE.
process_vm_writev	Ogranicz możliwości inspekcji procesów, które są już zablokowane przez pominięcie polecenia CAP_SYS_PTRACE.
ptrace	Śledzenie/profilowanie wywołania systemowego. Zablokowane w wersjach jądra systemu Linux przed wersją 4.8, aby uniknąć obejścia seccomp. Śledzenie/profilowanie dowolnych procesów jest już blokowane przez usunięcie CAP_SYS_PTRACE, ponieważ może to spowodować wyciek informacji na hoście.
query_module	Odmów dostępu do manipulacji i funkcji modułów jądra. Nieaktualne.
quotactl	Wywołanie systemowe związane z przydziałem zasobów, które może pozwolić kontenerom na wyłączenie własnych limitów zasobów lub rachunku procesów. Również ograniczone przez CAP_SYS_ADMIN.
reboot	Nie zezwalaj kontenerom na ponowne uruchomienie hosta. Również ograniczone przez CAP_SYS_BOOT.
request_key	Uniemożliwiaj kontenerom używanie pierścienia klucza jądra, który nie jest przestrzennie nazwiskowany.
set_mempolicy	Wywołanie systemowe, które modyfikuje pamięć jądra i ustawienia NUMA. Już ogrodzony przez CAP_SYS_NICE.
setns	Odmów skojarzenia wątku z przestrzenią nazw. Również ograniczone przez CAP_SYS_ADMIN.
settimeofday	Informacje na temat czasu/datownika nie są przypisane do żadnej przestrzeni nazw. Również ograniczone przez CAP_SYS_TIME.
stime	Informacje na temat czasu/datownika nie są przypisane do żadnej przestrzeni nazw. Również ograniczone przez CAP_SYS_TIME.
swapon	Odmów rozpoczęcia/zatrzymania zamiany na plik/urządzenie. Również ograniczone przez CAP_SYS_ADMIN.
swapoff	Odmów rozpoczęcia/zatrzymania zamiany na plik/urządzenie. Również ograniczone przez CAP_SYS_ADMIN.
sysfs	Przestarzały syscall.
_sysctl	Przestarzałe, zastąpione przez /proc/sys.
umount	Powinna być operacją uprzywilejowaną. Również ograniczone przez CAP_SYS_ADMIN.
umount2	Powinna być operacją uprzywilejowaną. Również ograniczone przez CAP_SYS_ADMIN.
unshare	Odmów klonowania nowych przestrzeni nazw dla procesów. Również ograniczone przez CAP_SYS_ADMIN, z wyjątkiem unshare --user.
uselib	Starsze wywołanie systemowe związane z bibliotekami udostępnionymi, nieużywane przez długi czas.
userfaultfd	Obsługa błędów stron w przestrzeni użytkownika, co jest w dużej mierze potrzebne do migracji procesów.
ustat	Przestarzały syscall.
vm86	W maszynie wirtualnej z jądrem w trybie rzeczywistym x86. Również ograniczone przez CAP_SYS_ADMIN.
vm86old	W maszynie wirtualnej z jądrem w trybie rzeczywistym x86. Również ograniczone przez CAP_SYS_ADMIN.

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.