Anthos Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Activer des fonctionnalités facultatives sur le plan de contrôle géré

Cloud Service Mesh géré vous permet d'activer des fonctionnalités de maillage facultatives en personnalisant les ressources ConfigMap de votre cluster. Vous pouvez configurer le renforcement de la sécurité, par exemple les images de proxy sans distribution, restreindre la sortie externe avec des règles de trafic sortant et personnaliser l'échantillonnage des traces, tandis que Google gère la maintenance et les mises à niveau du plan de contrôle.

La disponibilité des fonctionnalités varie selon l'implémentation du plan de contrôle et le canal de publication. Pour en savoir plus, consultez Fonctionnalités compatibles avec les API Istio (plan de contrôle géré) et Activer des fonctionnalités facultatives sur un plan de contrôle au sein du cluster.

Image de proxy Distroless

Clusters directement intégrés (clusters directement intégrés au plan de contrôle TRAFFIC_DIRECTOR géré) : seul le type d'image distroless est accepté. Vous ne pouvez pas le modifier. L'image default n'est pas acceptée.
Clusters migrés (clusters migrés du plan de contrôle ISTIOD vers le plan de contrôle TRAFFIC_DIRECTOR) : le type d'image est défini par défaut sur l'image default (qui contient des binaires de débogage). Vous pouvez activer explicitement les images distroless vous-même pour améliorer la sécurité.

Distroless est le type d'image recommandé pour améliorer la sécurité. Il est recommandé de limiter le contenu d'un environnement d'exécution de conteneur aux packages nécessaires. Cette approche améliore la sécurité et le rapport signal sur bruit des outils d'analyse des failles CVE (Common Vulnerabilities and Exposures). Istio fournit des images de proxy basées sur des images de base distroless.

L'image de proxy distroless ne contient pas de fichiers binaires autres que le proxy. Par conséquent, il n'est pas possible d'exécuter un shell (exec), ni d'utiliser curl, ping ou d'autres utilitaires de débogage dans le conteneur. Toutefois, vous pouvez utiliser des conteneurs éphémères pour vous attacher à un pod de charge de travail en cours d'exécution afin de l'inspecter et d'exécuter des commandes personnalisées. Par exemple, consultez Collecter les journaux Cloud Service Mesh.

La configuration suivante active les images distroless pour l'ensemble de Cloud Service Mesh. Pour modifier un type d'image, vous devez redémarrer tous les pods et les réinjecter pour qu'ils prennent effet.

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: istio-release-channel
       namespace: istio-system
     data:
       mesh: |-
         defaultConfig:
           image:
             imageType: distroless

Vous pouvez remplacer imageType à l'aide de l'annotation de pod suivante. Notez que pour les clusters avec le plan de contrôle TRAFFIC_DIRECTOR géré, seule la valeur de remplacement explicite distroless est acceptée (les types d'images debug ou autres non distroless ne sont pas autorisés).

sidecar.istio.io/proxyImageType: distroless

Une fois que vous avez modifié le type d'image d'un déploiement à l'aide de l'annotation, le déploiement doit être redémarré. Pour revenir à l'image par défaut, supprimez l'annotation sidecar.istio.io/proxyImageType ou le champ imageType de votre MeshConfig, puis redémarrez le déploiement.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Comme il ne nécessite pas d'image de base de débogage, la plupart des types de débogage de proxy doivent utiliser gcloud beta container fleet mesh debug proxy-status / proxy-config (détails).

Règle de trafic sortant

Par défaut, outboundTrafficPolicy est défini sur ALLOW_ANY. Dans ce mode, tout le trafic vers n'importe quel service externe est autorisé. Pour contrôler et limiter le trafic aux seuls services externes pour lesquels des entrées de service sont définies, vous pouvez remplacer le comportement par défaut de ALLOW_ANY par REGISTRY_ONLY.

La configuration suivante configure outboundTrafficPolicy sur REGISTRY_ONLY :

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
data:
  mesh: |-
    outboundTrafficPolicy:
      mode: REGISTRY_ONLY

où release-channel est votre canal de publication (asm-managed, asm-managed-stable ou asm-managed-rapid).

Vous pouvez apporter les modifications de configuration nécessaires dans le configmap à l'aide de la commande suivante :
```
kubectl edit configmap istio-release-channel -n istio-system -o yaml
```

Exécutez la commande suivante pour afficher le ConfigMap :

kubectl get configmap istio-release-channel -n istio-system -o yaml

Pour vérifier que outboundTrafficPolicy est activé avec REGISTRY_ONLY, assurez-vous que les lignes suivantes apparaissent dans la section mesh:.
```
...
apiVersion: v1
data:
  mesh: |
    outboundTrafficPolicy:
     mode: REGISTRY_ONLY
...
```

Authentification de l'utilisateur final

Vous pouvez configurer l'authentification des utilisateurs avec Cloud Service Mesh géré pour l'authentification des utilisateurs finaux via un navigateur et le contrôle des accès à vos charges de travail déployées. Pour en savoir plus, consultez la page Configurer l'authentification des utilisateurs avec Cloud Service Mesh.

Configurer la version minimale de l'authentification TLS pour vos charges de travail

Si vous avez directement intégré Cloud Service Mesh avec une TRAFFIC_DIRECTOR implémentation du plan de contrôle gérée, vous ne pouvez pas modifier ce paramètre.

Vous pouvez utiliser le champ minProtocolVersion pour spécifier la version minimale de TLS pour les connexions TLS entre vos charges de travail. Pour en savoir plus sur la définition de la version minimale de TLS et la vérification de la configuration TLS de vos charges de travail, consultez la page Configuration minimale de la version TLS de la charge de travail Istio.

L'exemple suivant montre un ConfigMap définissant la version TLS minimale pour les charges de travail sur 1.3 :

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
data:
  mesh: |-
    meshMTLS:
      minProtocolVersion: TLSV1_3