Osvědčené postupy pro zabezpečení a upgrady clusteru ve službě Azure Kubernetes Service (AKS)

  • Článek

Při správě clusterů ve službě 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 zejména zabezpečit 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 pro:

  • K zabezpečení přístupu k serveru API použijte Microsoft Entra ID a Kubernetes řízení přístupu na základě role (Kubernetes RBAC).
  • Zabezpečte přístup ke kontejnerům k prostředkům uzlu.
  • Upgradujte cluster AKS na nejnovější verzi Kubernetes.
  • Udržujte uzly aktuální a automaticky aplikujte 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

Pokyny k osvědčeným postupům

Můžete povolit Defender for Containers , který vám pomůže zabezpečit kontejnery. Defender for Containers může vyhodnotit konfigurace clusteru a poskytovat doporučení 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

Pokyny k osvědčeným postupům

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

Server rozhraní API Kubernetes poskytuje jeden spojovací bod pro žádosti o provedení 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í pro Kubernetes jedinečný, je zvlášť důležité, když jste logicky izolovali cluster AKS pro použití s více tenanty.

Microsoft Entra ID poskytuje řešení pro správu identit připravené pro podniky, které se integruje s clustery AKS. Vzhledem k tomu, že Kubernetes neposkytuje řešení pro správu identit, může být obtížné omezit přístup k serveru rozhraní API. S integrovanými clustery Microsoft Entra v AKS použijete stávající uživatelské a skupinové účty k ověřování uživatelů na serveru rozhraní API.

Microsoft Entra integration for AKS clusters

Pomocí RBAC Kubernetes a integrace ID Microsoft Entra můžete zabezpečit server rozhraní API a poskytnout minimální oprávnění požadovaná pro vymezenou sadu prostředků, jako je jeden obor názvů. Různým uživatelům nebo skupinám Microsoft Entra můžete udělit různé role Kubernetes. Pomocí podrobných oprávnění můžete omezit přístup k serveru rozhraní API a poskytnout jasný záznam auditu provedených akcí.

Doporučeným postupem je použití skupin k poskytování přístupu k souborům a složkám místo jednotlivých identit. Můžete například použít členství ve skupině Microsoft Entra ID k vytvoření vazby uživatelů k rolím Kubernetes, nikoli k jednotlivým uživatelům. Když se členství ve skupině uživatele změní, jejich přístupová oprávnění ke clusteru AKS se odpovídajícím způsobem změní.

Řekněme, že mezitím svážete jednotlivé uživatele přímo s rolí a jejich funkce práce se změní. I když se členství ve skupinách Microsoft Entra aktualizuje, jejich oprávnění v clusteru AKS by nešla. V tomto scénáři uživatel skončí s více oprávněními, než vyžaduje.

Další informace o integraci Microsoft Entra, Kubernetes RBAC 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 metadat instance

Pokyny k osvědčeným postupům

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

Poznámka:

Pokud chcete implementovat zásady sítě, při vytváření clusteru AKS zahrňte atribut --network-policy azure . Pomocí následujícího příkazu vytvořte cluster: az aks create -g myResourceGroup -n myManagedCluster --enable-managed-identity --network-plugin azure --network-policy azure

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

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

Pokyny k osvědčeným postupům

Omezte přístup k akcím, které mohou kontejnery provádět. Zadejte nejmenší počet oprávnění a vyhněte se použití kořenového přístupu nebo privilegovaného 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 kořenový přístup.

Například nastavte allowPrivilegeEscalation: false v manifestu podu. Tyto integrované kontexty zabezpečení podů Kubernetes umožňují definovat další oprávnění, jako je uživatel nebo skupina, která se mají spustit jako, 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 kontejnerů můžete také 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:

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

V případě skutečného zabezpečení při spouštění nehostinných úloh s více tenanty 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 úloh s více tenanty byste měli používat fyzicky izolované clustery.

App Armor

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 umístěním a poskytují způsob, jak logicky izolovat kontejnery od základního uzlu. AppArmor funguje pro všechny aplikace, které běží na Linuxu, nejen pro pody Kubernetes.

AppArmor profiles in use in an AKS cluster to limit container actions

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.

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

I když AppArmor funguje pro libovolnou linuxovou aplikaci, funguje seccomp (secure computing) na úrovni procesu. Seccomp je také modul zabezpečení jádra Linuxu a nativně ho podporuje modul runtime Dockeru, který používají uzly AKS. S funkcí seccomp můžete omezit volání procesů kontejneru. Srovnejte s osvědčeným postupem udělení minimálního oprávnění kontejneru pouze ke spuštění:

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

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

Pokyny k osvědčeným postupům

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 se obvykle pohybují v alfa a beta stavu, než se stanou stabilními. Jakmile je stabilní, jsou obecně dostupné a doporučené pro použití v produkčním prostředí. Nový cyklus vydávání funkcí Kubernetes umožňuje aktualizovat Kubernetes, aniž byste pravidelně narazili na zásadní změny nebo upravili nasazení a šablony.

AKS podporuje tři podverze Kubernetes. Po zavedení nové podverze oprav se vyřadí nejstarší podverze a podporované verze oprav. K dílčí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í, abyste zkontrolovali potřebné upgrady. 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ě:

  • Kabelony a vyprázdní jeden uzel najednou.
  • 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 v vývojovém testovacím prostředí a ověřte, že vaše úloha zůstane v pořádku s novou verzí Kubernetes.

Kubernetes může zastaralá 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 postupně upgradujte jednotlivé fondy, aby se aktualizace postupně v rámci clusteru postupně shrnula. Pokud používáte více clusterů, upgradujte postupně jeden cluster, abyste postupně monitorovali 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ématu Podporované verze Kubernetes v AKS a upgrade clusteru AKS.

Zpracování aktualizací uzlů Linuxu

Každý večer můžou uzly Linuxu v AKS získávat opravy zabezpečení prostřednictvím kanálu aktualizace distribuce. Toto chování se automaticky konfiguruje při nasazení uzlů v clusteru AKS. Kvůli minimalizaci přerušení a potenciálního dopadu na spuštěné úlohy se uzly automaticky nerestartují, pokud to vyžaduje oprava zabezpečení nebo aktualizace jádra. Další informace o tom, jak zpracovávat restartování uzlů, najdete v tématu Použití aktualizací zabezpečení a jádra na uzly v AKS.

Upgrady imagí uzlů

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

Zpracování aktualizací uzlu Windows Serveru

U uzlů Windows Serveru pravidelně provádí operaci upgradu bitové kopie uzlu, která bezpečně vyprázdní pody a nasadí aktualizované uzly.