Freigeben über

Pod Sandboxing (Vorschau) mit Azure Kubernetes Service (AKS)

  • Artikel

Um Ihre Containerworkloads vor nicht vertrauenswürdigem oder potenziell schädlichem Code zu schützen, bietet AKS jetzt einen Mechanismus namens Pod Sandboxing (Vorschau). Pod Sandboxing bietet eine Isolationsgrenze zwischen der Containeranwendung und den gemeinsam genutzten Kernel- und Computerressourcen des Containerhosts. Zum Beispiel CPU, Speicher und Netzwerke. Pod Sandboxing integriert andere Sicherheitsmaßnahmen oder Datenschutzkontrollen in Ihre Gesamtarchitektur, um Sie bei der Erfüllung gesetzlicher, branchenspezifischer oder unternehmensinterner Konformitätsanforderungen zum Schutz sensibler Daten zu unterstützen.

In diesem Artikel erfahren Sie mehr zu diesem neuen Feature und lernen, es zu implementieren.

Voraussetzungen

  • Azure CLI Version 2.44.1 oder höher. Führen Sie az --version aus, um die Version zu finden, und führen Sie az upgrade aus, um ein Upgrade für die Version durchzuführen. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.

  • Die aks-preview Azure CLI-Erweiterung Version 0.5.123 oder höher.

  • Registrieren Sie die KataVMIsolationPreview-Funktion in Ihrem Azure-Abonnement.

  • AKS unterstützt Pod Sandboxing (Vorschau) ab Version 1.24.0 für alle AKS-Netzwerk-Plug-Ins.

  • Verwenden Sie zum Verwalten eines Kubernetes-Clusters den Kubernetes-Befehlszeilenclient kubectl. kubectl ist in Azure Cloud Shell enthalten. Mit dem Befehl az aks install-cli können Sie kubectl lokal installieren.

Installieren der Azure CLI-Erweiterung „aks-preview“

Wichtig

AKS-Previewfunktionen stehen gemäß dem Self-Service- und Aktivierungsprinzip zur Verfügung. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von Service Level Agreements und der Herstellergarantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

Führen Sie den folgenden Befehl aus, um die Erweiterung „aks-preview“ zu installieren:

az extension add --name aks-preview

Führen Sie den folgenden Befehl aus, um ein Update auf die neueste veröffentlichte Version der Erweiterung durchzuführen:

az extension update --name aks-preview

Registrieren des Featureflag KataVMIsolationPreview

Registrieren Sie das Featureflag KataVMIsolationPreview mithilfe des Befehls KataVMIsolationPreview, wie im folgenden Beispiel gezeigt:

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

Es dauert einige Minuten, bis der Status Registered (Registriert) angezeigt wird. Überprüfen Sie den Registrierungsstatus mithilfe des Befehls az feature show:

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

Wenn der Zustand Registered (Registriert) lautet, aktualisieren Sie die Registrierung des Ressourcenanbieters Microsoft.ContainerService mithilfe des Befehls az provider register:

az provider register --namespace "Microsoft.ContainerService"

Einschränkungen

Im Folgenden sind Einschränkungen für diese Vorschau von Pod Sandboxing (Vorschau) aufgeführt:

Funktionsweise

Kata Containers, das auf dem Azure Linux Containerhost für AKS-Stack ausgeführt wird, bietet eine hardwaregestützte Isolation, um diese Funktionalität in AKS bereitzustellen. Pod Sandboxing erweitert die Vorteile der Hardwareisolation. Es bietet beispielsweise einen separaten Kernel für jeden Kata-Pod. Durch Hardwareisolation werden jedem Pod Ressourcen zugeordnet. Diese werden nicht mit anderen Kata-Containern oder Namespace-Containern, die auf demselben Host ausgeführt werden, geteilt.

Die Lösungsarchitektur basiert auf den folgenden Komponenten:

Die Bereitstellung von Pod Sandboxing mithilfe von Kata-Containern ähnelt dem üblichen Containerd-Workflow zum Bereitstellen von Containern. Die Bereitstellung umfasst Kata Runtime-Optionen, die Sie in der Podvorlage definieren können.

Um dieses Feature mit einem Pod zu verwenden, besteht der einzige Unterschied darin, dass Sie als runtimeClassName kata-mshv-vm-isolation hinzuzufügen müssen.

