En l'absence d'authentification au niveau de la passerelle, toute requête peut atteindre vos services principaux, les exposant ainsi à des accès non autorisés. L'authentification par JSON Web Token (JWT) sur une passerelle d'entrée Alibaba Cloud Service Mesh (ASM) applique un contrôle d'accès centralisé afin que seules les requêtes présentant un JWT valide atteignent vos services.
Fonctionnement
ASM s'appuie sur deux ressources de sécurité Istio pour appliquer l'authentification JWT au niveau de la passerelle :
RequestAuthentication définit la manière dont la passerelle valide les JWT entrants : l'émetteur, la clé de signature et l'emplacement du token dans la requête. Une requête accompagnée d'un JWT invalide est rejetée. Une requête sans JWT est acceptée, mais aucune identité authentifiée ne lui est associée.
AuthorizationPolicy détermine quelles requêtes doivent impérativement présenter un JWT valide. En l'absence de cette politique, les requêtes non authentifiées (celles dépourvues de token) transitent vers vos services.
Ces deux ressources fonctionnent conjointement : RequestAuthentication valide les tokens, tandis qu'AuthorizationPolicy impose leur présence. Lorsque vous configurez l'authentification JWT via la console ASM, le système génère automatiquement ces deux ressources. L'étape JWT Config crée la ressource RequestAuthentication, et l'étape Matching Rules crée la ressource AuthorizationPolicy.
Une requête adressée à un chemin non concerné par les règles, mais portant un JWT invalide, est tout de même rejetée. Seules les requêtes totalement dépourvues de JWT sont autorisées à transiter sur les chemins non correspondants.
Informations contextuelles
Les JWT sont couramment employés pour authentifier les utilisateurs. Un JWT contient des informations utilisateur ainsi qu'un champ stockant ces données chiffrées. Lors de la mise en œuvre d'une authentification basée sur JWT, les informations chiffrées sont déchiffrées et comparées aux données saisies afin de vérifier l'identité de l'utilisateur. Pour plus d'informations, consultez la page JWT.
Prérequis
Avant de commencer, assurez-vous d'avoir :
Configurer l'authentification JWT
La configuration s'effectue en deux étapes : définissez d'abord les règles de validation JWT, puis établissez les règles de correspondance déterminant quelles requêtes nécessitent une authentification.
Étape 1 : Configurer les règles de validation JWT
Connectez-vous à la console ASM.
Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.
Sur la page Mesh Management, cliquez sur le nom de l'instance ASM cible.
Dans le volet de navigation de gauche, sélectionnez ASM Gateways > Ingress Gateway.
Sur la page Ingress Gateway, cliquez sur le nom de la passerelle d'entrée à configurer.
Dans le volet de navigation de la vue d'ensemble de la passerelle, sélectionnez Gateway Security > JWT certification.
-
À l'étape JWT Config, activez l'option Enable gateway JWT authentication et configurez les paramètres suivants :
Paramètre Description Issuer Entité ayant émis le JWT. Exemple : testing@secure.istio.io.JWKS Source Source du jeu de clés web JSON (JWKS) utilisée pour vérifier les signatures JWT. Sélectionnez jwks pour fournir directement le jeu de clés. Key Contenu du JWKS. Collez un objet JSON contenant les clés publiques servant à vérifier les signatures JWT. Exemple : { "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}AdvancedConfig (Facultatif) Cliquez sur AdvancedConfig pour ouvrir la boîte de dialogue JWT Rules Advanced Options . Configurez les paramètres décrits dans le tableau suivant, puis cliquez sur OK. Options avancées :
Option Description JWTToken Position Emplacement où la passerelle recherche le JWT dans les requêtes entrantes. JWT Passthrough Indique si le JWT original doit être transféré au service en amont après validation. Transmit Payload through Header Nom de l'en-tête utilisé pour transmettre la charge utile JWT décodée au service en amont. Cliquez sur Next.
Étape 2 : Configurer les règles de correspondance
-
À l'étape Matching Rules, configurez les paramètres suivants : Match Mode : Détermine la manière dont la passerelle applique l'authentification JWT aux requêtes correspondantes. Matching Rules : Définit les requêtes qui nécessitent (ou sont exemptées de) l'authentification JWT. Sélectionnez Custom Matching Rules, activez l'option Path et saisissez le chemin cible. Par exemple, pour exiger l'authentification JWT uniquement pour le chemin
/productpage: Avec cette configuration, les requêtes adressées à/productpagedoivent porter un JWT valide. Les requêtes vers d'autres chemins transitent sans JWT.Définissez Match Mode sur Auth If Matched.
Sélectionnez Custom Matching Rules, activez l'option Path et définissez le chemin sur
/productpage.
RemarqueSi une requête adressée à un chemin non concerné porte un JWT invalide, la passerelle la rejette néanmoins. Seules les requêtes totalement dépourvues de JWT sont autorisées à transiter sur les chemins non correspondants.
Mode Comportement Auth If Matched Les requêtes correspondant aux règles doivent passer l'authentification JWT. Les requêtes non correspondantes n'ont pas besoin de JWT. Bypass Auth If Matched Les requêtes correspondant aux règles contournent l'authentification JWT. Toutes les autres requêtes doivent passer l'authentification JWT. Cliquez sur Submit.
Après avoir cliqué sur Submit, un message de confirmation (JWT-based authentication is successfully configured) s'affiche et les ressources de sécurité Istio générées apparaissent. Cliquez sur YAML pour afficher les configurations des ressources.
Vérifier la configuration
Exécutez les tests suivants pour confirmer que l'authentification JWT fonctionne comme prévu.
Configurer le token de test
Exportez un JWT d'exemple en tant que variable d'environnement :
TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg
Remplacez <IP address of the ASM gateway> dans les commandes suivantes par l'adresse IP réelle de votre passerelle d'entrée.
JWT valide sur un chemin protégé
Vérifiez qu'une requête accompagnée d'un JWT valide adressée à /productpage renvoie le code 200 OK :
curl -I http://<IP address of the ASM gateway>/productpage -H "Authorization: Bearer $TOKEN"
Réponse attendue :
HTTP/1.1 200 OK
content-type: text/html; charset=utf-8
content-length: 4294
server: istio-envoy
date: Tue, 17 Jan 2023 08:47:34 GMT
x-envoy-upstream-service-time: 17
Absence de JWT sur un chemin protégé
Vérifiez qu'une requête sans JWT adressée à /productpage renvoie le code 403 Forbidden :
curl -I http://<IP address of the ASM gateway>/productpage
Réponse attendue :
HTTP/1.1 403 Forbidden
content-length: 19
content-type: text/plain
date: Tue, 17 Jan 2023 08:50:31 GMT
server: istio-envoy
JWT invalide sur un chemin protégé
Vérifiez qu'une requête accompagnée d'un JWT invalide adressée à /productpage renvoie le code 401 Unauthorized :
curl -I http://<IP address of the ASM gateway>/productpage -H "Authorization: Bearer invalid token"
Réponse attendue :
HTTP/1.1 401 Unauthorized
www-authenticate: Bearer realm="http://114.55.XXX.XXX/productpage", error="invalid_token"
content-length: 79
content-type: text/plain
date: Tue, 17 Jan 2023 08:51:47 GMT
server: istio-envoy
Absence de JWT sur un chemin non protégé
Vérifiez qu'une requête sans JWT adressée à un chemin extérieur aux règles de correspondance renvoie le code 200 OK :
curl -I http://<IP address of the ASM gateway>/api/v1/products/1
Réponse attendue :
HTTP/1.1 200 OK
content-type: application/json
content-length: 195
server: istio-envoy
date: Tue, 17 Jan 2023 08:55:10 GMT
x-envoy-upstream-service-time: 16
Résumé des résultats attendus
| Scénario | Chemin | JWT | Résultat attendu |
|---|---|---|---|
| JWT valide sur un chemin protégé | /productpage |
Valide | 200 OK -- Accès autorisé |
| Absence de JWT sur un chemin protégé | /productpage |
Aucun | 403 Forbidden -- Accès refusé |
| JWT invalide sur un chemin protégé | /productpage |
Invalide | 401 Unauthorized -- Accès refusé |
| Absence de JWT sur un chemin non protégé | /api/v1/products/1 |
Aucun | 200 OK -- Accès autorisé |
Rubriques connexes
Configurer la collecte des journaux d'accès pour une passerelle ASM -- Surveillez le trafic de la passerelle et détectez d'éventuels problèmes de sécurité.
Utiliser la fonctionnalité d'audit des opérations KubeAPI dans ASM -- Suivez les opérations quotidiennes et les modifications de ressources dans votre maillage.
Configurer des alertes d'audit pour les opérations sur les ressources ASM -- Mettez en place des alertes pour les modifications importantes de ressources.
Configurer l'authentification JWT pour une passerelle d'entrée (basée sur YAML) -- Configurez l'authentification JWT à l'aide du YAML CRD Istio plutôt que via la console.