Freigeben über

Pod Sandboxing mit Azure Kubernetes Service (AKS)

Um Ihre Containerarbeitslasten vor nicht vertrauenswürdigem oder potenziell schädlichem Code zu schützen, enthält AKS jetzt einen Mechanismus namens Pod Sandboxing. Pod Sandboxing bietet eine Isolationsgrenze zwischen der Containeranwendung und den gemeinsam genutzten Kernel- und Computeressourcen des Containerhosts wie CPU, Speicher und Netzwerk. Anwendungen werden in isolierten, leichtgewichtigen virtuellen Pod-Computern (VMs) gestartet. 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

  • Die Azure CLI-Version 2.80.0 oder höher. Führen Sie az --version aus, um die Version Ihrer Azure CLI festzustellen, und az upgrade um ein Upgrade durchzuführen. Weitere Details finden Sie in den Schritten unter Installieren der Azure CLI.

  • AKS unterstützt Pod Sandboxing auf Kubernetes, Version 1.27.0 und höher.

  • 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.

Einschränkungen

Im Folgenden finden Sie Einschränkungen, die für pod Sandboxing gelten:

  • Kata-Container erreichen möglicherweise nicht die IOPS-Leistungsbeschränkungen, die herkömmliche Container auf Azure Files und leistungsstarker lokaler SSD erreichen können.

  • Microsoft Defender for Containers unterstützt die Bewertung von Kata-Runtime-Pods nicht.

  • Der Zugriff auf das Host-Netzwerk von Kata wird nicht unterstützt. Es ist nicht möglich, direkt auf die Hostnetzwerkkonfiguration innerhalb der VM zuzugreifen.

  • Die CPU- und Speicherzuordnung mit Pod Sandboxing hat andere Überlegungen im Vergleich zu runc. Verweisen Sie auf die Abschnitte zur Speicherverwaltung auf der Seite "Überlegungen".

Funktionsweise

Pod Sandboxing auf AKS baut auf dem Open-Source-Kata-Container-Projekt auf. Kata-Container, die auf dem Azure Linux-Containerhost für AKS ausgeführt werden, bieten VM-basierte Isolation und einen separaten Kernel für jeden Pod. Pod Sandboxing ermöglicht Benutzern das Zuweisen von Ressourcen für jeden Pod und teilt sie nicht mit anderen Kata-Containern oder Namespacecontainern, die auf demselben Host ausgeführt werden.

Die Lösungsarchitektur basiert auf den folgenden Hauptkomponenten:

Das Bereitstellen von Pod Sandboxing mithilfe von Kata-Containern ähnelt dem Standardworkflow containerd zum Bereitstellen von Containern. Cluster mit aktivierter Pod-Sandboxing verfügen über eine bestimmte Laufzeitklasse, auf die in einem Pod-Manifest (runtimeClassName: kata-vm-isolation) verwiesen werden kann.

Um dieses Feature mit einem Pod zu verwenden, besteht der einzige Unterschied darin, der Pod-Spezifikation den runtimeClassNamekata-vm-isolation hinzuzufügen. Wenn ein Pod die runtimeClass kata-vm-isolation verwendet, startet der Hypervisor eine leichtgewichtige VM mit eigenem Kernel, damit die Workload darin ausgeführt werden kann.

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 KataVmIsolation an, um das Pod Sandboxing-Feature im Knotenpool zu aktivieren. Mit diesem Parameter sollten diese anderen Parameter die folgenden Anforderungen erfüllen. Andernfalls schlägt der Befehl fehl und meldet ein Problem mit den entsprechenden Parametern.
    • --os-sku: AzureLinux. Nur die Azure Linux os-sku unterstützt dieses Feature.
    • --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 KataVmIsolation \
    --node-vm-size Standard_D4s_v3 \
    --node-count 3 \
    --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:

  • Überprüfen Sie, ob der Cluster Kubernetes, Version 1.27.0 und höher, ausführt.

