Présentation

Objectifs

Dans cet atelier, vous allez apprendre à effectuer les tâches suivantes :

• Appliquer le mode mTLS STRICT sur l'ensemble du maillage de services

• Appliquer le mode mTLS STRICT sur un seul espace de noms

• Explorer les configurations de sécurité dans le tableau de bord Anthos Service Mesh

• Ajouter des règles d'autorisation pour appliquer les accès en fonction d'un jeton Web JSON (JWT)

• Ajouter des règles d'autorisation pour le trafic HTTP dans un maillage Istio

Tâche 1 : Mettre en place l'atelier

Dans cette tâche, vous allez utiliser Qwiklabs pour procéder à l'initialisation de votre atelier.

Accéder à Qwiklabs

Pour chaque atelier, nous vous attribuons un nouveau projet Google Cloud et un nouvel ensemble de ressources pour une durée déterminée, sans frais.

1. Connectez-vous à Qwiklabs dans une fenêtre de navigation privée.

2. Vérifiez le temps imparti pour l'atelier (par exemple : 01:15:00) : vous devez pouvoir le terminer dans ce délai.
   Une fois l'atelier lancé, vous ne pouvez pas le mettre en pause. Si nécessaire, vous pourrez le redémarrer, mais vous devrez tout reprendre depuis le début.

3. Lorsque vous êtes prêt, cliquez sur Démarrer l'atelier.

4. Notez vos identifiants pour l'atelier (Nom d'utilisateur et Mot de passe). Ils vous serviront à vous connecter à Google Cloud Console.

5. Cliquez sur Ouvrir la console Google.

6. Cliquez sur Utiliser un autre compte, puis copiez-collez les identifiants de cet atelier lorsque vous y êtes invité.
   Si vous utilisez d'autres identifiants, des messages d'erreur s'afficheront ou des frais seront appliqués.

7. Acceptez les conditions d'utilisation et ignorez la page concernant les ressources de récupération des données.

Une fois la connexion initiale effectuée, le tableau de bord du projet s'affiche.

Cliquez sur Sélectionner un projet, puis sélectionnez l'ID de votre projet GCP. Cliquez ensuite sur OUVRIR.

Activer Google Cloud Shell

Google Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud.

Google Cloud Shell vous permet d'accéder à vos ressources Google Cloud grâce à une ligne de commande.

1. Dans la barre d'outils située en haut à droite dans la console Cloud, cliquez sur le bouton "Ouvrir Cloud Shell".

   

2. Cliquez sur Continuer.

Le provisionnement et la connexion à l'environnement prennent quelques instants. Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET. Par exemple :

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

• Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

Résultat :

Credentialed accounts: - @.com (active)

Exemple de résultat :

Credentialed accounts: - google1623327_student@qwiklabs.net

• Vous pouvez lister les ID de projet à l'aide de cette commande :

gcloud config list project

Résultat :

[core] project =

Exemple de résultat :

[core] project = qwiklabs-gcp-44776a13dea667a6 Remarque : Pour consulter la documentation complète sur gcloud, accédez au guide de présentation de la gcloud CLI.

Tâche 2 : Vérifier la configuration d'Anthos Service Mesh

L'environnement de cet atelier a déjà été partiellement configuré. Un cluster GKE avec deux nœuds a été provisionné pour vous. Si vous souhaitez examiner le processus de création du cluster, consultez le script de démarrage de setup-vm.

Configurer l'accès au cluster pour kubectl

1. Définissez les variables d'environnement correspondant à la zone et au nom du cluster :

   export CLUSTER_NAME=gke export CLUSTER_ZONE=us-central1-b

2. Dans Cloud Shell, configurez l'accès à la ligne de commande kubectl en exécutant cette commande :

   # get the project id export GCLOUD_PROJECT=$(gcloud config get-value project) # configure kubectl gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $GCLOUD_PROJECT

Vérifier l'installation du cluster et d'Anthos Service Mesh

3. Vérifiez que votre cluster est opérationnel :

   gcloud container clusters list

   Résultat (ne pas copier)

   NAME LOCATION MASTER_VERSION ... STATUS central us-central1-b 1.15.12-gke.2 ... RUNNING

4. Assurez-vous que les services Kubernetes suivants sont déployés : istio-ingressgateway, istiod et promsd :

   kubectl get service -n istio-system

   Résultat (ne pas copier)

   NAME TYPE CLUSTER-IP istio-ingressgateway LoadBalancer 10.7.249.134 istiod ClusterIP 10.7.249.95 promsd ClusterIP 10.7.249.69

