Cette page explique comment activer des fonctionnalités facultatives sur Cloud Service Mesh avec un Istiod géré. Pour en savoir plus sur le plan de contrôle interne au cluster, consultez la section Activer des fonctionnalités facultatives sur le plan de contrôle interne au cluster.
Lorsque vous provisionnez Cloud 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 peut vous aider à effectuer la conversion vers la configuration compatible avec le plan de contrôle géré.
Image de proxy Distroless
Si vous avez directement intégré Cloud Service Mesh avec une implémentation de plan de contrôle
TRAFFIC_DIRECTOR
gérée, seul le type d'image "distroless" est accepté. Vous ne pouvez pas le modifier.Si votre parc utilisait initialement l'implémentation du plan de contrôle
ISTIOD
et a été migré vers l'implémentationTRAFFIC_DIRECTOR
, votre type d'image n'a pas été modifié pendant la migration. Vous pouvez alors le modifier pour vous séparer.
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.
Il n'est donc pas possible d'utiliser une interface système (exec
) ni d'utiliser curl
, ping
ou d'autres utilitaires de débogage à l'intérieur du conteneur. Toutefois, vous pouvez utiliser des conteneurs éphémères pour l'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 page Collecter des journaux Cloud Service Mesh.
La configuration suivante active le partage des images pour l'ensemble du maillage de services Cloud Service. 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.
sidecar.istio.io/proxyImageType: debug
Après avoir modifié le type d'image d'un déploiement à l'aide de l'annotation, vous devez redémarrer 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
(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 les services externes 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
surREGISTRY_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
ouasm-managed-rapid
).Vous pouvez apporter les modifications de configuration nécessaires précédemment 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é avecREGISTRY_ONLY
, assurez-vous que les lignes suivantes apparaissent dans la sectionmesh:
.... 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é pour l'authentification des utilisateurs finaux basée sur le 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 dans Cloud 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 savoir comment définir la version TLS minimale et vérifier la configuration TLS de vos charges de travail, consultez Configuration de la version TLS minimale de la charge de travail d'Istio.
L'exemple suivant montre comment 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