Osvědčené postupy pro zabezpečení a upgrady clusterů v Azure Kubernetes Service (AKS)

  • Článek
  • 9 min ke čtení

Při správě clusterů v Azure Kubernetes Service (AKS) je klíčovým aspektem zabezpečení úloh a dat. Když spouštíte clustery s více tenanty pomocí logické izolace, potřebujete zabezpečit zejména přístup k prostředkům a úlohám. Minimalizujte riziko útoku použitím nejnovějších aktualizací zabezpečení operačního systému Kubernetes a uzlu.

Tento článek se zaměřuje na zabezpečení clusteru AKS. Získáte informace o těchto tématech:

  • K zabezpečení přístupu k serveru API použijte řízení přístupu na základě role v Azure Active Directory a Kubernetes (Kubernetes RBAC).
  • Zabezpečený přístup ke kontejneru k prostředkům uzlu.
  • Upgradujte cluster AKS na nejnovější verzi Kubernetes.
  • Udržujte uzly aktuální a automaticky použijte opravy zabezpečení.

Můžete si také přečíst osvědčené postupy pro správu imagí kontejnerů a zabezpečení podů.

Povolení ochrany před hrozbami

Osvědčené postupy

Pokud chcete lépe zabezpečit kontejnery, můžete povolit Defender pro kontejnery . Defender pro kontejnery může vyhodnotit konfigurace clusteru a poskytovat doporučení k zabezpečení, spouštět kontroly ohrožení zabezpečení a poskytovat ochranu a upozorňování pro uzly a clustery Kubernetes v reálném čase.

Zabezpečený přístup k serveru rozhraní API a uzlům clusteru

Osvědčené postupy

Jedním z nejdůležitějších způsobů zabezpečení clusteru je zabezpečený přístup k serveru rozhraní API Kubernetes. Pokud chcete řídit přístup k serveru rozhraní API, integrujte Kubernetes RBAC s Azure Active Directory (Azure AD). Pomocí těchto ovládacích prvků zabezpečujete AKS stejným způsobem jako přístup k předplatným Azure.

Server rozhraní API Kubernetes poskytuje jeden bod připojení pro požadavky na provádění akcí v rámci clusteru. Pokud chcete zabezpečit a auditovat přístup k serveru rozhraní API, omezte přístup a poskytněte nejnižší možné úrovně oprávnění. i když tento přístup není jedinečný pro Kubernetes, je obzvláště důležitý, když jste logicky izolovali cluster AKS pro použití s více tenanty.

Azure AD poskytuje podnikové řešení pro správu identit, které se integruje s clustery AKS. Vzhledem k tomu, že Kubernetes neposkytuje řešení pro správu identit, může se stát, že budete muset důkladně omezit přístup k serveru rozhraní API. S clustery integrovanými Azure AD v AKS můžete k ověřování uživatelů na serveru rozhraní API použít stávající uživatelské a skupinové účty.

Integrace Azure Active Directory pro clustery AKS

Pomocí řízení přístupu na základě role Kubernetes a Azure AD integrace můžete zabezpečit server rozhraní API a poskytnout minimální oprávnění požadovaná sadě prostředků s vymezeným oborem, jako je jeden obor názvů. Různým Azure AD uživatelům nebo skupinám můžete udělit různé role Kubernetes. S podrobnými oprávněními můžete omezit přístup k serveru rozhraní API a poskytnout jasný záznam pro audit provedených akcí.

Doporučeným osvědčeným postupem je místo jednotlivých identit používat k poskytování přístupu k souborům a složkám skupiny . Můžete například použít Azure AD členství ve skupině k vytvoření vazby uživatelů k rolím Kubernetes místo k jednotlivým uživatelům. Při změně členství uživatele ve skupině se odpovídajícím způsobem mění přístupová oprávnění ke clusteru AKS.

Mezitím řekněme, že svážete jednotlivého uživatele přímo s rolí a změní se jeho pracovní funkce. Zatímco se Azure AD členství ve skupinách aktualizuje, jejich oprávnění v clusteru AKS ne. V tomto scénáři uživatel skončí s více oprávněními, než vyžaduje.

