Sdílet prostřednictvím

Zabezpečení přístupu kontejnerů k prostředkům pomocí integrovaných funkcí zabezpečení Linuxu

V tomto článku se dozvíte, jak zabezpečit přístup kontejnerů k prostředkům pro úlohy Azure Kubernetes Service (AKS).

Důležité

Od 30. listopadu 2025 už AKS nebude podporovat ani poskytovat aktualizace zabezpečení pro Azure Linux 2.0. Od 31. března 2026 se image uzlů odeberou a nebudete moct škálovat fondy uzlů. Migrujte na podporovanou verzi Azure Linuxu buď aktualizací fondů uzlů na podporovanou verzi Kubernetes, nebo migrací na osSku AzureLinux3. Další informace najdete v tématu [Vyřazení z provozu] Uzel poolů Azure Linux 2.0 v AKS.

Přehled

Stejně jako byste uživatelům nebo skupinám měli udělit minimální požadovaná oprávnění, měli byste také omezit kontejnery jenom na nezbytné akce a procesy. Abyste minimalizovali riziko útoku, vyhněte se konfiguraci aplikací a kontejnerů, které vyžadují eskalovaná oprávnění nebo kořenový přístup.

Pomocí integrovaných kontextů zabezpečení podů Kubernetes můžete definovat další oprávnění, jako je uživatel nebo skupina, pod kterými se mají spouštět, linuxové možnosti, které bude k dispozici, nebo nastavení allowPrivilegeEscalation: false v manifestu podu. Další osvědčené postupy najdete v tématu Zabezpečení přístupu podů k prostředkům.

Pokud chcete zlepšit izolaci hostitele a snížit laterální přesun v Linuxu, můžete použít obory názvů uživatelů.

Pro ještě podrobnější kontrolu nad akcemi kontejneru můžete použít integrované funkce zabezpečení Linuxu, jako je AppArmor a seccomp.

  1. Definujte funkce zabezpečení Linuxu na úrovni uzlu.
  2. Implementujte funkce prostřednictvím manifestu podu.

Integrované funkce zabezpečení Linuxu jsou dostupné jenom na linuxových uzlech a podech.

Poznámka:

V současné době nejsou prostředí Kubernetes zcela bezpečná pro nepřátelské použití s více tenanty. Další funkce zabezpečení, jako je Microsoft Defender for Containers, AppArmor, seccomp, obory názvů uživatelů, přístup k podům nebo RBAC Kubernetes pro uzly, efektivně blokují zneužití.

Pro skutečné zabezpečení při spouštění nepřátelských víceklientských úloh důvěřujte pouze hypervisoru. Doména zabezpečení pro Kubernetes se stává celým clusterem, nikoli z jednotlivých uzlů.

U těchto typů nepřátelských víceklientských úloh byste měli používat fyzicky izolované clustery.

Obory názvů uživatelů

Linuxové pody běží ve výchozím nastavení pomocí několika oborů názvů: síťové obory názvů pro izolaci síťové identity a oboru názvů PID za účelem izolace procesů. Uživatelský obor názvů izoluje uživatele uvnitř kontejneru od uživatelů na hostiteli. Omezuje také rozsah funkcí a interakcí podů se zbytkem systému.

Identifikátory UID a IDENTIFIKÁTORy GID uvnitř kontejneru jsou mapovány na neprivilegované uživatele na hostiteli, takže veškerá interakce se zbytkem hostitele probíhá jako neprivilegované UID a GID. Například root uvnitř kontejneru (UID 0) je možné mapovat na uživatele 65536 na hostiteli. Kubernetes vytvoří mapování, které zaručuje, že se nepřekrývá s jinými pody používajícími obory názvů uživatelů v systému.

