Activer des fonctionnalités facultatives sur un service Anthos Service Mesh géré

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

Lorsque vous provisionnez Anthos Service Mesh géré, les fonctionnalités activées par défaut diffèrent selon la plate-forme. Si vous utilisez actuellement une configuration basée sur IstioOperator, l'outil Migrate from IstioOperator (Migrer depuis IstioOperator) peut vous aider à effectuer la conversion vers la configuration compatible avec le plan de contrôle géré.

Journaux d'accès Envoy

Exécutez les commandes suivantes pour activer la journaux d'accès Envoy :

Exécutez la commande suivante pour ajouter accessLogFile: /dev/stdout :

cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
EOF

où release-channel est votre version disponible (asm-managed, asm-managed-stable ou asm-managed-rapid).

Exécutez la commande suivante pour afficher le ConfigMap :

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

Pour vérifier que la journalisation des accès est activée, assurez-vous que la ligne accessLogFile: /dev/stdout apparaît dans la section mesh:.
```
...
apiVersion: v1
data:
  mesh: |
    ....
    accessLogFile: /dev/stdout
...
```

Activer le suivi dans le cloud

Exécutez les commandes suivantes pour activer Cloud Trace :

Exécutez la commande suivante :

cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
  mesh: |-
    defaultConfig:
      tracing:
        stackdriver: {}
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
EOF

où release-channel est votre version disponible (asm-managed, asm-managed-stable ou asm-managed-rapid).

Exécutez la commande suivante pour afficher le ConfigMap :

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

Pour vérifier que Cloud Trace est activé, assurez-vous que les lignes suivantes apparaissent dans la section mesh:.
```
...
apiVersion: v1
data:
  mesh: |
    ....
    defaultConfig:
      tracing:
        stackdriver:{}
...
```
Redémarrez les proxys.

Notez que la configuration du traceur fait actuellement partie de la configuration d'amorçage du proxy. Par conséquent, chaque pod doit redémarrer et être réinjecté pour récupérer la mise à jour du traceur. Par exemple, vous pouvez utiliser la commande suivante pour redémarrer les pods appartenant à un déploiement:
```
kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME
```

Pour en savoir plus sur les en-têtes de trace compatibles, consultez Accéder aux traces.

Image de proxy 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.

La configuration suivante active les images distroless pour Anthos 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

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. Si vous avez besoin d'accéder à ces outils pour des déploiements spécifiques, vous pouvez remplacer 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 via l'annotation, le déploiement doit être redémarré.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Pour la plupart des types de débogage de proxy, istioctl proxy-cmd doit être utilisé, ce qui ne nécessite pas d'image de base de débogage.

Règle de trafic sortant

Par défaut, outboundTrafficPolicy est défini sur ALLOW_ANY. Dans ce mode, tout le trafic vers tout 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 ALLOW_ANY par REGISTRY_ONLY

La configuration suivante définit 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 ci-dessous :
```
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 Anthos Service Mesh gérée pour l'authentification de l'utilisateur final basée sur 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 Anthos Service Mesh.

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

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 TLS minimale et sur la vérification de la configuration TLS de vos charges de travail, consultez la section Configuration de la version TLS minimale des charges de travail d'Istio.

L'exemple suivant montre comment un ConfigMap définit 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