Verwenden Sie den folgenden Befehl, um pod Sandboxing 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 KataVmIsolation an, um das Pod Sandboxing-Feature 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 entsprechenden Parameter.
      • --os-sku: AzureLinux. Nur die Azure Linux os-sku unterstützt dieses Feature.
      • --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 KataVmIsolation --node-vm-size Standard_D4s_v3

  2. Führen Sie den Befehl az aks update aus, um das Pod-Sandboxing auf dem Cluster zu aktivieren.

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

Bereitstellen Ihrer Anwendungen

Mit Pod-Sandboxing können Sie eine Kombination aus „normalen“ Pods bereitstellen, welche die Kata-Runtime nicht nutzen, und Kata-Pods, welche die Runtime nutzen. Der Hauptunterschied zwischen den beiden bei der Bereitstellung liegt darin, dass ein Kata-Pod die Zeile runtimeClassName: kata-vm-isolation in seiner Spezifikation hat.

Bereitstellen einer Anwendung mit der Kata-Laufzeit

Führen Sie die folgenden Schritte aus, um einen Pod mit der Kata-Runtime auf Ihrem AKS-Cluster bereitzustellen.

  1. Erstellen Sie eine Datei namens kata-app.yaml , um Ihren Kata-Pod zu beschreiben, und fügen Sie dann das folgende Manifest ein.

    kind: Pod
apiVersion: v1
metadata:
  name: isolated-pod
spec:
  runtimeClassName: kata-vm-isolation
  containers:
  - name: kata
    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-vm-isolation.

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

    kubectl apply -f kata-app.yaml

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

    pod/isolated-pod created

(Optional) Überprüfen der Kernelisolationskonfiguration

Wenn Sie den Unterschied zwischen dem Kernel eines Kata- und nicht-Kata-Pods überprüfen möchten, können Sie eine andere Workload einrichten, die nicht über die Kata-Laufzeit verfügt.

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

  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 von Kata-Pod zu.

    kubectl exec -it isolated-pod -- /bin/sh

    Kubectl stellt eine Verbindung zu Ihrem Cluster her, führt /bin/sh im ersten Container innerhalb von isolated-pod aus und leitet die Eingabe- und Ausgabeströme Ihres Terminals an den Prozess des Containers weiter. Sie können auch eine Shell-Sitzung auf dem Container starten, der den Nicht-Kata-Pod hostet, um die Unterschiede zu erkennen.

  2. Nachdem Sie eine Shellsitzung vom Kata-Pod zum Container gestartet haben, können Sie Befehle ausführen, um zu überprüfen, ob der Katacontainer in einer Pod-Sandbox ausgeführt wird. Beachten Sie, dass sie eine andere Kernelversion aufweist als der Nicht-Kata-Container außerhalb der Sandbox.

    Die Kernelversion wird mit dem folgenden Befehl abgerufen:

    uname -r

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

    [user]/# uname -r
6.6.96.mshv1

  3. Starten Sie eine Shellsitzung mit dem Container von normal-pod , um die Kernelausgabe zu überprüfen:

    kubectl exec -it normal-pod -- /bin/bash

    Die Kernelversion wird mit dem folgenden Befehl abgerufen:

    uname -r

    Das folgende Beispiel ähnelt der Ausgabe des virtuellen Computers, der einen normalen Pod ausführt. Dies ist ein anderer Kernel als der Kata-Pod, der innerhalb der Pod-Sandbox ausgeführt wird:

    6.6.100.mshv1-1.azl3

Cleanup

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 auf einem vorhandenen Cluster bereitgestellt haben, können Sie die Pods mit dem Befehl "kubectl delete pod " entfernen.

kubectl get pods
kubectl delete pod <kata-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.
  • Um die Isolation durch Pod Sandboxing weiter zu erforschen und Workloadszenarien zu erkunden, probieren Sie die Pod Sandboxing Labs aus.
  • Last updated on