Pod Sandboxing (Vorschau) mit Azure Kubernetes Service (AKS)
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 Sieaz 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:
Kata-Container erreichen möglicherweise nicht die IOPS-Leistungsgrenzwerte, die herkömmliche Container auf Azure Files und lokalen Hochleistungs-SSD erreichen können.
Microsoft Defender for Containers unterstützt die Bewertung von Kata-Runtime-Pods nicht.
Kata Host-Netzwerk wird nicht unterstützt.
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:
- Der Azure Linux-Containerhost für AKS
- Microsoft Hyper-V Hypervisor
- Azure-optimierter Dom0 Linux-Kernel
- Open-Source Cloud-Hypervisor Virtual Machine Monitor (VMM)
- Integration in das Kata Container Framework
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.
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
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
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:
- Führen Sie die Schritte aus, um das Featureflag KataVMIsolationPreview zu registrieren.
- Stellen Sie sicher, dass der Cluster die Kubernetes Version 1.24.0 oder höher ausführt.
Verwenden Sie den folgenden Befehl, um Pod Sandboxing (Vorschau) zu aktivieren, indem Sie einen Knotenpool zum Hosten erstellen.
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
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.
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"]
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.
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
.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
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.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
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.
Azure Kubernetes Service