Další informace o integraci Azure AD, řízení přístupu na základě role Kubernetes a Azure RBAC najdete v tématu Osvědčené postupy pro ověřování a autorizaci v AKS.

Omezení přístupu k rozhraní API pro metadata instancí

Osvědčené postupy

Do všech oborů názvů uživatelů přidejte zásady sítě, které zablokují výchozí přenos dat podů do koncového bodu metadat.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-instance-metadata
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.10.0.0/0#example
        except:
        - 169.254.169.254/32

Poznámka

Alternativně můžete použít identitu podu , i když je ve verzi Public Preview. Má pod (NMI), který běží jako DaemonSet na každém uzlu v clusteru AKS. NMI zachytává požadavky na tokeny zabezpečení na službu Azure Instance Metadata Service na každém uzlu, přesměruje je na sebe a ověří, jestli má pod přístup k identitě, pro které žádá token, a načte token z tenanta Azure AD jménem aplikace.

Zabezpečení přístupu ke kontejnerům k prostředkům

Osvědčené postupy

Omezte přístup k akcím, které můžou kontejnery provádět. Poskytněte nejmenší počet oprávnění a vyhněte se použití přístupu uživatele root nebo privilegované eskalace.

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 přístup uživatele root.

Můžete například nastavit allowPrivilegeEscalation: false v manifestu podu. Tyto předdefinované kontexty zabezpečení podů Kubernetes umožňují definovat další oprávnění, například uživatele nebo skupinu, se kterou se má spustit, nebo možnosti Linuxu, které se mají zveřejnit. Další osvědčené postupy najdete v tématu Zabezpečení přístupu podů k prostředkům.

Pro ještě podrobnější kontrolu nad akcemi kontejneru můžete použít také integrované linuxové funkce zabezpečení, 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

Prostředí Kubernetes nejsou v současné době zcela bezpečná pro nepřátelské použití více tenantů. Zneužití efektivně blokují i další funkce zabezpečení, jako Microsoft Defender pro ContainersAppArmor, seccomp, Pod Security Admission nebo Kubernetes RBAC pro uzly.

Pro zajištění skutečného zabezpečení při spouštění nepřátelských úloh s více tenanty důvěřujte pouze hypervisoru. Doménou zabezpečení pro Kubernetes se stane celý cluster, nikoli jednotlivý uzel.

Pro tyto typy nehostinných úloh s více tenanty byste měli použít fyzicky izolované clustery.

App Armor

K omezení akcí kontejneru můžete použít modul zabezpečení jádra AppArmor Linuxu. 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ý. Vytvoříte profily AppArmor, které omezují akce čtení, zápisu nebo spuštění nebo systémové funkce, jako je připojení systémů souborů. Výchozí profily AppArmor omezují přístup k různým /proc umístěním a /sys poskytují prostředky k logické izolaci kontejnerů od základního uzlu. AppArmor funguje pro všechny aplikace, které běží v Linuxu, nejen pro pody Kubernetes.

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. 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 je profil správně parsovaný a použitý na AppArmor, nezobrazí se žádný výstup a vrátíte se na příkazový řádek.

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

    • Definuje poznámku pro container.apparmor.security.beta.kubernetes.
    • Odkazuje na profil deny-write 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 nástroji AppArmor najdete v tématu Profily AppArmor v Kubernetes.

Zabezpečené výpočetní prostředí

Zatímco AppArmor funguje pro každou linuxovou aplikaci, seccomp (secure computing) funguje na úrovni procesu. Seccomp je také modul zabezpečení jádra Linuxu a nativně ho podporuje modul runtime Dockeru používaný uzly AKS. Pomocí příkazu seccomp můžete omezit volání procesů kontejneru. Zarovnejte se s osvědčeným postupem udělení minimálního oprávnění ke spuštění kontejneru pouze pro:

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

Pokud chcete vidět seccomp v akci, vytvořte filtr, který brání změně oprávnění k souboru.

  1. 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 následující:

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

  4. Z místního počítače 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 následující:

    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. Stav podů můžete zobrazit pomocí příkazu kubectl get pods .

    • Pod hlásí chybu.
    • Filtr chmod seccomp brání spuštění příkazu, jak je znázorněno v následujícím příkladu výstupu:
    kubectl get pods

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