Implementace Kubernetes má několik klíčových výhod:

  • Zvýšená izolace hostitele: Pokud kontejner uvozuje hranice podů, i když běží jako kořen uvnitř kontejneru, nemá žádná oprávnění k hostiteli. Důvodem je to, že identifikátory UID a IDENTIFIKÁTORy GID kontejneru jsou mapovány na neprivilegované uživatele na hostiteli. Pokud dojde k úniku kontejneru, obory názvů uživatelů výrazně chrání, jaké soubory v hostiteli může kontejner číst a zapisovat, což proces může posílat signály. Udělené možnosti jsou platné pouze v oboru názvů uživatele, a ne v hostiteli.

  • Prevence laterálního pohybu: Vzhledem k tomu, že se identifikátory UID a IDENTIFIKÁTORy GID pro různé kontejnery mapují na různé, nepřekryvné identifikátory UID a IDENTIFIKÁTORy GID na hostiteli mají kontejnery obtížnější čas na sebe navzájem napadnout. Předpokládejme například, že kontejner A běží s různými identifikátory UID a identifikátory GID na hostiteli než kontejner B. V případě přerušení kontejneru můžou operace, které může provádět se soubory a procesy kontejneru B, jsou omezené: jen pro čtení a zápis, co soubor umožňuje ostatním. Ale ani to není možné, protože existuje další prevence nadřazeného adresáře kořenového svazku podu, aby k němu mohl přistupovat pouze pod GID.

  • Respektovat princip nejnižších oprávnění: Vzhledem k tomu, že se identifikátory UID a IDENTIFIKÁTORy GID mapují na neprivilegované uživatele na hostiteli, získají ho jenom uživatelé, kteří potřebují oprávnění k hostiteli (a zakazují obory názvů uživatelů). Bez uživatelských oborů názvů neexistuje žádné oddělení mezi uživateli kontejneru a uživateli hostitele. Nemůžeme se vyhnout udělení oprávnění hostiteli procesům, které ho nepotřebují, když potřebují oprávnění přímo uvnitř kontejneru.

  • Povolení nových případů použití: Obory názvů uživatelů umožňují kontejnerům získat určité možnosti uvnitř vlastního oboru názvů uživatele, aniž by to ovlivnilo hostitele. Možnosti udělené omezené na pod odemykají nové možnosti, například spouštění aplikací, které vyžadují privilegované operace bez udělení úplného kořenového přístupu na hostiteli. Mezi běžné nové případy použití, které je možné bezpečně implementovat, patří: spouštění vnořených kontejnerů a neprivilegovaných sestavení kontejnerů.

  • Neprivilegované nastavení kontejneru: Většina vytváření a nastavení kontejneru se na hostiteli nespustí jako kořen, což výrazně omezuje dopad mnoha prostředí CVE.

Žádná z těchto věcí není pravdivá, pokud se nepoužívají obory názvů uživatelů. Pokud se kontejner spustí jako kořen, pokud se nepoužívají obory názvů uživatelů, proces běží na hostiteli jako kořen, jsou možnosti platné na hostiteli a nastavení kontejneru se provádí jako kořen hostitele.

Než začnete

Než začnete, ujistěte se, že máte následující:

Omezení

Povolení uživatelských oborů názvů

K použití této funkce nejsou potřeba žádné konfigurace. Pokud používáte požadovanou verzi AKS, všechno funguje bez použití.

  1. Vytvořte soubor s názvem mypod.yaml a zkopírujte ho v následujícím manifestu:

    Chcete-li použít uživatelské obory názvů, yaml musí mít pole hostUsers: false.

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

  2. Nasaďte aplikaci pomocí kubectl apply příkazu a zadejte název manifestu YAML.

    kubectl apply -f mypod.yaml

  3. Pomocí příkazu zkontrolujte stav nasazených podů kubectl get pods .

    kubectl get pods

  4. Exec do podu, který zkontrolujete /proc/self/uid_map pomocí kubectl exec příkazu:

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

Výstup by měl mít v posledním sloupci 65536. Například:

0  833617920      65536

Zmírnění cves

Tady jsou některé cve, které jsou zcela nebo částečně zmírněny s uživatelskými obory názvů.

