Activer des fonctionnalités facultatives sur un 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 diffèrent 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 une configuration basée sur IstioOperator aujourd'hui, l'outil Migrer depuis IstioOperator peut vous aider à convertir la configuration compatible avec le plan de contrôle géré.

Image de proxy Distroless

Si vous avez intégré directement Cloud Service Mesh avec une TRAFFIC_DIRECTOR implémentation de plan de contrôle gérée, seul le type d'image sans distribution est pris en charge. Vous ne pouvez pas le modifier.
Si votre flotte utilisait initialement l'implémentation du plan de contrôle ISTIOD et a été migrée vers l'implémentation TRAFFIC_DIRECTOR, votre type d'image n'a pas été modifié lors de la migration. Vous pouvez modifier vous-même le type d'image en distroless.

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 associer à 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 le imageType à l'aide de l'annotation de pod suivante.

sidecar.istio.io/proxyImageType: debug

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é.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Étant donné qu'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 un 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 version disponible (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 Cloud Service Mesh gérée 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 section 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 intégré directement Cloud Service Mesh avec une implémentation de plan de contrôle TRAFFIC_DIRECTORgé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