Udostępnij przez

Zabezpieczanie dostępu kontenera do zasobów dla obciążeń usługi Azure Kubernetes Service (AKS) przy użyciu wbudowanych funkcji zabezpieczeń systemu Linux

Z tego artykułu dowiesz się, jak zabezpieczyć dostęp kontenerów do zasobów dla obciążeń w usłudze Azure Kubernetes Service (AKS) przy użyciu przestrzeni nazw użytkowników, AppArmor i seccomp – wbudowanych funkcji zabezpieczeń systemu Linux.

Omówienie zabezpieczeń dostępu do kontenerów

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żytkownikó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. Te funkcje pomagają ograniczyć akcje, które kontenery mogą wykonywać, definiując funkcje zabezpieczeń systemu Linux na poziomie węzła i implementując je za pośrednictwem manifestu zasobnika.

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

Uwaga

Obecnie środowiska Kubernetes nie są bezpieczne w przypadku wrogiego użycia wielodostępu. Inne funkcje zabezpieczeń, takie jak Microsoft Defender for Containers, AppArmor, seccomp, przestrzenie nazw użytkowników, Wstęp do zabezpieczeń zasobnika lub Kubernetes Role-Based Access Control (RBAC) dla węzłów, efektywnie blokują eksploity.

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.

Wymagania wstępne dotyczące przestrzeni nazw użytkowników

Ograniczenia dotyczące przestrzeni nazw użytkowników

Omówienie przestrzeni 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 (user_namespace) 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. Aby dowiedzieć się więcej, zobacz dokumentację przestrzeni nazw użytkowników platformy Kubernetes.

Włącz przestrzenie nazw użytkowników

  1. Utwórz plik o nazwie mypod.yaml i skopiuj go w następującym manifeście. Aby używać przestrzeni nazw użytkownika, kod 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. Exec do pod przy użyciu polecenia kubectl exec.

    kubectl exec -ti userns -- bash

  5. W zasobniku sprawdź /proc/self/uid_map za pomocą następującego polecenia:

    cat /proc/self/uid_map

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

    0  833617920      65536

    Ten wynik wskazuje, że użytkownik root wewnątrz kontenera (UID 0) jest mapowany na użytkownika 65536 na hoście.

Typowe luki w zabezpieczeniach i ekspozycje (CVE) ograniczane przez przestrzenie nazw użytkowników

W poniższej tabeli przedstawiono niektóre typowe luki w zabezpieczeniach i zagrożenia (CVE), które są częściowo lub w pełni ograniczane przy użyciu user_namespaces:

CVE Ocena stopnia powagi Poziom ważności
CVE-2019-5736 8,6 High
CVE 2024-21262 8,6 High
CVE 2022-0492 7,8 High
CVE-2021-25741 8.1 / 8.8 Wysoki/Wysoki
CVE-2017-1002101 9.6 / 8.8 Krytyczne/wysokie

Pamiętaj, że ta lista nie jest wyczerpująca. Aby dowiedzieć się więcej, zobacz Kubernetes v1.33: Przestrzenie nazw użytkowników włączone domyślnie.

Wymagania wstępne appArmor

Uwaga

Platforma Azure Linux 3.0 obsługuje AppArmor od wersji VHD z 7 listopada 2025 r.

Omówienie aplikacji AppArmor

Aby ograniczyć akcje kontenera, możesz użyć modułu zabezpieczeń jądra systemu Linux AppArmor . Aplikacja AppArmor jest dostępna jako część bazowego systemu operacyjnego węzła usługi AKS i jest domyślnie włączona. Można tworzyć 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.

Uwaga

Przed platformą Kubernetes w wersji 1.30 funkcja AppArmor została określona za pomocą adnotacji. Od wersji 1.30 AppArmor jest określana w polu securityContext w specyfikacji podu. Aby uzyskać więcej informacji, zobacz dokumentację platformy Kubernetes AppArmor.

Profile AppArmor używane w klastrze AKS w celu ograniczenia akcji kontenerów

Zabezpieczanie podów za pomocą narzędzia AppArmor

Można określić profile AppArmor na poziomie podu lub kontenera. Profil kontenera AppArmor ma pierwszeństwo przed profilem zasobnika AppArmor. Jeśli żadna z nich nie zostanie określona, kontener zostanie uruchomiony bez ograniczeń. Aby uzyskać więcej informacji na temat profilów AppArmor, zobacz dokumentację Kubernetes o zabezpieczaniu Podów przy użyciu AppArmor.

Konfigurowanie niestandardowego profilu AppArmor

Poniższy przykład tworzy profil, który uniemożliwia zapisywanie plików w kontenerze.

  1. SSH do węzła AKS.

  2. Utwórz plik o nazwie deny-write.profile 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,
}

  3. Załaduj profil AppArmor do węzła.

    # This example assumes that node names match host names, and are reachable via SSH.
NODES=($( kubectl get node -o jsonpath='{.items[*].status.addresses[?(.type == "Hostname")].address}' ))

for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF
#include <tunables/global>

profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>

  file,

  # Deny all file writes.
  deny /** w,
}
EOF'
done

Wdróż zasobnik z niestandardowym profilem AppArmor

  1. Wdróż pod "Hello AppArmor" z profilem deny-write.

    apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor
spec:
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: k8s-apparmor-example-deny-write
  containers:
  - name: hello
    image: busybox:1.28
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

  2. Zastosuj manifest zasobnika przy użyciu kubectl apply polecenia .

    kubectl apply -f hello-apparmor.yaml

  3. Uruchom plik Exec w zasobniku i sprawdź, czy kontener jest uruchomiony z profilem AppArmor.

    kubectl exec hello-apparmor -- cat /proc/1/attr/current

    Dane wyjściowe powinny wyświetlać używany profil AppArmor. Przykład:

    k8s-apparmor-example-deny-write (enforce)

Wymagania wstępne dotyczące seccomp

Zarejestruj flagę KubeletDefaultSeccompProfilePreview funkcji

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:

  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

Ograniczenia seccomp

  • Usługa AKS obsługuje tylko domyślne profile seccomp (RuntimeDefault i Unconfined). Niestandardowe profile seccomp nie są obsługiwane.
  • SeccompDefault nie jest obsługiwanym parametrem dla pul węzłów systemu Windows.

Omówienie domyślnych profilów seccomp (wersja zapoznawcza)

Aplikacja AppArmor działa w przypadku dowolnej aplikacji systemu Linux, natomiast funkcja seccomp (lub bezpieczne przetwarzanie) działa na poziomie procesu. Seccomp jest również modułem zabezpieczeń jądra systemu Linux. Środowisko containerd uruchomieniowe używane przez węzły usługi AKS zapewnia natywną obsługę seccomp. 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.

Domyślne profile seccomp można stosować przy użyciu niestandardowych konfiguracji węzłów podczas tworzenia nowej puli węzłów systemu Linux. Usługa AKS obsługuje wartości RuntimeDefault oraz 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.

Ograniczanie wywołań systemu kontenerów za pomocą polecenia seccomp

  1. Wykonaj kroki, aby zastosować profil seccomp w konfiguracji narzędzia kubelet , określając wartość "seccompDefault": "RuntimeDefault".
  2. Połącz się z hostem.
  3. Sprawdź, czy konfiguracja została zastosowana do węzłów.

Rozwiązywanie problemów z błędami obciążeń za pomocą polecenia seccomp

Po włączeniu SeccompDefault, domyślny profil seccomp środowiska uruchomieniowego kontenera jest używany dla wszystkich obciążeń zaplanowanych na węźle, co może powodować niepowodzenie obciążeń z powodu zablokowanych wywołań systemowych. Jeśli wystąpi awaria obciążenia, mogą wystąpić błędy, takie jak:

  • Obciążenie kończy się nieoczekiwanie po włączeniu funkcji z powodu błędu "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ą te błędy, zalecamy zmianę profilu seccomp na Unconfined. Unconfined nie nakłada żadnych ograniczeń na wywołania systemowe, pozwalając na wykonanie wszystkich wywołań systemowych.

Omówienie niestandardowych profilów seccomp

Dzięki niestandardowemu profilowi seccomp masz bardziej szczegółową kontrolę nad ograniczonymi wywołaniami systemowymi dla kontenerów. Możesz utworzyć własne profile seccomp, wykonując następujące czynności:

  • Używanie filtrów do określania akcji, które mają być dozwolone lub blokowane.
  • Dodawanie adnotacji do skojarzenia z filtrem seccomp w manifeście YAML zasobnika.

Uwaga

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

Konfigurowanie niestandardowego profilu seccomp

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 seccomp.security.alpha.kubernetes.io i odwołuje się do istniejącego filtru prevent-chmod.

    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, używając polecenia kubectl apply

    kubectl apply -f ./aks-seccomp.yaml

  6. Wyświetl stan poda przy użyciu polecenia kubectl get pods.

    kubectl get pods

    W danych wyjściowych powinno być widoczne, że pod zgłasza błąd. Polecenie chmod jest blokowane przez filtr seccomp, jak pokazano w przykładowych danych wyjściowych:

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

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 profilów, zobacz domyślne profile seccomp platformy Docker lub containerd.

Usługa AKS używa domyślnego profilu seccomp dla RuntimeDefaultcontainerd 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 dozwolonych bezpiecznych wywołań systemowych. Po wprowadzeniu zmian na platformie Docker i kontenerze usługa AKS aktualizuje konfigurację domyślną tak, aby odpowiadała. Aktualizacje tej listy mogą spowodować błąd związany z obciążeniem. Aby uzyskać aktualizacje dotyczące wydania, zobacz notatki o wydaniu AKS.

W poniższej tabeli wymieniono znaczące wywołania systemowe, które są skutecznie blokowane, ponieważ nie znajdują się na liście dopuszczonych. Ta lista nie jest wyczerpująca. Jeśli obciążenie wymaga żadnego z zablokowanych poleceń syscall, nie używaj RuntimeDefault profilu seccomp.

Zablokowane wywołanie syscall opis
acct Systemowe wywołanie księgujące, które może pozwolić kontenerom wyłączyć własne limity zasobów lub ewidencję 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_PTRACEelementu , 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 Syscall quota, który może pozwolić kontenerom wyłączyć własne limity zasobów lub ewidencjonowanie 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ż bramowane 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.

Treści powiązane

Aby dowiedzieć się więcej na temat zabezpieczania klastra usługi AKS, znajdziesz następujące artykuły:

  • Last updated on