Aktivieren Sie Istio CNI für das Istio-basierte Service-Mesh-Add-on für Azure Kubernetes Service.

In diesem Artikel erfahren Sie, wie Sie Istio CNI für das Istio-basierte Dienstgitter-Add-On auf Azure Kubernetes Service (AKS) aktivieren. Istio CNI verbessert die Sicherheit, indem die Notwendigkeit privilegierter Netzwerkfunktionen in Anwendungsworkloads innerhalb des Dienstgitters eliminiert wird.

Überblick

Istio leitet den Anwendungsdatenverkehr mit einem von zwei Mechanismen an den Envoy-Sidecar-Proxy um:

Istio CNI (CNIChaining): Ein CNI-Plug-In auf Clusterebene konfiguriert die Datenverkehrsumleitung, sodass Anwendungs-Pods keine privilegierten Netzwerkfunktionen benötigen. Der istio-validation-Init-Container wird während der Sidecar-Injektion hinzugefügt, um zu überprüfen, ob die Umleitung des Datenverkehrs richtig konfiguriert ist.
Init-Container (InitContainers): Jeder Anwendungs-Pod verwendet einen privilegierten istio-init Init-Container, der zum Konfigurieren der Umleitung des Datenverkehrs die Berechtigungen NET_ADMIN und NET_RAW erfordert. Diese Funktionen lösen häufig Sicherheitsbedenken in Unternehmensumgebungen aus.

Ab Revision asm-1-30ist Istio CNI der Standardumleitungsmechanismus für neue Gitterinstallationen. Für die Revisionen asm-1-25 bis asm-1-29 sind Init-Container weiterhin die Standardeinstellung, und Sie müssen Istio CNI explizit aktivieren. Frühere Versionen unterstützen Istio CNI nicht.

Istio CNI bietet die folgenden Vorteile gegenüber Init-Containern:

Verbessert die Sicherheit: Entfernt die Notwendigkeit privilegierter Netzwerkfunktionen (NET_ADMIN, NET_RAW) von Anwendungsworkloads.
Vereinfacht Pod-Sicherheitsrichtlinien: Anwendungs pods erfordern nur minimale Funktionen
Erhält die Funktionalität aufrecht: Bietet die gleichen Datenverkehrsverwaltungsfunktionen wie der herkömmliche Init-Containeransatz.

Hinweis

Istio CNI ist kein Ersatz für Azure CNI und beeinträchtigt nicht Ihre normale AKS-Netzwerk. Es handelt sich um ein separates Plugin, das für die Konfiguration der Umleitung des Datenverkehrs von Istio auf Knotenebene entwickelt wurde und die Sicherheit erhöht, indem es privilegierte Init-Container in Anwendungspods überflüssig macht.

Bevor Sie anfangen

Installieren Sie die Azure CLI Version 2.86.0 oder höher. Sie können ausführen az --version , um die Version zu überprüfen. Informationen zum Ausführen einer Installation oder eines Upgrades finden Sie unter Installieren der Azure CLI.
Sie benötigen einen AKS-Cluster mit aktiviertem Istio-basierten Service Mesh Add-On. Wenn Sie nicht über dieses Setup verfügen, lesen Sie "Deploy Istio-based service mesh add-on for Azure Kubernetes Service".
Stellen Sie sicher, dass Ihr Istio-Service-Mesh Revision asm-1-25 oder höher verwendet. Sie können die aktuelle Revision überprüfen mit:
```
az aks show --resource-group <resource-group-name> --name <cluster-name> --query 'serviceMeshProfile.istio.revisions'
```

Festlegen von Umgebungsvariablen

export CLUSTER=<cluster-name>
export RESOURCE_GROUP=<resource-group-name>

Istio CNI aktivieren

Aktivieren von Istio CNI bei einer neuen Gitterinstallation

Für Revisionen ab asm-1-30 ist CNIChaining der standardmäßige Proxy-Umleitungsmechanismus für Neuinstallationen des Service-Mesh-Add-ons. Sie müssen keine zusätzlichen Parameter angeben. Für Revisionen asm-1-25 bis asm-1-29 aktivieren Sie Istio CNI explizit, indem Sie den Parameter --proxy-redirection-mechanism angeben:

az aks mesh enable --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --proxy-redirection-mechanism CNIChaining

Aktivieren von Istio CNI bei einer vorhandenen Gitterinstallation

Wenn Sie das Istio-Dienstgitter-Add-On bereits aktiviert haben, können Sie mit dem folgenden Befehl zu Istio CNI wechseln:

az aks mesh proxy-redirection-mechanism --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --mechanism CNIChaining

Der asm-1-30 Standardwert gilt nur für neue Installationen, sodass das Upgrade eines vorhandenen Gitters den Umleitungsmechanismus nicht ändert.

Hinweis

Vorhandene Pods wechseln nicht automatisch in den Init-Container istio-validation. Starten Sie Ihre Bereitstellungen nach Aktivierung von Istio CNI neu, damit Pods die Änderung übernehmen (z. B. kubectl rollout restart deployment/<name>).

Überprüfen, ob Istio CNI aktiviert ist

Verwenden Sie az aks get-credentials um die Anmeldeinformationen für Ihren AKS-Cluster abzurufen.

