Dans Cloud Service Mesh 1.5 et versions ultérieures, l'authentification TLS mutuelle (auto mTLS) est activée par défaut. L'authentification mTLS permet à un proxy side-car client de détecter automatiquement si le serveur possède un side-car. Le side-car client envoie l'authentification mTLS aux charges de travail avec des side-cars, et envoie du texte brut aux charges de travail sans side-car. Notez toutefois que les services acceptent à la fois le trafic en texte brut et le trafic mTLS. Lorsque vous injectez des proxys side-car dans vos pods, nous vous recommandons également de configurer vos services de manière à n'accepter que le trafic mTLS.
Avec Cloud Service Mesh, vous pouvez appliquer l'authentification mTLS en dehors du code de votre application en définissant un seul fichier YAML. Cloud Service Mesh vous donne la possibilité d'appliquer une règle d'authentification à l'ensemble du maillage de services, à un espace de noms ou à une charge de travail individuelle.
Coûts
Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :
Pour obtenir une estimation des coûts en fonction de votre utilisation prévue, utilisez le simulateur de coût.
Une fois que vous aurez terminé ce tutoriel, évitez de payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.
Avant de commencer
Assurez-vous que la facturation est activée pour votre projet.
Provisionnez Cloud Service Mesh sur un cluster GKE. Il existe différentes méthodes de configuration compatibles :
Clonez le dépôt :
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-samples cd anthos-service-mesh-samples
Déployer une passerelle d'entrée
Définissez le contexte actuel de
kubectl
sur le cluster :gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
Créez un espace de noms pour votre passerelle d'entrée :
kubectl create namespace asm-ingress
Activez l'espace de noms pour l'injection : Les étapes dépendent de votre implémentation du plan de contrôle.
Géré (TD)
Appliquez le libellé d'injection par défaut à l'espace de noms :
kubectl label namespace asm-ingress \ istio.io/rev- istio-injection=enabled --overwrite
Géré (Istiod)
Recommandation : exécutez la commande suivante pour appliquer le libellé d'injection par défaut à l'espace de noms :
kubectl label namespace asm-ingress \ istio.io/rev- istio-injection=enabled --overwrite
Si vous êtes un utilisateur existant avec le plan de contrôle Istiod géré : nous vous recommandons d'utiliser l'injection par défaut, mais l'injection basée sur les révisions est acceptée. Suivez les instructions suivantes :
Exécutez la commande suivante pour localiser les versions disponibles :
kubectl -n istio-system get controlplanerevision
Le résultat ressemble à ce qui suit :
NAME AGE asm-managed-rapid 6d7h
Dans le résultat, la valeur de la colonne
NAME
est le libellé de révision qui correspond à la version disponible pour la version de Cloud Service Mesh.Appliquez le libellé de révision à l'espace de noms.
kubectl label namespace asm-ingress \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Déployez l'exemple de passerelle dans le dépôt
anthos-service-mesh-samples
:kubectl apply -n asm-ingress \ -f docs/shared/asm-ingress-gateway
Résultat attendu :
serviceaccount/asm-ingressgateway configured service/asm-ingressgateway configured deployment.apps/asm-ingressgateway configured gateway.networking.istio.io/asm-ingressgateway configured
Déployez l'exemple d'application Boutique en ligne.
Si ce n'est pas le cas, définissez le contexte actuel de
kubectl
sur le cluster :gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
Créez l'espace de noms pour l'exemple d'application :
kubectl create namespace onlineboutique
Ajoutez un libellé à l'espace de noms
onlineboutique
pour injecter automatiquement les proxys Envoy. Suivez les étapes pour activer l'injection side-car automatique.Déployez l'application exemple, le
VirtualService
pour l'interface et les comptes de service pour les charges de travail. Dans ce tutoriel, vous allez déployer Online Boutique, une application de démonstration de microservices.kubectl apply \ -n onlineboutique \ -f docs/shared/online-boutique/virtual-service.yaml kubectl apply \ -n onlineboutique \ -f docs/shared/online-boutique/service-accounts
Afficher vos services
Affichez les pods dans l'espace de noms
onlineboutique
:kubectl get pods -n onlineboutique
Résultat attendu :
NAME READY STATUS RESTARTS AGE adservice-85598d856b-m84m6 2/2 Running 0 2m7s cartservice-c77f6b866-m67vd 2/2 Running 0 2m8s checkoutservice-654c47f4b6-hqtqr 2/2 Running 0 2m10s currencyservice-59bc889674-jhk8z 2/2 Running 0 2m8s emailservice-5b9fff7cb8-8nqwz 2/2 Running 0 2m10s frontend-77b88cc7cb-mr4rp 2/2 Running 0 2m9s loadgenerator-6958f5bc8b-55q7w 2/2 Running 0 2m8s paymentservice-68dd9755bb-2jmb7 2/2 Running 0 2m9s productcatalogservice-84f95c95ff-c5kl6 2/2 Running 0 114s recommendationservice-64dc9dfbc8-xfs2t 2/2 Running 0 2m9s redis-cart-5b569cd47-cc2qd 2/2 Running 0 2m7s shippingservice-5488d5b6cb-lfhtt 2/2 Running 0 2m7s
Tous les pods de votre application doivent être opérationnels, avec une valeur
2/2
dans la colonneREADY
. Cela indique que les pods ont un proxy side-car Envoy injecté avec succès. Si2/2
ne s'affiche pas au bout de quelques minutes, consultez le guide de dépannage.Obtenez l'adresse IP externe et définissez-la sur une variable :
kubectl get services -n asm-ingress export FRONTEND_IP=$(kubectl --namespace asm-ingress \ get service --output jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}' \ )
Vous obtenez un résultat semblable à celui-ci :
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE asm-ingressgateway LoadBalancer 10.19.247.233 35.239.7.64 80:31380/TCP,443:31390/TCP,31400:31400/TCP 27m
Accédez à l'adresse
EXTERNAL-IP
dans votre navigateur Web. La boutique en ligne devrait s'afficher dans votre navigateur.
Créer un pod TestCurl
Créez un pod TestCurl pour envoyer du trafic en texte brut à des fins de test.
apiVersion: v1
kind: Pod
metadata:
name: testcurl
namespace: default
annotations:
sidecar.istio.io/inject: "false"
spec:
containers:
- name: curl
image: curlimages/curl
command: ["sleep", "600"]
Accéder à l'exemple boutique en ligne
Définissez le contexte actuel de
kubectl
sur le cluster sur lequel vous avez déployé la boutique en ligne :gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
Répertoriez les services dans l'espace de noms
frontend
:kubectl get services -n frontend
Notez que
frontend-external
estLoadBalancer
et qu'il possède une adresse IP externe. L'exemple d'application inclut un service qui est un équilibreur de charge, de sorte qu'il puisse être déployé sur GKE sans Cloud Service Mesh.Accédez à l'application dans votre navigateur à l'aide de l'adresse IP externe du service
frontend-external
:http://FRONTEND_EXTERNAL_IP/
Cloud Service Mesh vous permet de déployer une passerelle d'entrée. Vous pouvez également accéder à la Boutique en ligne en utilisant l'adresse IP externe de la passerelle d'entrée. Obtenez l'adresse IP externe de la passerelle. Remplacez les espaces réservés par les informations suivantes :
- GATEWAY_SERVICE_NAME : nom du service de passerelle d'entrée. Si vous avez déployé l'exemple de passerelle sans modification ou si vous avez déployé la passerelle d'entrée par défaut, le nom est
istio-ingressgateway
. - GATEWAY_NAMESPACE : espace de noms dans lequel vous avez déployé la passerelle d'entrée. Si vous avez déployé la passerelle d'entrée par défaut, l'espace de noms est
istio-system
.
kubectl get service GATEWAY_NAME -n GATEWAY_NAMESPACE
- GATEWAY_SERVICE_NAME : nom du service de passerelle d'entrée. Si vous avez déployé l'exemple de passerelle sans modification ou si vous avez déployé la passerelle d'entrée par défaut, le nom est
Ouvrez un autre onglet dans votre navigateur et accédez à l'application en utilisant l'adresse IP externe de la passerelle d'entrée :
http://INGRESS_GATEWAY_EXTERNAL_IP/
Exécutez la commande suivante pour
curl
le servicefrontend
avec le protocole HTTP brut d'un autre pod. Comme les services se trouvent dans des espaces de noms différents, vous devez boucler le nom DNS du servicefrontend
.kubectl debug --image istio/base --target istio-proxy -it \ $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \ -n product-catalog -- \ curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
Votre requête aboutit avec l'état
200
, car par défaut, le trafic TLS et le trafic en texte brut sont acceptés.
Activer l'authentification TLS mutuelle par espace de noms
Pour appliquer l'authentification mTLS, vous devez appliquer une règle PeerAuthentication
avec kubectl
.
Enregistrez la règle d'authentification suivante sous
mtls-namespace.yaml
.cat <<EOF > mtls-namespace.yaml apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "namespace-policy" spec: mtls: mode: STRICT EOF
La ligne
mode: STRICT
du fichier YAML configure les services de manière à n'accepter que l'authentification mTLS. Par défaut,mode
est défini surPERMISSIVE
, qui configure les services de sorte qu'ils acceptent à la fois le texte brut et l'authentification mTLS.Appliquez la règle d'authentification pour configurer tous les services Boutique en ligne afin qu'ils n'acceptent que l'authentification mTLS :
for ns in ad cart checkout currency email frontend loadgenerator \ payment product-catalog recommendation shipping; do kubectl apply -n $ns -f mtls-namespace.yaml done
Résultat attendu :
peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created peerauthentication.security.istio.io/namespace-policy created
Accédez à l'onglet de votre navigateur qui accède à Boutique en ligne à l'aide de l'adresse IP externe du service
frontend-external
:http://FRONTEND_EXTERNAL_IP/
Actualisez la page. Le navigateur affiche l'erreur suivante :
L'actualisation de la page entraîne l'envoi de texte brut au service
frontend
. En raison de la règle d'authentificationSTRICT
, le proxy side-car bloque la requête auprès du service.Accédez à l'onglet de votre navigateur qui accède à la boutique en ligne en utilisant l'adresse IP externe de
istio-ingressgateway
, puis actualisez la page, qui s'affiche correctement. Lorsque vous accédez à la Boutique en ligne à l'aide de la passerelle d'entrée, la requête prend le chemin suivant :Flux d'authentification mTLS :
- Le navigateur envoie une requête HTTP en texte brut au serveur.
- Le conteneur du proxy de passerelle d'entrée intercepte la requête.
- Le proxy de passerelle d'entrée effectue un handshake TLS avec le proxy côté serveur (le service d'interface dans cet exemple). Ce handshake comprend un échange de certificats. Ces certificats sont pré-chargés dans les conteneurs du proxy par Cloud Service Mesh.
- Le proxy de passerelle d'entrée effectue une vérification de la dénomination sécurisée du certificat du serveur, confirmant ainsi qu'une identité autorisée exécute le serveur.
- Les proxys de passerelle d'entrée et serveurs établissent une connexion TLS mutuelle, et le serveur proxy transfère la requête au conteneur d'applications de serveur (le service de frontend).
Exécutez la commande suivante pour
curl
le servicefrontend
avec le protocole HTTP brut d'un autre pod.kubectl exec testcurl -n default -- curl \ http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
Votre requête échoue, car nous envoyons du trafic en texte brut à partir d'une charge de travail sans side-car où la règle STRICT
peerAuthentication
est appliquée.
Rechercher et supprimer des règles d'authentification
Pour obtenir la liste de toutes les règles
PeerAuthentication
du maillage de services, procédez comme suit :kubectl get peerauthentication --all-namespaces
Le résultat ressemble à ce qui suit :
NAMESPACE NAME MODE AGE ad namespace-policy STRICT 17m cart namespace-policy STRICT 17m checkout namespace-policy STRICT 17m currency namespace-policy STRICT 17m email namespace-policy STRICT 17m frontend namespace-policy STRICT 17m loadgenerator namespace-policy STRICT 17m payment namespace-policy STRICT 17m product-catalog namespace-policy STRICT 17m recommendation namespace-policy STRICT 17m shipping namespace-policy STRICT 17m
Supprimez la règle d'authentification de tous les espaces de noms de Boutique en ligne :
for ns in ad cart checkout currency email frontend loadgenerator payment \ product-catalog recommendation shipping; do kubectl delete peerauthentication -n $ns namespace-policy done;
Résultat attendu :
peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted peerauthentication.security.istio.io "namespace-policy" deleted
Accédez à la boutique en ligne à l'aide de l'adresse IP externe du service
frontend-external
, puis actualisez la page. La page s'affiche comme prévu.Exécutez la commande suivante pour
curl
le servicefrontend
avec le protocole HTTP brut d'un autre pod.kubectl debug --image istio/base --target istio-proxy -it \ $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \ -n product-catalog -- \ curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
Votre requête aboutit avec l'état
200
, car par défaut, le trafic TLS et le trafic en texte brut sont acceptés.
Si vous actualisez la page dans la console Google Cloud qui affiche la liste des Charges de travail, l'état affiché pour mTLS est désormais Permissive
.
Activer l'authentification TLS mutuelle par charge de travail
Pour définir une règle PeerAuthentication
pour une charge de travail spécifique, vous devez configurer la section selector
et spécifier les libellés correspondant à la charge de travail souhaitée.
Toutefois, Cloud Service Mesh ne peut pas agréger les règles au niveau de la charge de travail pour le trafic mTLS sortant vers un service. Vous devez configurer une règle de destination pour gérer ce comportement.
Appliquez une règle d'authentification à une charge de travail spécifique. Notez que la règle suivante utilise des étiquettes et des sélecteurs pour cibler le déploiement
frontend
spécifique.cat <<EOF | kubectl apply -n frontend -f - apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "frontend" namespace: "frontend" spec: selector: matchLabels: app: frontend mtls: mode: STRICT EOF
Résultat attendu :
peerauthentication.security.istio.io/frontend created
Configurez une règle de destination correspondante :
cat <<EOF | kubectl apply -n frontend -f - apiVersion: "networking.istio.io/v1alpha3" kind: "DestinationRule" metadata: name: "frontend" spec: host: "frontend.demo.svc.cluster.local" trafficPolicy: tls: mode: ISTIO_MUTUAL EOF
Résultat attendu :
destinationrule.networking.istio.io/frontend created
Accédez à la boutique en ligne à l'aide de l'adresse IP externe du service
frontend-external
, puis actualisez la page. La page ne s'affiche pas, carfrontend service
est défini surSTRICT
mTLS et le proxy side-car bloque la requête.Exécutez la commande suivante pour
curl
le servicefrontend
avec le protocole HTTP brut d'un autre pod.kubectl exec testcurl -n default -- curl \ http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
Votre requête échoue, car nous envoyons du trafic en texte brut à partir d'une charge de travail sans side-car où la règle STRICT
peerAuthentication
est appliquée.Supprimez la règle d'authentification :
kubectl delete peerauthentication -n frontend frontend
Résultat attendu :
peerauthentication.security.istio.io "frontend" deleted
Supprimez la règle de destination :
kubectl delete destinationrule -n frontend frontend
Résultat attendu :
destinationrule.networking.istio.io "frontend" deleted
Appliquer l'authentification mTLS à l'échelle du maillage
Pour empêcher tous vos services du maillage d'accepter le trafic en texte brut, définissez une règle PeerAuthentication
à l'échelle du maillage avec le mode mTLS défini sur STRICT
.
La règle PeerAuthentication
à l'échelle du maillage ne doit pas comporter de sélecteur et doit être appliquée dans l'espace de noms racine istio-system
. Lorsque vous déployez la règle, le plan de contrôle provisionne automatiquement les certificats TLS afin que les charges de travail puissent s'authentifier mutuellement.
Appliquez l'authentification mTLS à l'échelle du maillage :
kubectl apply -f - <<EOF apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "mesh-wide" namespace: "istio-system" spec: mtls: mode: STRICT EOF
Résultat attendu :
peerauthentication.security.istio.io/mesh-wide created
Accédez à la boutique en ligne à l'aide de l'adresse IP externe du service
frontend-external
, puis actualisez la page. La page ne s'affiche pas.Exécutez la commande suivante pour
curl
le servicefrontend
avec le protocole HTTP brut d'un autre pod.kubectl exec testcurl -n default -- curl \ http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
Votre requête échoue, car nous envoyons du trafic en texte brut à partir d'une charge de travail sans side-car où la règle STRICT
peerAuthentication
est appliquée.Supprimez la stratégie
mesh-wide
:kubectl delete peerauthentication -n istio-system mesh-wide
Résultat attendu :
peerauthentication.security.istio.io "mesh-wide" deleted
Effectuer un nettoyage
Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et les ressources individuelles.
Si vous souhaitez éviter des frais supplémentaires, supprimez le cluster :
gcloud container clusters delete CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
Si vous souhaitez conserver votre cluster et supprimer l'exemple de boutique en ligne, procédez comme suit :
- Supprimez les espaces de noms de l'application :
kubectl delete -f online-boutique/kubernetes-manifests/namespaces
Résultat attendu :
namespace "ad" deleted namespace "cart" deleted namespace "checkout" deleted namespace "currency" deleted namespace "email" deleted namespace "frontend" deleted namespace "loadgenerator" deleted namespace "payment" deleted namespace "product-catalog" deleted namespace "recommendation" deleted namespace "shipping" deleted
- Supprimez les entrées de service :
kubectl delete -f online-boutique/istio-manifests/allow-egress-googleapis.yaml
Résultat attendu :
serviceentry.networking.istio.io "allow-egress-googleapis" deleted serviceentry.networking.istio.io "allow-egress-google-metadata" deleted
Étape suivante
- Pour obtenir un guide général sur la configuration des règles
PeerAuthentication
, consultez la page Configurer la sécurité du transport.