Sdílet prostřednictvím

Zabezpečení přístupu kontejnerů k prostředkům pro pracovní zátěže Azure Kubernetes Service (AKS) pomocí integrovaných bezpečnostních vlastností v Linuxu

V tomto článku se dozvíte, jak pomocí uživatelských oborů jmen, AppArmor a seccomp vestavěných bezpečnostních funkcí Linuxu zabezpečit přístup kontejnerů k prostředkům pro úlohy v Azure Kubernetes Service (AKS).

Přehled zabezpečení přístupu ke kontejnerům

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. Tyto funkce pomáhají omezit akce, které kontejnery můžou provádět definováním funkcí zabezpečení Linuxu na úrovni uzlu a jejich implementací prostřednictvím manifestu podu.

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

Poznámka:

Prostředí Kubernetes v současné době nejsou bezpečná pro nepřátelské použití s více tenanty. Další funkce zabezpečení, jako je Microsoft Defender for Containers, AppArmor, seccomp, uživatelské obory názvů, Pod Security Admission nebo Kubernetes Role-Based Access Control (RBAC) 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.

Požadavky na uživatelské jmenné obory

  • Existující cluster AKS. Pokud nemáte klastr, vytvořte si ho pomocí Azure CLI, Azure PowerShell nebo portálu Azure.
  • Minimální verze Kubernetes 1.33 pro řídicí rovinu a pracovní uzly. Pokud nepoužíváte Kubernetes verze 1.33 nebo vyšší, musíte upgradovat verzi Kubernetes.
  • Pracovní uzly se systémem Azure Linux 3.0 nebo Ubuntu 24.04 k zajištění splnění minimálních požadavků na stack, abyste mohli povolit obory názvů uživatelů. Pokud potřebujete upgradovat verzi operačního systému (OS), přečtěte si článek o upgradu verze operačního systému.

Omezení uživatelských jmenných prostorů

Přehled uživatelských jmenných prostorů

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ů. Obor názvů uživatele (user_namespace) 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ěkteré klíčové výhody. Další informace najdete v dokumentaci k oborům názvů uživatelů Kubernetes.

Povolit uživatelské obory názvů

  1. Vytvořte soubor s názvem mypod.yaml a zkopírujte ho v následujícím manifestu. Aby bylo možné používat obory názvů uživatelů, musí mít YAML 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. Pomocí příkazu kubectl exec se přihlaste do podu.

    kubectl exec -ti userns -- bash

  5. V podu zkontrolujte /proc/self/uid_map pomocí následujícího příkazu:

    cat /proc/self/uid_map

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

    0  833617920      65536

    Tento výstup označuje, že root uvnitř kontejneru (UID 0) je mapován na uživatele 65536 na hostiteli.

Běžné zranitelnosti a expozice (CVE) zmírněné pomocí uživatelských oborů názvů

Následující tabulka uvádí některé běžné zranitelnosti a vystavení (CVE), která jsou částečně nebo plně zmírněná pomocí user_namespaces:

CVE Skóre závažnosti Úroveň závažnosti
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 Vysoká / Vysoká
CVE-2017-1002101 9.6 / 8.8 Kritické / vysoké

Mějte na paměti, že tento seznam není vyčerpávající. Další informace najdete v tématu Kubernetes verze 1.33: Obory názvů uživatelů jsou ve výchozím nastavení povolené.

Požadavky appArmor

Poznámka:

Azure Linux 3.0 podporuje AppArmor od vydání VHD z 7. listopadu 2025.

Přehled AppArmoru

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 ve výchozím nastavení je povolený. Můžete vytvářet profily AppArmor, které omezují akce čtení, zápisu nebo provádění akcí nebo systémových funkcí, jako je připojení systémů 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:

Před Kubernetes v1.30 byl AppArmor zadán prostřednictvím poznámek. Od verze 1.30 je AppArmor zadaný prostřednictvím securityContext pole ve specifikaci podu. Další informace najdete v dokumentaci k Kubernetes AppArmor.

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

Zabezpečení podů pomocí AppArmoru

Profily AppArmor můžete zadat na úrovni podu nebo kontejneru. Profil AppArmor kontejneru má přednost před profilem AppArmor podu. Pokud není zadáno ani jedno, kontejner se spustí bez omezení. Další informace o profilech AppArmor najdete v dokumentaci k zabezpečení podu s využitím AppArmor Kubernetes.

Konfigurace vlastního profilu AppArmor