5. Assurez-vous que les pods Kubernetes correspondants sont déployés et que tous les conteneurs sont opérationnels : istio-ingressgateway-*, istiod-* et promsd-* :

   kubectl get pods -n istio-system

   Résultat (ne pas copier)

   NAME READY STATUS istio-ingressgateway-845f4d4b6c-hg7gz 1/1 Running ...

Tâche 3 : Déployer les services sleep et httpbin

Dans cette tâche, vous allez créer un ensemble d'espaces de noms pour héberger les services httpbin et sleep. Ces services vous permettront d'explorer l'impact du mode mTLS sur leur trafic. Le service sleep agit en tant que client et appelle le service httpbin, qui agit en tant que serveur.

Configurer l'exemple d'authentification

Vous allez déployer cet exemple de configuration, puis l'utiliser pour explorer les options d'authentification proposées par Istio :

1. Dans Cloud Shell, créez des espaces de noms pour les exemples de clients et de services. Le trafic dans les espaces de noms legacy-* est acheminé en texte brut, tandis que le trafic des espaces de noms mtls-* est acheminé par mTLS :

   kubectl create ns mtls-client kubectl create ns mtls-service kubectl create ns legacy-client kubectl create ns legacy-service kubectl get namespaces

   Résultat (ne pas copier)

   NAME STATUS AGE ... legacy-client Active 5m50s legacy-service Active 5m34s mtls-client Active 5m56s mtls-service Active 5m40s

2. Déployez les anciens services dans les espaces de noms legacy-*. Nous les appelons "anciens", car ils ne font pas partie du maillage :

   #configurations are stored in Github kubectl apply -f \ https://raw.githubusercontent.com/istio/istio/release-1.6/samples/sleep/sleep.yaml \ -n legacy-client kubectl apply -f \ https://raw.githubusercontent.com/istio/istio/release-1.6/samples/httpbin/httpbin.yaml \ -n legacy-service

3. Activez l'injection automatique du proxy side-car Istio sur les espaces de noms mtls-* :

   # get the revision label export DEPLOYMENT=$(kubectl get deployments -n istio-system | grep istiod) export VERSION=asm-$(echo $DEPLOYMENT | cut -d'-' -f 3)-$(echo $DEPLOYMENT \ | cut -d'-' -f 4 | cut -d' ' -f 1) # enable auto-injection on the namespaces kubectl label namespace mtls-client istio-injection- istio.io/rev=${VERSION} --overwrite kubectl label namespace mtls-service istio-injection- istio.io/rev=${VERSION} --overwrite

4. Déployez les services dans les espaces de noms mtls-* :

   kubectl apply -f \ https://raw.githubusercontent.com/istio/istio/release-1.6/samples/sleep/sleep.yaml \ -n mtls-client kubectl apply -f \ https://raw.githubusercontent.com/istio/istio/release-1.6/samples/httpbin/httpbin.yaml \ -n mtls-service

5. Vérifiez que les services sleep et httpbin sont tous deux déployés dans les espaces de noms mtls-service et legacy-service :

   kubectl get services --all-namespaces

   Résultat (ne pas copier)

   NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ... legacy-client sleep ClusterIP 10.7.248.186 <none> 80/TCP 31s legacy-service httpbin ClusterIP 10.7.248.121 <none> 8000/TCP 14s mtls-client sleep ClusterIP 10.7.252.127 <none> 80/TCP 99s mtls-service httpbin ClusterIP 10.7.247.200 <none> 8000/TCP 50s

6. Vérifiez qu'un pod sleep est en cours d'exécution dans les espaces de noms mtls-client et legacy-client, et qu'un pod httpbin est en cours d'exécution dans les espaces de noms mtls-service et legacy-service :

   kubectl get pods --all-namespaces

   Résultat (ne pas copier)

   NAMESPACE NAME READY STATUS RESTARTS AGE ... legacy-client sleep-f8cbf5b76-5v8f9 1/1 Running 0 65s legacy-service httpbin-779c54bf49-5fr9k 1/1 Running 0 47s mtls-client sleep-64d4546bdb-gnpc5 2/2 Running 0 2m13s mtls-service httpbin-5d7bdc9d78-7mfn5 2/2 Running 0 84s

Vérifier que les deux clients sleep peuvent communiquer avec les deux services httpbin