Další informace o dostupných filtrech najdete v tématu Profily zabezpečení Seccomp pro Docker.

Pravidelné aktualizace na nejnovější verzi Kubernetes

Osvědčené postupy

Pokud chcete mít přehled o nových funkcích a opravách chyb, pravidelně upgradujte verzi Kubernetes v clusteru AKS.

Kubernetes vydává nové funkce rychleji než tradiční platformy infrastruktury. Mezi aktualizace Kubernetes patří:

  • Nové funkce
  • Opravy chyb nebo zabezpečení

Nové funkce obvykle procházejí stavem alfa a beta , než se stanou stabilními. Jakmile jsou stabilní, jsou obecně dostupné a doporučené pro použití v produkčním prostředí. Cyklus vydávání nových funkcí Kubernetes umožňuje aktualizovat Kubernetes, aniž byste museli pravidelně docházet k zásadním změnám nebo upravovat nasazení a šablony.

AKS podporuje tři podverze Kubernetes. Po zavedení nové podverze oprav se nejstarší podverze a podporované verze oprav vyřadí. K menším aktualizacím Kubernetes dochází pravidelně. Pokud chcete zůstat v rámci podpory, ujistěte se, že máte proces zásad správného řízení pro kontrolu potřebných upgradů. Další informace najdete v tématu Podporované verze Kubernetes AKS.

Pokud chcete zkontrolovat verze dostupné pro váš cluster, použijte příkaz az aks get-upgrades , jak je znázorněno v následujícím příkladu:

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

Cluster AKS pak můžete upgradovat pomocí příkazu az aks upgrade . Proces upgradu bezpečně:

  • Cordony a vyprazdňuje po jednom uzlu.
  • Naplánuje pody na zbývajících uzlech.
  • Nasadí nový uzel s nejnovějšími verzemi operačního systému a Kubernetes.

Důležité

Otestujte nové podverze ve vývojovém testovacím prostředí a ověřte, že vaše úlohy zůstávají v pořádku s novou verzí Kubernetes.

Kubernetes může vyřadit rozhraní API (například ve verzi 1.16), na která vaše úlohy spoléhají. Při zavádění nových verzí do produkčního prostředí zvažte použití více fondů uzlů v samostatných verzích a upgradujte jednotlivé fondy postupně, aby se aktualizace postupně přenesla do clusteru. Pokud používáte více clusterů, upgradujte postupně jeden cluster, abyste mohli postupně monitorovat dopad nebo změny.

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION

Další informace o upgradech v AKS najdete v tématech Podporované verze Kubernetes v AKS a Upgrade clusteru AKS.

Zpracování aktualizací linuxových uzlů

Každý večer dostávají linuxové uzly v AKS opravy zabezpečení prostřednictvím kanálu aktualizace distribuce. Toto chování se automaticky nakonfiguruje při nasazení uzlů v clusteru AKS. Aby se minimalizovalo přerušení a potenciální dopad na spuštěné úlohy, uzly se automaticky nerestartují, pokud to vyžaduje oprava zabezpečení nebo aktualizace jádra. Další informace o tom, jak zpracovat restartování uzlů, najdete v tématu Použití aktualizací zabezpečení a jádra u uzlů v AKS.

Upgrady imagí uzlů

Bezobslužné upgrady nainstalují aktualizace operačního systému uzlu Linux, ale image použitá k vytvoření uzlů pro váš cluster zůstane beze změny. Pokud se do clusteru přidá nový linuxový uzel, použije se k jeho vytvoření původní image. Tento nový uzel bude dostávat všechny aktualizace zabezpečení a jádra dostupné během automatické kontroly každou noc, ale zůstane bez opravy, dokud se nedokončí všechny kontroly a restartování. Upgrade image uzlu můžete použít ke kontrole a aktualizaci imagí uzlů používaných vaším clusterem. Další informace o upgradu imagí uzlu najdete v tématu Upgrade bitové kopie uzlu Azure Kubernetes Service (AKS).

Zpracování aktualizací uzlů Windows Serveru

U uzlů s Windows Serverem pravidelně provádíte operaci upgradu image uzlů, abyste mohli bezpečně zprovoznění a vyprázdnění podů a nasazovat aktualizované uzly.