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

Cette page explique comment activer des fonctionnalités facultatives sur Cloud Service Mesh géré. Pour en savoir plus sur le plan de contrôle intégré au cluster, consultez la page Activer les fonctionnalités facultatives sur le plan de contrôle intégré au cluster.

Lorsque vous provisionnez Cloud Service Mesh géré, les fonctionnalités compatibles varient en fonction de l'implémentation du plan de contrôle, et certaines fonctionnalités ne sont disponibles que via une liste d'autorisation. Pour en savoir plus, consultez la section Fonctionnalités compatibles. Si vous utilisez actuellement une configuration basée sur IstioOperator, le

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 compatible. Vous ne pouvez pas modifier ce paramètre. L'image default n'est pas compatible.

  • 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 fichiers binaires de débogage). Vous pouvez activer explicitement les images distroless 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 connecter à un pod de charge de travail en cours d'exécution afin de pouvoir l'inspecter et exécuter des commandes personnalisées. Par exemple, consultez la section 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é, seul distroless est compatible en tant que valeur de remplacement explicite (debug ou d'autres types d'images non distroless ne sont pas autorisés).

sidecar.istio.io/proxyImageType: distroless

Après avoir 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 elle 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 (pour en savoir plus).

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 modifier le comportement par défaut de ALLOW_ANY en REGISTRY_ONLY.

  1. 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).

  2. Vous pouvez apporter les modifications de configuration nécessaires précédentes dans le configmap à l'aide de la commande suivante :

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

  3. Exécutez la commande suivante pour afficher le configmap :

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

  4. 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 implémentation du TRAFFIC_DIRECTOR plan de contrôle, 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 qui définit la version minimale de TLS 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