Activer les fonctionnalités facultatives sur le plan de contrôle géré
Cette page explique comment activer les fonctionnalités facultatives sur les Cloud Service Mesh. Pour en savoir plus sur le plan de contrôle dans le cluster, consultez Activez les fonctionnalités facultatives sur le plan de contrôle du cluster.
Lorsque vous provisionnez Cloud Service Mesh géré, les fonctionnalités compatibles diffèrent
basée sur l'implémentation du plan de contrôle, et certaines fonctionnalités ne sont
disponibles via la liste d'autorisation. Voir
fonctionnalités compatibles.
Si vous utilisez actuellement une configuration basée sur IstioOperator
,
L'outil Migrate from IstioOperator peut vous aider
convertir 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 un
TRAFFIC_DIRECTOR
géré implémentation du plan de contrôle, alors seul le type d'image "distroless" 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 était migré vers l'implémentation deTRAFFIC_DIRECTOR
, votre type d'image n'a pas été modifié pendant la migration, et vous pouvez modifier le type d'image 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 de exec
un shell ni d'utiliser curl
, ping
ou d'autres
de débogage à l'intérieur du conteneur. Toutefois, vous pouvez utiliser des conteneurs éphémères
à un pod de charge de travail en cours d'exécution pour pouvoir l'inspecter et exécuter des requêtes
commandes. Par exemple, consultez
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, le déploiement doit être redémarré.
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
doit 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,
le trafic vers tout service externe est autorisé. Pour contrôler et restreindre le trafic
uniquement aux services externes pour lesquels
entrées de service
vous pouvez modifier le comportement par défaut de ALLOW_ANY
en
REGISTRY_ONLY
La configuration suivante configure
outboundTrafficPolicy
pourREGISTRY_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 méthode 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 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 pour Cloud Service Mesh géré l'authentification des utilisateurs finaux sur navigateur et le contrôle des accès charges de travail. Pour en savoir plus, consultez Configurer l'authentification des utilisateurs dans 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 un TRAFFIC_DIRECTOR
géré
implémentation du 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 configuration
la version TLS minimale et en vérifiant la
configuration TLS de vos charges de travail,
consultez la page Configuration de la version TLS minimale de la charge de travail d'Istio.
L'exemple suivant montre un paramètre ConfigMap
définissant la version TLS minimale pour
vers la version 1.3:
apiVersion: v1
kind: ConfigMap
metadata:
name: istio-release-channel
namespace: istio-system
data:
mesh: |-
meshMTLS:
minProtocolVersion: TLSV1_3