7. Utilisez Cloud Shell pour exécuter cette boucle de commande imbriquée :

   for from in "mtls-client" "legacy-client"; do for to in "mtls-service" "legacy-service"; do kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n" done done

   Résultat (ne pas copier)

   sleep.mtls-client to httpbin.mtls-service: 200 sleep.mtls-client to httpbin.legacy-service: 200 sleep.legacy-client to httpbin.mtls-service: 200 sleep.legacy-client to httpbin.legacy-service: 200

Nous pouvons désormais appliquer des stratégies de sécurité pour cette application.

Tâche 4 : Comprendre l'authentification et activer l'authentification de service à service avec mTLS

Anthos Service Mesh

1. Dans la console, accédez à Navigation > Anthos > Service Mesh.

2. Dans le tableau de bord Anthos Service Mesh, les deux services créés dans les espaces de noms mtls-service et mtls-client s'affichent. Les anciens services n'apparaissent pas, car nous n'avons pas ajouté d'étiquettes à leur espace de noms. Ils restent donc en dehors du maillage. Dans le menu déroulant Espace de noms, sélectionnez l'espace de noms mtls-service, puis cliquez sur le service httpbin situé en dessous.

3. Dans le panneau de gauche, accédez à Services connectés.

4. Deux services s'affichent :

   • Le service sleep dans l'espace de noms mtls-client, qui fait partie du maillage et possède un proxy side-car. Le véritable nom s'affiche et la communication est effectuée par mTLS, car il s'agit du comportement par défaut dans Istio.
   • Un service unknown, représentant le service sleep dans l'espace de noms legacy-client, qui ne fait pas partie du maillage et ne possède pas de side-car proxy. Le véritable nom ne s'affiche pas et la communication est effectuée en texte brut.

   Pointez le curseur de la souris sur l'icône en forme de cadenas dans la colonne Port de requête, puis vérifiez que mTLS est associé à la couleur verte et que le texte brut est associé à la couleur rouge.

5. Consultez maintenant l'onglet Sécurité (bêta) dans le panneau de gauche. Il indique que le service httpbin a reçu du trafic en texte brut et mTLS.

Tester l'authentification TLS mutuelle

Par défaut, Istio configure les charges de travail de destination en mode PERMISSIVE. Lorsque le mode PERMISSIVE est activé, un service peut accepter à la fois le trafic en texte brut et mTLS. L'authentification mTLS est utilisée lorsque la requête contient l'en-tête X-Forwarded-Client-Cert.

6. Utilisez Cloud Shell pour envoyer une requête du service sleep (dans l'espace de noms mtls-client) au service httpbin (dans l'espace de noms mtls-service) :

   kubectl exec $(kubectl get pod -l app=sleep -n mtls-client -o jsonpath={.items..metadata.name}) -c sleep -n mtls-client -- curl http://httpbin.mtls-service:8000/headers -s | grep X-Forwarded-Client-Cert

   Résultat (ne pas copier)

   "X-Forwarded-Client-Cert": "By=spiffe:// ...

   L'en-tête X-Forwarded-Client-Cert est présent, donc le trafic a été mutuellement authentifié et chiffré.

7. Envoyez maintenant une requête du service sleep (dans l'espace de noms mtls-client) au service httpbin (dans l'espace de noms legacy-service) :

   kubectl exec $(kubectl get pod -l app=sleep -n mtls-client -o jsonpath={.items..metadata.name}) -c sleep -n mtls-client -- curl http://httpbin.legacy-service:8000/headers -s | grep X-Forwarded-Client-Cert

   L'en-tête X-Forwarded-Client-Cert n'est pas présent, donc le trafic a été envoyé et reçu en texte brut.

8. Enfin, envoyez une requête du service sleep (dans l'espace de noms legacy-client) au service httpbin (dans l'espace de noms mtls-service) :

   kubectl exec $(kubectl get pod -l app=sleep -n legacy-client -o jsonpath={.items..metadata.name}) -c sleep -n legacy-client -- curl http://httpbin.mtls-service:8000/headers -s | grep X-Forwarded-Client-Cert

   L'en-tête X-Forwarded-Client-Cert n'est pas présent, donc le trafic a été envoyé et reçu en texte brut.

🔎 Remarque : Le service httpbin dans l'espace de noms mtls-service a accepté le trafic mTLS du service sleep dans l'espace de noms mtls-client et le trafic en texte brut du service sleep dans l'espace de noms legacy-client.

Appliquer le mode mTLS STRICT sur l'ensemble du maillage de services

