Activer Istio CNI pour le module complémentaire de maillage de services basé sur Istio pour Azure Kubernetes Service

Cet article explique comment activer Istio CNI pour le module complémentaire Istio Service Mesh sur Azure Kubernetes Service (AKS). Istio CNI améliore la sécurité en éliminant la nécessité de fonctionnalités réseau privilégiées dans les charges de travail d’application au sein du maillage de service.

Aperçu

Istio redirige le trafic d’application vers le proxy sidecar Envoy à l’aide de l’un des deux mécanismes suivants :

  • Istio CNI (CNIChaining) : un plug-in CNI au niveau du cluster configure la redirection du trafic, de sorte que les pods d’application n’ont pas besoin de fonctionnalités réseau privilégiées. Le conteneur init istio-validation est ajouté lors de l’injection du conteneur sidecar afin de vérifier que la redirection du trafic est correctement configurée.
  • Conteneurs Init (InitContainers) : chaque pod d’application utilise un conteneur init privilégié istio-init qui nécessite NET_ADMIN et NET_RAW des fonctionnalités pour configurer la redirection du trafic. Ces fonctionnalités soulèvent souvent des problèmes de sécurité dans les environnements d’entreprise.

À compter de la révision asm-1-30, Istio CNI est le mécanisme de redirection par défaut pour les nouvelles installations de maillage. Pour les révisions asm-1-25 via asm-1-29, les conteneurs init restent la valeur par défaut et vous devez activer explicitement Istio CNI. Les révisions antérieures ne prennent pas en charge Istio CNI.

Istio CNI offre les avantages suivants sur les conteneurs init :

  • Améliore la sécurité : supprime la nécessité de fonctionnalités réseau privilégiées (NET_ADMIN, NET_RAW) des charges de travail d’application
  • Simplifie les stratégies de sécurité des pods : les pods d’application nécessitent uniquement des fonctionnalités minimales
  • Conserve les fonctionnalités : fournit les mêmes capacités de gestion du trafic que l'approche traditionnelle du conteneur init

Note

Istio CNI n’est pas un remplacement pour Azure CNI et n’interfère pas avec votre réseau AKS normal. Il s’agit d’un plug-in distinct conçu pour gérer la configuration de la redirection du trafic d’Istio au niveau du nœud, ce qui améliore la sécurité en supprimant la nécessité de conteneurs init privilégiés dans les pods d’application.

Avant de commencer

  • Installez le Azure CLI version 2.86.0 ou ultérieure. Vous pouvez exécuter az --version pour vérifier la version. Pour installer ou mettre à niveau Azure CLI, consultez Installer Azure CLI.

  • Vous avez besoin d’un cluster AKS avec le module complémentaire de maillage de services istio activé. Si vous ne disposez pas de cette configuration, consultez le module complémentaire Deploy Istio-based Service Mesh pour Azure Kubernetes Service.

  • Assurez-vous que votre maillage de services Istio utilise une révision asm-1-25 ou ultérieure. Vous pouvez vérifier la révision actuelle avec :

    az aks show --resource-group <resource-group-name> --name <cluster-name> --query 'serviceMeshProfile.istio.revisions'

Définir des variables d’environnement

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

Activer Istio CNI

Activer Istio CNI sur une nouvelle installation de maillage

Pour les révisions asm-1-30 et ultérieures, CNIChaining est le mécanisme de redirection du proxy par défaut pour les nouvelles installations du module complémentaire de maillage de services. Vous n’avez pas besoin de spécifier de paramètres supplémentaires. Pour les révisions asm-1-25 à asm-1-29, activez explicitement Istio CNI en indiquant le paramètre --proxy-redirection-mechanism :

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

Activer Istio CNI sur une installation de maillage existante

Si le module complémentaire Istio Service Mesh est déjà activé, vous pouvez basculer vers Istio CNI à l’aide de la commande suivante :

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

La asm-1-30 valeur par défaut s’applique uniquement aux nouvelles installations, de sorte que la mise à niveau d’un maillage existant ne modifie pas son mécanisme de redirection.

Note

Les pods existants ne basculent pas automatiquement vers le istio-validation conteneur init. Redémarrez vos déploiements après avoir activé Istio CNI afin que les pods récupèrent la modification (par exemple). kubectl rollout restart deployment/<name>

Vérifier que Istio CNI est activé

Utilisez az aks get-credentials pour obtenir les informations d’identification de votre cluster AKS :

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

Après avoir activé Istio CNI, vérifiez l’installation en vérifiant que le DaemonSet CNI est en cours d’exécution :

kubectl get daemonset -n aks-istio-system

Vous devriez voir l’Istio CNI DaemonSet en cours d’exécution :

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

Déployer des charges de travail et vérifier le comportement

Pour vérifier l’amélioration de la sécurité, vous pouvez déployer l’exemple d’application bookinfo et vérifier que les charges de travail utilisent le conteneur init sécurisé istio-validation au lieu du conteneur privilégié istio-init .

Déployer un exemple d’application

D’abord, activez l’injection de sidecar pour l’espace de noms par défaut :

# 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}

Déployez l’exemple d’application bookinfo :

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

Vérifier l’utilisation sécurisée du conteneur init

Vérifiez que les pods déployés utilisent le conteneur init sécurisé istio-validation au lieu de istio-init:

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

La sortie attendue doit s’afficher istio-validation en tant que conteneur init avec des fonctionnalités supprimées :

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"]}

Vous pouvez également vérifier le YAML d’un pod spécifique pour vérifier le contexte de sécurité :

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

La sortie doit indiquer que le istio-validation conteneur init n’a pas de fonctionnalités privilégiées :

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

Désactiver Istio CNI

Pour désactiver Istio CNI et revenir à l’utilisation de conteneurs init traditionnels, utilisez la commande suivante :

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

Après avoir désactivé Istio CNI :

  1. Le DaemonSet CNI sera supprimé :

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

    Sortie attendue (aucun DaemonSet CNI) :

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

  2. Les nouvelles charges de travail utilisent le conteneur d’init traditionnel istio-init avec des fonctionnalités réseau. Redémarrez tous les déploiements existants pour récupérer la modification :

    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

  3. Vérifiez le nom et les fonctionnalités du conteneur init :

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

    La sortie attendue doit s’afficher istio-init avec les fonctionnalités réseau :

    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"]}

Étapes suivantes

  • Last updated on