Wenn ein Pod die runtimeClass kata-mshv-vm-isolation verwendet, wird eine VM erstellt, die als Podsandbox zum Hosten der Container dient. Der Standardarbeitsspeicher der VM beträgt 2 GB, und die Standard-CPU verfügt über einen Kern, wenn das Containerressourcenmanifest (containers[].resources.limits) keinen Grenzwert für CPU und Arbeitsspeicher angibt. Wenn Sie im Containerressourcenmanifest einen Grenzwert für CPU oder Arbeitsspeicher angeben, hat die VM containers[].resources.limits.cpu mit dem Argument 1, um 1 + xCPU zu verwenden, und containers[].resources.limits.memory mit dem Argument 2, um 2 GB + yMemory anzugeben. Container können nur so viele CPU-Kerne und so viel Arbeitsspeicher verwenden, wie die Grenzwerte der Container erlauben. Der Befehl containers[].resources.requests wird in dieser Vorschau ignoriert. Wir konzentrieren uns vordergründig darauf, den CPU- und Arbeitsspeicheraufwand zu reduzieren.

Einen neuen Cluster bereitstellen

Führen Sie die folgenden Schritte aus, um einen Azure Linux AKS-Cluster mithilfe der Azure CLI bereitzustellen.

  1. Erstellen Sie einen AKS-Cluster mit dem Befehl az aks create und geben Sie die folgenden Parameter an:

    • --workload-runtime: Geben Sie KataMshvVmIsolation an, um die Podsandbox-Funktion im Knotenpool zu aktivieren. Zusammen mit diesem Parameter müssen diese weiteren Parameter die folgenden Anforderungen erfüllen. Andernfalls schlägt der Befehl fehl und meldet ein Problem mit dem/den entsprechenden Parameter(n).
    • --os-sku: AzureLinux. Nur die Azure Linux os-sku unterstützt diese Funktion in dieser Vorschauversion.
    • --node-vm-size: Es ist jede Größe einer Azure VM, die eine VM der Generation 2 ist und geschachtelte Virtualisierung unterstützt, möglich. Zum Beispiel Dsv3-VMs.

    Im folgenden Beispiel wird ein Cluster mit dem Namen myAKSCluster mit einem Knoten in myResourceGroup erstellt.

    az aks create 
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --os-sku AzureLinux \
    --workload-runtime KataMshvVmIsolation \
    --node-vm-size Standard_D4s_v3 \
    --node-count 1 \
    --generate-ssh-keys

  2. Führen Sie den folgenden Befehl aus, um Anmeldeinformationen für den Zugriff auf den Kubernetes-Cluster zu erhalten. Verwenden Sie den Befehl az aks get-credentials, und ersetzen Sie die Werte für den Clusternamen und den Ressourcengruppennamen.

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

  3. Der Befehl kubectl get pods gibt eine Liste aller Pods in allen Namespaces zurück.

    kubectl get pods --all-namespaces

Bereitstellung in einem bestehenden Cluster

Um dieses Feature mit einem vorhandenen AKS-Cluster verwenden zu können, müssen die folgenden Anforderungen erfüllt sein:

Verwenden Sie den folgenden Befehl, um Pod Sandboxing (Vorschau) zu aktivieren, indem Sie einen Knotenpool zum Hosten erstellen.

  1. Fügen Sie Ihrem AKS-Cluster mithilfe des Befehls az aks nodepool add einen Knotenpool hinzu. Geben Sie die folgenden Parameter an:

    • --resource-group: Geben Sie den Namen einer vorhandenen Ressourcengruppe ein, in der der AKS-Cluster erstellt werden soll.
    • --cluster-name: Geben Sie einen eindeutigen Namen für den AKS-Cluster ein, z. B. myAKSCluster.
    • --name: Geben Sie einen eindeutigen Namen für den Knotenpool Ihres Clusters ein, z. B. nodepool2.
    • --workload-runtime: Geben Sie KataMshvVmIsolation an, um die Podsandbox-Funktion im Knotenpool zu aktivieren. Zusammen mit dem Parameter --workload-runtime müssen diese anderen Parameter die folgenden Anforderungen erfüllen. Andernfalls schlägt der Befehl fehl und meldet ein Problem mit dem/den entsprechenden Parameter(n).
      • --os-sku: AzureLinux. Nur die Azure Linux os-sku unterstützt diese Funktion in der Vorschauversion.
      • --node-vm-size: Es ist jede Größe einer Azure VM, die eine VM der Generation 2 ist und geschachtelte Virtualisierung unterstützt, möglich. Zum Beispiel Dsv3-VMs.

    Im folgenden Beispiel wird dem Cluster myAKSCluster ein Knotenpool mit einem Knoten in nodepool2 in der Ressourcengruppe myResourceGroup hinzugefügt:

    az aks nodepool add --cluster-name myAKSCluster --resource-group myResourceGroup --name nodepool2 --os-sku AzureLinux --workload-runtime KataMshvVmIsolation --node-vm-size Standard_D4s_v3

  2. Führen Sie den Befehl az aks update aus, um Pod Sandboxing (Vorschau) im Cluster zu aktivieren.

    az aks update --name myAKSCluster --resource-group myResourceGroup

Bereitstellen einer vertrauenswürdigen Anwendung