Mějte na paměti, že seznam není vyčerpávající, jedná se pouze o výběr CVE s vysokým skóre, které se zmírňují:

Další informace najdete v tomto blogovém příspěvku s dalšími informacemi o uživatelských oborech názvů.

App Armor (bezpečnostní modul)

Pokud chcete omezit akce kontejneru, můžete použít modul zabezpečení jádra AppArmor Pro Linux. AppArmor je k dispozici jako součást základního operačního systému uzlu AKS a je ve výchozím nastavení povolená. Vytvoříte profily AppArmor, které omezují akce čtení, zápisu nebo provádění akcí nebo systémových funkcí, jako je připojení systému souborů. Výchozí profily AppArmor omezují přístup k různým /proc a /sys místům a poskytují prostředky k logické izolaci kontejnerů od základního uzlu. AppArmor funguje pro všechny aplikace, které běží na Linuxu, nejen pro pody Kubernetes.

Poznámka:

Azure Linux 3.0 nenabízí podporu AppArmor. Pro uzly Azure Linux 3.0 doporučujeme místo AppArmoru využít SELinux k povinnému řízení přístupu.

Profily AppArmor používané v clusteru AKS k omezení akcí kontejneru

Pokud chcete vidět AppArmor v akci, následující příklad vytvoří profil, který brání zápisu do souborů.

  1. Připojení SSH k uzlu AKS

  2. Vytvořte soubor s názvem deny-write.profile.

  3. Zkopírujte a vložte následující obsah:

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

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

Profily AppArmor se přidávají pomocí apparmor_parser příkazu.

  1. Přidejte profil do AppArmoru.

  2. Zadejte název profilu vytvořeného v předchozím kroku:

    sudo apparmor_parser deny-write.profile

    Pokud se profil správně parsuje a použije na AppArmor, nezobrazí se žádný výstup a vrátíte se do příkazového řádku.

  3. Na místním počítači vytvořte manifest podu s názvem aks-apparmor.yaml. Tento manifest:

    • Definuje poznámku pro container.apparmor.security.beta.kubernetes.
    • Odkazuje na profil odepření zápisu vytvořený v předchozích krocích.
    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 nasazení podu spusťte následující příkaz a ověřte, že pod hello-apparmor zobrazuje stav Spuštěno :

    kubectl get pods

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

Další informace o AppArmoru najdete v tématu Profily AppArmor v Kubernetes.

Secure computing (seccomp)

I když AppArmor funguje pro libovolnou linuxovou aplikaci, funguje seccomp (secure computing) na úrovni procesu. Seccomp je také bezpečnostní modul jádra Linuxu a runtime, který používají uzly AKS, ho podporuje nativně. S funkcí seccomp můžete omezit systémová volání kontejneru. Seccomp vytvoří další vrstvu ochrany před běžnými ohroženími zabezpečení volání systému zneužitými škodlivými aktéry a umožňuje určit výchozí profil pro všechny úlohy v uzlu.

Konfigurace výchozího profilu seccomp (Preview)

Při vytváření nového fondu uzlů s Linuxem můžete použít výchozí profily seccomp pomocí vlastních konfigurací uzlů . AKS podporuje dvě hodnoty: RuntimeDefault a Unconfined. Některé úlohy mohou vyžadovat nižší počet omezení syscall než jiné. To znamená, že během běhu mohou selhat s profilem RuntimeDefault. Pokud chcete takové selhání zmírnit, můžete určit Unconfined profil. Pokud vaše úloha vyžaduje vlastní profil, přečtěte si téma Konfigurace vlastního profilu seccomp.

Omezení

  • SeccompDefault není podporovaný parametr pro fondy uzlů Windows.
  • Od 2. 9. 2024 je k dispozici SeccompDefault v API preview.

Důležité