Následující příklad vytvoří profil, který brání zápisu do souborů v kontejneru.

  1. Připojení SSH k uzlu AKS

  2. Vytvořte soubor s názvem deny-write.profile 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,
}

  3. Načtěte profil AppArmor do uzlu.

    # 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

Nasazení podu s vlastním profilem AppArmor

  1. Nasadit pod "Hello AppArmor" s profilem odepření zápisu.

    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. Použijte manifest podu kubectl apply pomocí příkazu.

    kubectl apply -f hello-apparmor.yaml

  3. Připojte se do prostředí podu a ověřte, že kontejner běží s profilem AppArmor.

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

    Výstup by měl zobrazit profil AppArmor, který se používá. Například:

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

Požadavky na seccomp

Zaregistruj příznak funkce KubeletDefaultSeccompProfilePreview

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:

  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í seccomp

  • AKS podporuje pouze výchozí profily seccomp (RuntimeDefault a Unconfined). Vlastní profily seccomp nejsou podporovány.
  • SeccompDefault není podporovaný parametr pro fondy uzlů Windows.

Přehled výchozích profilů seccomp (Preview)

I když AppArmor funguje pro libovolnou linuxovou aplikaci, funguje seccomp (nebo secure computing) na úrovni procesu. Seccomp je také modul zabezpečení jádra Linuxu. Modul containerd runtime používaný uzly AKS poskytuje nativní podporu pro seccomp. 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.

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 RuntimeDefault hodnoty a Unconfined hodnoty. Některé úlohy mohou vyžadovat nižší počet omezení syscall než jiné. To znamená, že během běhu s profilem RuntimeDefault můžou selhat. 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í volání systému kontejnerů pomocí seccomp

  1. Postupujte podle kroků pro použití profilu seccomp v konfiguraci kubelet zadáním "seccompDefault": "RuntimeDefault".
  2. Připojte se k hostiteli.
  3. Ověřte, že se na uzly použila konfigurace.

Řešení selhání úloh pomocí seccomp

Pokud je SeccompDefault povoleno, výchozí seccomp profil modulu runtime kontejneru se používá pro všechny úlohy naplánované na uzlu, což může způsobit selhání úloh kvůli blokovaným voláním syscall. Pokud dojde k selhání úlohy, můžou se zobrazit chyby, například:

  • Úloha se po povolení funkce neočekávaně ukončí s chybou "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 těmto chybám, doporučujeme změnit profil seccomp na Unconfined. Unconfined nepřidává žádná omezení na systémová volání, umožňuje provádění všech systémových volání.

Přehled vlastních profilů seccomp

S vlastním profilem seccomp máte podrobnější kontrolu nad omezenými voláními syscall pro vaše kontejnery. Vlastní profily seccomp můžete vytvořit pomocí:

  • Pomocí filtrů můžete určit, jaké akce se mají povolit nebo zamítnout.
  • Přidání poznámek v manifestu YAML podu pro přidružení k filtru seccomp.

Poznámka:

Nápovědu k řešení potíží s vaším profilem seccomp najdete v tématu Řešení potíží s konfigurací seccomp profilu ve službě Azure Kubernetes Service (AKS).

Konfigurace vlastního profilu 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 a odkazuje na existující filtr 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

    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. Nasazení ukázkového podu pomocí příkazu kubectl apply:

    kubectl apply -f ./aks-seccomp.yaml

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

    kubectl get pods

    Ve výstupu byste měli vidět, že pod hlásí chybu. Příkaz chmod není spuštěn filtrem seccomp, jak je znázorněno v příkladu výstupu:

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

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 najdete v dockeru nebo kontejnerových výchozích profilech seccomp.

AKS používá kontejnerový výchozí profil seccomp pro 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 systémových volání. Když v Dockeru a kontejneru provedete 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.

Následující tabulka uvádí významná systémová volání, která jsou účinně blokována, protože nejsou v povoleném seznamu. Tento seznam není vyčerpávající. Pokud vaše úloha vyžaduje některé z blokovaných systémových volání, nepoužívejte RuntimeDefault profil seccomp.

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émové volání kvóty, které by mohlo umožnit kontejnerům vypnout jejich vlastní limity prostředků nebo sledová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 znakem /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. Také řízeno CAP_SYS_ADMIN (kromě 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.

Související obsah

Další informace o zabezpečení clusteru AKS najdete v následujících článcích:

  • Last updated on