En mode STRICT, les services injectés avec le proxy Istio n'acceptent pas le trafic en texte brut et s'authentifient mutuellement avec leurs clients.

Vous pouvez appliquer le mode mTLS STRICT sur l'ensemble du maillage ou par espace de noms en créant des ressources PeerAuthentication.

9. Créez des ressources PeerAuthentication pour l'ensemble du maillage de services :

   kubectl apply -n istio-system -f - <<EOF apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "mesh-wide-mtls" spec: mtls: mode: STRICT EOF

10. Exécutez cette boucle de commande imbriquée :

    for from in "mtls-client" "legacy-client"; do for to in "mtls-service" "legacy-service"; do kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n" done done

    Résultat (ne pas copier)

    sleep.mtls-client to httpbin.mtls-service: 200 sleep.mtls-client to httpbin.legacy-service: 200 sleep.legacy-client to httpbin.mtls-service: 000 command terminated with exit code 56 sleep.legacy-client to httpbin.legacy-service: 200

    🔎 Le service httpbin dans l'espace de noms mtls-service refuse désormais le trafic en texte brut du client sleep dans l'espace de noms legacy-client.

11. Supprimez la ressource mTLS PeerAuthentication au niveau du maillage en exécutant cette commande dans Cloud Shell :

    kubectl delete pa mesh-wide-mtls -n istio-system

Appliquer le mode mTLS STRICT sur un seul espace de noms

12. Dans Cloud Shell, créez un espace de noms pour mTLS STRICT :

    kubectl create ns strict-mtls-service

13. Activez l'injection automatique du proxy side-car Istio sur le nouvel espace de noms :

    # get the revision label export DEPLOYMENT=$(kubectl get deployments -n istio-system | grep istiod) export VERSION=asm-$(echo $DEPLOYMENT | cut -d'-' -f 3)-$(echo $DEPLOYMENT \ | cut -d'-' -f 4 | cut -d' ' -f 1) # enable auto-injection on the namespaces kubectl label namespace strict-mtls-service istio-injection- istio.io/rev=${VERSION} --overwrite

14. Utilisez Cloud Shell pour déployer une autre instance du service httpbin dans l'espace de noms strict-mtls-service :

    kubectl apply -f \ https://raw.githubusercontent.com/istio/istio/release-1.6/samples/httpbin/httpbin.yaml \ -n strict-mtls-service

15. Créez une ressource PeerAuthentication pour l'espace de noms strict-mtls-service :

    kubectl apply -n strict-mtls-service -f - <<EOF apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "restricted-mtls" namespace: strict-mtls-service spec: mtls: mode: STRICT EOF

16. Vérifiez que le service httpbin dans l'espace de noms mtls-service accepte toujours le trafic en texte brut :

    kubectl exec $(kubectl get pod -l app=sleep -n legacy-client -o jsonpath={.items..metadata.name}) -c sleep -n legacy-client -- curl "http://httpbin.mtls-service:8000/ip" -s -o /dev/null -w "sleep.legacy-client to httpbin.mtls-service: %{http_code}\n"

    Résultat (ne pas copier)

    sleep.legacy-client to httpbin.mtls-service: 200

17. Vérifiez maintenant que le service httpbin dans l'espace de noms strict-mtls-service n'accepte pas le trafic en texte brut :

    kubectl exec $(kubectl get pod -l app=sleep -n legacy-client -o jsonpath={.items..metadata.name}) -c sleep -n legacy-client -- curl "http://httpbin.strict-mtls-service:8000/ip" -s -o /dev/null -w "sleep.legacy-client to httpbin.strict-mtls-service: %{http_code}\n"

    Résultat (ne pas copier)

    sleep.legacy-client to httpbin.strict-mtls-service: 000 command terminated with exit code 56

18. Vérifiez que le service httpbin dans l'espace de noms strict-mtls-service accepte bien le trafic mTLS :

    kubectl exec $(kubectl get pod -l app=sleep -n mtls-client -o jsonpath={.items..metadata.name}) -c sleep -n mtls-client -- curl "http://httpbin.strict-mtls-service:8000/ip" -s -o /dev/null -w "sleep.mtls-client to httpbin.strict-mtls-service: %{http_code}\n"

    Résultat (ne pas copier)

    sleep.mtls-client to httpbin.strict-mtls-service: 200

19. Dans Google Cloud Console, sélectionnez Navigation > Anthos > Service Mesh.