Funkce AKS ve verzi Preview jsou k dispozici na bázi samoobsluhy a dobrovolného přihlášení. Ukázky jsou poskytovány "jak jsou" a "podle aktuální dostupnosti" a jsou vyloučené ze smluv o úrovni služeb a omezené záruky. Předběžné verze AKS jsou částečně pokryty zákaznickou podporou podle možností. Proto tyto funkce nejsou určené pro produkční použití. Další informace najdete v následujících článcích podpory:

Zaregistruj příznak funkce KubeletDefaultSeccompProfilePreview

  1. Příznak funkce KubeletDefaultSeccompProfilePreview zaregistrujte pomocí příkazu az feature register.

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

    Zobrazení stavu Zaregistrované trvá několik minut.

  2. Pomocí příkazu ověřte stav az feature show registrace.

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

  3. Jakmile se stav projeví jako zaregistrovaný, aktualizujte registraci poskytovatele prostředků Microsoft.ContainerService pomocí az provider register příkazu.

    az provider register --namespace Microsoft.ContainerService

Omezení systémových volání kontejneru pomocí funkce seccomp

1. Postupujte podle kroků pro použití profilu seccomp v konfiguraci kubelet zadáním "seccompDefault": "RuntimeDefault".

RuntimeDefault používá výchozí profil seccomp kontejneru, který omezuje určitá systémová volání pro zvýšení zabezpečení. Omezená volání syscallů selžou. Další informace naleznete ve výchozím profilu seccomp pro containerD.

2. Zkontrolujte, zda byla použita konfigurace.

Potvrdíte, že jsou nastavení použita na uzly, tak že se připojíte k hostiteli a ověříte, že došlo ke změnám konfigurace v systému souborů.

3. Řešení potíží se selháními úloh

Pokud je povolená funkce SeccompDefault, výchozí profil seccomp modulu runtime kontejneru se ve výchozím nastavení používá pro všechny úlohy naplánované na uzlu. To může způsobit selhání úloh kvůli blokovaným systémovým voláním. Pokud došlo k selhání úlohy, může se zobrazit například následující chyba:

  • Zatížení se objeví neočekávaně po povolení funkce, se zobrazuje chybová zpráva 'Oprávnění odepřeno'.
  • Chybové zprávy seccomp lze také zobrazit v auditd nebo syslogu tím, že ve výchozím profilu nahradíte SCMP_ACT_ERRNO za SCMP_ACT_LOG.

Pokud dojde k výše uvedeným chybám, doporučujeme změnit profil seccomp na Unconfined. Unconfined neumožní žádné omezení pro syscalls, což umožňuje všechna systémová volání, což snižuje zabezpečení.

Konfigurace vlastního profilu seccomp

S vlastním profilem seccomp můžete mít podrobnější kontrolu nad omezenými systémovými voláními. Podle osvědčených postupů udělte kontejneru minimální oprávnění k provozu:

  • Definování pomocí filtrů, které akce se mají povolit nebo odepřít
  • Přidání poznámek v manifestu YAML podu pro přidružení k filtru seccomp.

Pokud chcete zobrazit sekcomp v akci, vytvořte filtr, který brání změně oprávnění v souboru.

  1. Připojení SSH k uzlu AKS

  2. Vytvořte filtr seccomp s názvem /var/lib/kubelet/seccomp/prevent-chmod.

  3. Zkopírujte a vložte následující obsah:

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

    Ve verzi 1.19 a novější je potřeba nakonfigurovat:

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

  4. Na místním počítači vytvořte manifest podu s názvem aks-seccomp.yaml a vložte následující obsah. Tento manifest:

    • Definuje poznámku pro seccomp.security.alpha.kubernetes.io.
    • Odkazuje na filtr prevent-chmod vytvořený v předchozím 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

    Ve verzi 1.19 a novější je potřeba nakonfigurovat:

    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. Nasaďte ukázkový pod pomocí příkazu kubectl apply :

    kubectl apply -f ./aks-seccomp.yaml

  6. Pomocí příkazu kubectl get pods zobrazte stav podu.

    • Pod hlásí chybu.
    • Příkaz chmod není spuštěn filtrem seccomp, jak je znázorněno v příkladu výstupu:
    kubectl get pods

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