Führen Sie die folgenden Schritte aus, um die Bereitstellung einer vertrauenswürdigen Anwendung im freigegebenen Kernel im AKS-Cluster zu veranschaulichen.

  1. Erstellen Sie eine Datei namens trusted-app.yaml, um einen vertrauenswürdigen Pod zu beschreiben, und fügen Sie dann das folgende Manifest ein.

    kind: Pod
apiVersion: v1
metadata:
  name: trusted
spec:
  containers:
  - name: trusted
    image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
    command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]

  2. Stellen Sie den Kubernetes-Pod bereit, indem Sie den Befehl kubectl apply ausführen und die Datei trusted-app.yaml angeben:

    kubectl apply -f trusted-app.yaml

    Die Ausgabe des Befehls sieht in etwa wie im folgenden Beispiel aus:

    pod/trusted created

Bereitstellen einer nicht vertrauenswürdigen Anwendung

Führen Sie die folgenden Schritte aus, um die Bereitstellung einer nicht vertrauenswürdigen Anwendung in der Podsandbox im AKS-Cluster zu veranschaulichen.

  1. Erstellen Sie eine Datei namens untrusted-app.yaml, um einen nicht vertrauenswürdigen Pod zu beschreiben, und fügen Sie dann das folgende Manifest ein.

    kind: Pod
apiVersion: v1
metadata:
  name: untrusted
spec:
  runtimeClassName: kata-mshv-vm-isolation
  containers:
  - name: untrusted
    image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
    command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]

    Der Wert für runtimeClassNameSpec ist kata-mhsv-vm-isolation.

  2. Stellen Sie den Kubernetes-Pod bereit, indem Sie den Befehl kubectl apply ausführen und die Datei untrusted-app.yaml angeben:

    kubectl apply -f untrusted-app.yaml

    Die Ausgabe des Befehls sieht in etwa wie im folgenden Beispiel aus:

    pod/untrusted created

Überprüfen der Kernel-Isolationskonfiguration

  1. Um auf einen Container im AKS-Cluster zuzugreifen, starten Sie eine Shellsitzung, indem Sie den Befehl kubectl exec ausführen. In diesem Beispiel greifen Sie auf den Container innerhalb des nicht vertrauenswürdigen Pods zu.

    kubectl exec -it untrusted -- /bin/bash

    Kubectl stellt eine Verbindung mit Ihrem Cluster her, führt den Befehl /bin/sh im ersten Container innerhalb des nicht vertrauenswürdigen Pods aus und leitet die Eingabe- und Ausgabedatenströme Ihres Terminals an den Prozess des Containers weiter. Sie können auch eine Shellsitzung mit dem Container starten, der den vertrauenswürdigen Pod hostet.

  2. Nachdem Sie eine Shellsitzung mit dem Container des nicht vertrauenswürdigen Pods gestartet haben, können Sie Befehle ausführen, um zu überprüfen, ob der nicht vertrauenswürdige Container in einer Podsandbox ausgeführt wird. Sie werden feststellen, dass er eine andere Kernelversion als der vertrauenswürdige Container außerhalb der Sandbox hat.

    Die Kernelversion wird mit dem folgenden Befehl abgerufen:

    uname -r

    Das folgende Beispiel ähnelt der Ausgabe des Podsandbox-Kernels:

    root@untrusted:/# uname -r
5.15.48.1-8.cm2

  3. Starten Sie eine Shellsitzung mit dem Container des vertrauenswürdigen Pods, um die Kernelausgabe zu überprüfen:

    kubectl exec -it trusted -- /bin/bash

    Die Kernelversion wird mit dem folgenden Befehl abgerufen:

    uname -r

    Das folgende Beispiel ähnelt der Ausgabe der VM, auf der der vertrauenswürdige Pod ausgeführt wird. Dabei handelt es sich um einen anderen Kernel als den des nicht vertrauenswürdigen Pods, der in der Pod-Sandbox ausgeführt wird:

    5.15.80.mshv2-hvl1.m2

Bereinigen

Wenn Sie mit der Erkundung dieses Features fertig sind, sollten Sie Ihre unnötigen Ressourcen bereinigen, um Azure-Gebühren zu vermeiden. Wenn Sie im Rahmen Ihrer Erkundung oder Ihres Tests einen neuen Cluster bereitgestellt haben, können Sie den Cluster mithilfe des Befehls az aks delete löschen.

az aks delete --resource-group myResourceGroup --name myAKSCluster

Wenn Sie Pod Sandboxing (Vorschau) für einen vorhandenen Cluster aktiviert haben, können Sie die Pods mithilfe des Befehls kubectl delete pod entfernen.

kubectl delete pod pod-name

Nächste Schritte

Erfahren Sie mehr über Azure Dedicated Hosts für Knoten mit Ihrem AKS-Cluster, um Hardwareisolation und Kontrolle über Wartungsereignisse der Azure-Plattform zu verwenden.