20. Dans le tableau de bord Anthos Service Mesh, nous disposons maintenant de trois services. Dans le menu déroulant Espace de noms, sélectionnez l'espace de noms strict-mtls-service, puis cliquez sur le service httpbin situé en dessous.

21. Dans le panneau de gauche, cliquez sur Services connectés.

22. Pointez le curseur de la souris sur l'icône en forme de cadenas dans la colonne Port de requête pour vérifier que seul le trafic mTLS a été reçu. Le trafic peut mettre quelques minutes à apparaître dans le tableau de bord. Si le service sleep n'apparaît pas, patientez une à deux minutes, puis actualisez le tableau de bord.

23. Consultez maintenant l'onglet Sécurité (bêta) dans le panneau de gauche. Là encore, seul le trafic mTLS a été reçu.

24. Supprimez la règle d'authentification des pairs strict-mtls-service en exécutant la commande suivante dans Cloud Shell :

    kubectl delete pa restricted-mtls -n strict-mtls-service

Tâche 5 : Exploiter les ressources RequestAuthentication et AuthorizationPolicy

Cette tâche vous explique comment configurer et utiliser les ressources RequestAuthentication et AuthorizationPolicy. Vous autoriserez les requêtes associées à un jeton JWT approuvé et vous refuserez les requêtes qui n'en disposent pas.

RequestAuthentication

Une ressource RequestAuthentication définit les méthodes d'authentification des requêtes compatibles avec une charge de travail. Les requêtes comportant des informations d'authentification non valides sont rejetées. Les requêtes qui ne comportent pas d'identifiants d'authentification sont acceptées, mais ne possèdent pas d'identité authentifiée.

1. Créez une ressource RequestAuthentication pour la charge de travail httpbin dans l'espace de noms mtls-service. Cette règle permet à la charge de travail d'accepter les requêtes associées à un jeton JWT émis par testing@secure.istio.io:

   kubectl apply -f - <<EOF apiVersion: "security.istio.io/v1beta1" kind: "RequestAuthentication" metadata: name: "jwt-example" namespace: mtls-service spec: selector: matchLabels: app: httpbin jwtRules: - issuer: "testing@secure.istio.io" jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/jwks.json" EOF

2. Vérifiez qu'une requête avec un jeton JWT non valide est refusée :

   kubectl exec "$(kubectl get pod -l app=sleep -n mtls-client -o jsonpath={.items..metadata.name})" -c sleep -n mtls-client -- curl "http://httpbin.mtls-service:8000/headers" -s -o /dev/null -H "Authorization: Bearer invalidToken" -w "%{http_code}\n"

   Résultat (ne pas copier)

   401

3. Vérifiez qu'une requête sans jeton JWT est autorisée :

   kubectl exec "$(kubectl get pod -l app=sleep -n mtls-client -o jsonpath={.items..metadata.name})" -c sleep -n mtls-client -- curl "http://httpbin.mtls-service:8000/headers" -s -o /dev/null -w "%{http_code}\n"

   Résultat (ne pas copier)

   200

AuthorizationPolicy

4. Créez une ressource AuthorizationPolicy pour la charge de travail httpbin dans l'espace de noms mtls-service :

   kubectl apply -f - <<EOF apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: require-jwt namespace: mtls-service spec: selector: matchLabels: app: httpbin action: ALLOW rules: - from: - source: requestPrincipals: ["testing@secure.istio.io/testing@secure.istio.io"] EOF

   La règle nécessite que toutes les requêtes adressées à la charge de travail httpbin disposent d'un jeton JWT valide avec l'attribut requestPrincipal défini sur testing@secure.istio.io/testing@secure.istio.io. Istio construit l'attribut requestPrincipal en combinant les clés iss et sub du jeton JWT avec un séparateur "/", comme indiqué ci-dessous :

5. Téléchargez un jeton JWT légitime pouvant être utilisé pour envoyer des requêtes acceptées :

   TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -

   Résultat (ne pas copier)

   {"exp":4685989700,"foo":"bar","iat":1532389700,"iss":"testing@secure.istio.io","sub":"testing@secure.istio.io"}

   Notez que les clés iss et sub sont définies sur testing@secure.istio.io. Ainsi, Istio génère l'attribut requestPrincipal avec la valeur testing@secure.istio.io/testing@secure.istio.io :

6. Vérifiez qu'une requête avec un jeton JWT valide est autorisée :

   kubectl exec "$(kubectl get pod -l app=sleep -n mtls-client -o jsonpath={.items..metadata.name})" -c sleep -n mtls-client -- curl "http://httpbin.mtls-service:8000/headers" -s -o /dev/null -H "Authorization: Bearer $TOKEN" -w "%{http_code}\n"

   Résultat (ne pas copier)

   200