Nápovědu k řešení potíží s vaším profilem seccomp najdete v článku Řešení potíží s konfigurací profilu seccomp ve službě Azure Kubernetes Service.

Možnosti profilu zabezpečení Seccomp

Profily zabezpečení Seccomp jsou sadou definovaných systémových volání, která jsou povolena nebo omezena. Většina runtime kontejnerů má výchozí profil seccomp, který je podobný, ne-li stejný, jako ten, který používá Docker. Další informace o dostupných profilech naleznete v Docker nebo containerD výchozích profilech seccomp.

AKS používá výchozí profil seccomp containerD pro modul RuntimeDefault při konfiguraci seccomp pomocí vlastní konfigurace uzlu.

Významná systémová volání blokována ve výchozím profilu

Docker i containerD udržují seznamy povolených volání bezpečných syscallů. Tato tabulka uvádí významná (ale ne všechna) systémová volání, která jsou účinně blokována, protože nejsou na povoleném seznamu. Pokud vaše úloha vyžaduje některá z blokovaných systémových volání, nepoužívejte RuntimeDefault profil seccomp.

Když se v Dockeru a containerD provede změny, AKS aktualizuje výchozí konfiguraci tak, aby odpovídala. Aktualizace tohoto seznamu můžou způsobit selhání úloh. Informace o aktualizacích verzí najdete v poznámkách k verzi AKS.