az aks get-credentials --resource-group ${RESOURCE_GROUP} --name ${CLUSTER}

Überprüfen Sie nach dem Aktivieren von Istio CNI die Installation, indem Sie überprüfen, ob das CNI DaemonSet ausgeführt wird:

kubectl get daemonset -n aks-istio-system

Sie sollten das Istio CNI DaemonSet ausgeführt sehen:

NAME                                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
azure-service-mesh-istio-cni-addon-node   3         3         3       3            3           kubernetes.io/os=linux   94s

Bereitstellen von Workloads und Überprüfen des Verhaltens

Um die Sicherheitsverbesserung zu überprüfen, können Sie die Bookinfo-Beispielanwendung bereitstellen und überprüfen, ob Workloads den sicheren istio-validation Init-Container anstelle des privilegierten istio-init Containers verwenden.

Bereitstellen der Beispielanwendung

Aktivieren Sie zunächst die Sidecar-Injection für den Standardnamespace:

# Get the current Istio revision
REVISION=$(az aks show --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --query 'serviceMeshProfile.istio.revisions[0]' -o tsv)

# Label the namespace for sidecar injection
kubectl label namespace default istio.io/rev=${REVISION}

Bereitstellen der Bookinfo-Beispielanwendung:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.25/samples/bookinfo/platform/kube/bookinfo.yaml

Überprüfung der Verwendung sicherer Init-Container

Überprüfen Sie, ob die bereitgestellten Pods den sicheren istio-validation Init-Container anstelle von istio-init verwenden.

kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.initContainers[0].name}{"\t"}{.spec.initContainers[0].securityContext.capabilities}{"\n"}{end}'

Die erwartete Ausgabe sollte istio-validation als Init-Container mit verworfenen Berechtigungen anzeigen:

details-v1-799dc5d847-7x9gl     istio-validation        {"drop":["ALL"]}
productpage-v1-99d6d698f-89gpj  istio-validation        {"drop":["ALL"]}
ratings-v1-7545c4bb6c-m7t42     istio-validation        {"drop":["ALL"]}
reviews-v1-8679d76d6c-jz4vg     istio-validation        {"drop":["ALL"]}
reviews-v2-5b9c77895c-b2b7m     istio-validation        {"drop":["ALL"]}
reviews-v3-5b57874f5f-kk9rt     istio-validation        {"drop":["ALL"]}

Sie können auch das YAML eines bestimmten Pods überprüfen, um den Sicherheitskontext zu verifizieren.

kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A 20 -B 25 "name: istio-validation"

Die Ausgabe sollte zeigen, dass der istio-validation Init-Container keine privilegierten Funktionen hat:

initContainers:
  - args:
    …
    name: istio-validation
    …
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      privileged: false
      readOnlyRootFilesystem: true
      runAsGroup: 1337
      runAsNonRoot: true
      runAsUser: 1337

Istio CNI deaktivieren

Um Istio CNI zu deaktivieren und zu herkömmlichen Init-Containern zurückzukehren, verwenden Sie den folgenden Befehl:

az aks mesh proxy-redirection-mechanism --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --mechanism InitContainers

Nach dem Deaktivieren von Istio CNI:

Das CNI DaemonSet wird entfernt:

kubectl get daemonset azure-service-mesh-istio-cni-addon-node -n aks-istio-system

Erwartete Ausgabe (kein CNI DaemonSet):

Error from server (NotFound): daemonsets.apps "azure-service-mesh-istio-cni-addon-node" not found

Neue Workloads verwenden den herkömmlichen istio-init Init-Container mit Netzwerkfunktionen. Starten Sie alle vorhandenen Bereitstellungen neu, um die Änderung zu übernehmen:

kubectl rollout restart deployment/details-v1
kubectl rollout restart deployment/productpage-v1
kubectl rollout restart deployment/ratings-v1
kubectl rollout restart deployment/reviews-v1
kubectl rollout restart deployment/reviews-v2
kubectl rollout restart deployment/reviews-v3

Überprüfen Sie den Namen und die Funktionen des Init-Containers:

kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.initContainers[0].name}{"\t"}{.spec.initContainers[0].securityContext.capabilities}{"\n"}{end}'

Die erwartete Ausgabe sollte istio-init mit Netzwerkfunktionen anzeigen:

details-v1-57bc58c559-722v8     istio-init        {"add":["NET_ADMIN","NET_RAW"],"drop":["ALL"]}
productpage-v1-7bb64f657c-jw6gs istio-init        {"add":["NET_ADMIN","NET_RAW"],"drop":["ALL"]}
ratings-v1-57d5594c75-4zd49     istio-init        {"add":["NET_ADMIN","NET_RAW"],"drop":["ALL"]}
reviews-v1-7fd8f9cd59-mdcf9     istio-init        {"add":["NET_ADMIN","NET_RAW"],"drop":["ALL"]}
reviews-v2-7b8bdc9cdf-k9qgb     istio-init        {"add":["NET_ADMIN","NET_RAW"],"drop":["ALL"]}
reviews-v3-588854d9d7-s2f7j     istio-init        {"add":["NET_ADMIN","NET_RAW"],"drop":["ALL"]}

Nächste Schritte

Feedback

War diese Seite hilfreich?

Last updated on 2026-06-25