7. Vérifiez qu'une requête sans jeton JWT est refusée :

   kubectl exec "$(kubectl get pod -l app=sleep -n mtls-client -o jsonpath={.items..metadata.name})" -c sleep -n mtls-client -- curl "http://httpbin.mtls-service:8000/headers" -s -o /dev/null -w "%{http_code}\n"

   Résultat (ne pas copier)

   403

Tâche 6 : Autoriser les requêtes en fonction de la méthode et du chemin d'accès

Cette tâche vous explique comment contrôler l'accès aux charges de travail à l'aide d'une ressource AuthorizationPolicy qui évalue le type de requête et l'URL.

1. Mettez à jour la règle d'autorisation require-jwt pour la charge de travail httpbin dans l'espace de noms mtls-service. La nouvelle règle conservera l'exigence JWT que vous avez configurée à la tâche précédente. De plus, vous allez limiter le type de requêtes HTTP pour forcer les clients à n'effectuer des requêtes GET que sur le point de terminaison /ip :

   kubectl apply -f - <<EOF apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: require-jwt namespace: mtls-service spec: selector: matchLabels: app: httpbin action: ALLOW rules: - from: - source: requestPrincipals: ["testing@secure.istio.io/testing@secure.istio.io"] to: - operation: methods: ["GET"] paths: ["/ip"] EOF

2. Vérifiez qu'une requête envoyée au point de terminaison /ip de httpbin fonctionne :

   kubectl exec "$(kubectl get pod -l app=sleep -n mtls-client -o jsonpath={.items..metadata.name})" -c sleep -n mtls-client -- curl "http://httpbin.mtls-service:8000/ip" -s -o /dev/null -H "Authorization: Bearer $TOKEN" -w "%{http_code}\n"

   Résultat (ne pas copier)

   200

3. Vérifiez qu'une requête envoyée au point de terminaison /headers de httpbin est refusée :

   kubectl exec "$(kubectl get pod -l app=sleep -n mtls-client -o jsonpath={.items..metadata.name})" -c sleep -n mtls-client -- curl "http://httpbin.mtls-service:8000/headers" -s -o /dev/null -H "Authorization: Bearer $TOKEN" -w "%{http_code}\n"

   Résultat (ne pas copier)

   403

4. Supprimez la règle d'autorisation require-jwt en exécutant la commande suivante :

   kubectl delete AuthorizationPolicy require-jwt -n mtls-service

Récapitulatif

Dans cet atelier, vous avez étudié l'authentification TLS mutuelle dans Istio. Vous avez vu comment le mode mTLS PERMISSIVE permet aux services de recevoir à la fois le trafic en texte brut et mTLS en provenance des clients, ce qui vous permet d'adopter l'authentification mTLS de manière progressive. Vous avez également activé le mode mTLS STRICT sur votre maillage de services, ce qui a eu pour effet de bloquer le trafic en texte brut vers tous vos services Istio injectés, puis vous avez limité l'application du mode mTLS STRICT à un seul espace de noms.

Par ailleurs, vous avez exploré les ressources RequestAuthentication et AuthorizationPolicy dans Istio.

Étapes suivantes

• Apprenez-en plus sur l'un des concepts Istio : la sécurité .
• Découvrez comment étendre une autorisation à la totalité d'un espace de noms sur cette page.
• Apprenez-en plus sur l'initiation TLS pour le trafic de sortie.

Terminer l'atelier

Une fois l'atelier terminé, cliquez sur Terminer l'atelier. Google Cloud Skills Boost supprime les ressources que vous avez utilisées, puis efface le compte.

Si vous le souhaitez, vous pouvez noter l'atelier. Sélectionnez un nombre d'étoiles, saisissez un commentaire, puis cliquez sur Envoyer.

Le nombre d'étoiles correspond à votre degré de satisfaction :

• 1 étoile = très insatisfait(e)
• 2 étoiles = insatisfait(e)
• 3 étoiles = ni insatisfait(e), ni satisfait(e)
• 4 étoiles = satisfait(e)
• 5 étoiles = très satisfait(e)

Si vous ne souhaitez pas donner votre avis, vous pouvez fermer la boîte de dialogue.

Pour soumettre des commentaires, suggestions ou corrections, veuillez accéder à l'onglet Assistance.

Copyright 2020 Google LLC Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.