Blokovaný syscall Popis
acct Účetnický systém syscall, který by mohl umožnit kontejnerům zakázat vlastní limity prostředků nebo účetnický proces. Také řízeno CAP_SYS_PACCT.
add_key Zabraňte kontejnerům v používání klíčenky jádra, která není oddělena názvovým prostorem.
bpf Zabránit načítání potenciálně trvalých BPF programů do jádra, již omezených CAP_SYS_ADMIN.
clock_adjtime Čas/datum není zapsán v žádném jmenném prostoru. Také řízeno CAP_SYS_TIME.
clock_settime Čas/datum není zapsán v žádném jmenném prostoru. Také řízeno CAP_SYS_TIME.
clone Odepřít klonování nových jmenných prostorů. Také řízeno CAP_SYS_ADMIN for CLONE_* flagy, s výjimkou CLONE_NEWUSER.
create_module Odepřít manipulaci a funkce v modulech jádra. Zastaralý. Také řízeno CAP_SYS_MODULE.
delete_module Odepřít manipulaci a funkce v modulech jádra. Také řízeno CAP_SYS_MODULE.
finit_module Odepřít manipulaci a funkce v modulech jádra. Také řízeno CAP_SYS_MODULE.
get_kernel_syms Odepřít načítání exportovaných symbolů jádra a modulů. Zastaralý.
get_mempolicy Syscall, který upravuje paměť jádra a nastavení NUMA. Již ovládáno CAP_SYS_NICE.
init_module Odepřít manipulaci a funkce v modulech jádra. Také řízeno CAP_SYS_MODULE.
ioperm Zabránit kontejnerům při změně úrovní privilegovaných oprávnění jádra pro vstupně-výstupní operace. Již ovládáno CAP_SYS_RAWIO.
iopl Zabránit kontejnerům při změně úrovní privilegovaných oprávnění jádra pro vstupně-výstupní operace. Již ovládáno CAP_SYS_RAWIO.
kcmp Omezit možnosti kontroly procesů, které jsou již blokovány vyřazením CAP_SYS_PTRACE.
kexec_file_load Sesterský syscall kexec_load, který dělá totéž, ale s mírně odlišnými argumenty. Také řízeno CAP_SYS_BOOT.
kexec_load Zakažte načtení nového jádra pro pozdější spuštění. Také řízeno CAP_SYS_BOOT.
keyctl Zabraňte kontejnerům v používání klíčenky jádra, která není oddělena názvovým prostorem.
lookup_dcookie Trasování/profilování systémových volání, kterým by mohly uniknout informace hostiteli. Také řízeno CAP_SYS_ADMIN.
mbind Syscall, který upravuje paměť jádra a nastavení NUMA. Již ovládáno CAP_SYS_NICE.
mount Zakázat montáž, již je omezeno CAP_SYS_ADMIN.
move_pages Syscall, který upravuje paměť jádra a nastavení NUMA.
nfsservctl Odepřít interakci s démonem NFS jádra operačního systému. Zastaralé od Linuxu 3.1.
open_by_handle_at Příčina úniku ze starého kontejneru Také řízeno CAP_DAC_READ_SEARCH.
perf_event_open Trasování/profilování systémových volání, kterým by mohly uniknout informace hostiteli.
personality Zabránit tomu, aby kontejner povolil emulaci BSD. Není inherentně nebezpečné, ale nedostatečně testované, s potenciálem pro zranitelnosti jádra.
pivot_root Odepření operace pivot_root by mělo být privilegovanou činností.
process_vm_readv Omezit možnosti kontroly procesů, které jsou již blokovány vyřazením CAP_SYS_PTRACE.
process_vm_writev Omezit možnosti kontroly procesů, které jsou již blokovány vyřazením CAP_SYS_PTRACE.
ptrace Trasování/profilace systémového volání. Blokované ve verzích jádra Linuxu před verzí 4.8, aby se zabránilo obejití seccomp. Trasování/profilace libovolných procesů je již blokováno vyřazením CAP_SYS_PTRACE, protože by mohlo dojít k úniku informací na hostiteli.
query_module Odepřít manipulaci a funkce v modulech jádra. Zastaralý.
quotactl Systém syscall kvót, který by mohl umožnit kontejnerům zakázat vlastní limity prostředků nebo účtování procesů. Také řízeno CAP_SYS_ADMIN.
reboot Nenechte kontejnery restartovat hostitele. Také řízeno CAP_SYS_BOOT.
request_key Zabraňte kontejnerům v používání klíčenky jádra, která není oddělena názvovým prostorem.
set_mempolicy Syscall, který upravuje paměť jádra a nastavení NUMA. Již ovládáno CAP_SYS_NICE.
setns Odepřít přidružení vlákna k oboru názvů. Také řízeno CAP_SYS_ADMIN.
settimeofday Čas/datum není zapsán v žádném jmenném prostoru. Také řízeno CAP_SYS_TIME.
stime Čas/datum není zapsán v žádném jmenném prostoru. Také řízeno CAP_SYS_TIME.
swapon Odepřít spuštění/zastavit prohození na soubor nebo zařízení. Také řízeno CAP_SYS_ADMIN.
swapoff Odepřít spuštění/zastavit prohození na soubor nebo zařízení. Také řízeno CAP_SYS_ADMIN.
sysfs Syscall zastaralý.
_sysctl Zastaralé, nahrazeno /proc/sys.
umount Měla by to být privilegovaná operace. Také řízeno CAP_SYS_ADMIN.
umount2 Měla by to být privilegovaná operace. Také řízeno CAP_SYS_ADMIN.
unshare Odepřít klonování nových oborů jmen pro procesy. CAP_SYS_ADMINJe také omezeno, s výjimkou příkazu unshare --user.
uselib Starší syscall související se sdílenými knihovnami, nepoužívaný po dlouhou dobu.
userfaultfd Řešení chyb stránek v uživatelském prostoru, což je z velké části potřeba k migraci procesů.
ustat Syscall zastaralý.
vm86 V jádru x86 v reálném režimu virtuálního počítače. Také řízeno CAP_SYS_ADMIN.
vm86old V jádru x86 v reálném režimu virtuálního počítače. Také řízeno CAP_SYS_ADMIN.

Další kroky

Přidružené osvědčené postupy najdete v tématu Osvědčené postupy pro zabezpečení a upgrady clusteru v AKS a osvědčené postupy pro zabezpečení podů v AKS.

  • Last updated on