Alibaba Cloud Service Mesh:Configurer une politique de sécurité ASM pour mettre en œuvre une autorisation personnalisée

Prérequis

• Une application est déployée dans le cluster ajouté à l'instance ASM.

• Une passerelle d'entrée est déployée et son adresse IP est obtenue.

• L'injection automatique du proxy sidecar est activée.

• Un service d'autorisation personnalisé est déployé.

Procédure

1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.

2. Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez Mesh Security Center > ASMSecurityPolicy.

3. Sur la page ASMSecurityPolicy, cliquez sur Create. Dans la boîte de dialogue Create ASMSecurityPolicy, cliquez sur Custom Authorization Service, puis sur OK.

4. Sur la page Create Custom Authorization Service, dans l'assistant Custom Authorization Service Configuration, sélectionnez l'onglet Custom authorization service (HTTP or gRPC protocol) implemented based on envoy.ext_authz. Configurez ensuite les paramètres et cliquez sur Next.

   Cet exemple utilise les configurations suivantes. Pour plus d'informations sur les paramètres, consultez la rubrique Connexion à un service d'autorisation personnalisé utilisant HTTP. Configurez les paramètres suivants : ASM security policy name (par exemple, test), Protocol (HTTP ou gRPC), Service address (par exemple, ext-authz.default.svc.cluster.local), Service port (par exemple, 8000) et Timeout (par exemple, 10 secondes). Activez éventuellement les commutateurs Allow requests when authorization service is unavailable et Use custom error code when authorization service is unavailable. Activez le commutateur Include request headers in check (includeRequestHeadersInCheck) et ajoutez les en-têtes requis à la liste ci-dessous, tels que cookie, authorization, x-forwarded-access-token, x-forwarded-user, x-forwarded-email, x-forwarded-proto, proxy-authorization, user-agent, x-forwarded-host, from, x-forwarded-for, accept et l'en-tête personnalisé x-ext-authz. Activez le commutateur Override headers on allow (headersToUpstreamOnAllow) et ajoutez les en-têtes à remplacer, tels que authorization, cookie, path, x-auth-request-access-token, x-forwarded-access-token et x-ext-authz-check-result. Activez le commutateur Override headers on deny (headersToDownstreamOnDeny) et ajoutez les en-têtes à remplacer, tels que content-type, set-cookie et x-ext-authz-check-result. L'en-tête x-ext-authz-check-result est un en-tête personnalisé ; il doit être ajouté aux listes d'autorisation et de refus.

5. Dans l'assistant Workload and Match Rules, cliquez sur Add Workload Group. Dans la boîte de dialogue New Workload Group, configurez les paramètres et cliquez sur Submit.

   Le tableau suivant décrit la configuration des paramètres pour cet exemple.

   Paramètre	Description
   Workload Group Name	Définissez le nom sur test-policy.
   Workload List	Cliquez sur Add Workload. Dans la boîte de dialogue Add Workload, sélectionnez Workload Scope. Définissez Namespaces sur default et Workload Type sur Service. Dans la zone Select workloads, sélectionnez productpage, cliquez sur l'icône pour la déplacer vers la zone selected, puis cliquez sur OK.
   Match Rule List	Définissez Match Mode sur The selected request must be authenticated. Sélectionnez Custom Matching Rules pour Matching Rules. Ensuite, activez le commutateur Path et définissez le chemin d'accès sur /productpage.

   Après la création de la politique, le message « Politique de sécurité ASM créée avec succès » s'affiche à l'étape Complete de l'assistant. Cliquez sur View YAML pour afficher le fichier YAML de la ressource créée, ou sur Complete pour revenir à la page ASMSecurityPolicy et consulter la nouvelle politique.

6. Vérifiez si la configuration d'autorisation personnalisée prend effet.

   1. Exécutez la commande suivante pour initier une requête avec l'en-tête x-ext-authz: allow afin d'accéder au service productpage :

      curl -I -H "x-ext-authz: allow" http://${IP address of the ingress gateway}/productpage

      Résultat attendu :

      HTTP/1.1 200 OK
      content-type: text/html; charset=utf-8
      content-length: 5288
      server: istio-envoy
      date: Tue, 17 Jan 2023 07:53:14 GMT
      x-envoy-upstream-service-time: 20

      Le résultat indique que l'autorisation personnalisée est déclenchée et que l'authentification réussit.

   2. Exécutez la commande suivante pour initier une requête avec l'en-tête x-ext-authz: deny afin d'accéder au service productpage :

      curl -I -H "x-ext-authz: deny" http://${IP address of the ingress gateway}/productpage

      Résultat attendu :

      HTTP/1.1 403 Forbidden
      x-ext-authz-check-result: denied
      date: Tue, 17 Jan 2023 07:55:27 GMT
      server: istio-envoy
      x-envoy-upstream-service-time: 2
      transfer-encoding: chunked

      Le résultat indique que l'autorisation personnalisée est déclenchée, mais que l'authentification échoue.

   Les résultats précédents confirment que la configuration d'autorisation personnalisée prend effet.

Références

• Pour plus d'informations sur les concepts et les fonctionnalités des politiques de sécurité ASM, consultez la rubrique Présentation des politiques de sécurité ASM.

• Vous pouvez activer la fonctionnalité d'audit du maillage pour enregistrer ou suivre les opérations quotidiennes des différents utilisateurs. Vous pouvez également configurer des alertes d'audit pour les opérations sur les ressources ASM et envoyer des notifications d'alerte aux contacts concernés en temps opportun lorsque des ressources importantes sont modifiées. Pour plus d'informations, consultez les rubriques Utilisation de la fonctionnalité d'audit des opérations KubeAPI dans ASM et Configuration des alertes d'audit pour les opérations sur les ressources ASM.