Tous les produits
Search

Ce produit

    Alibaba Cloud Service Mesh:Intégrer un service d'autorisation personnalisé via HTTP

    Centre de documentation

    Alibaba Cloud Service Mesh:Intégrer un service d'autorisation personnalisé via HTTP

    Dernière mise à jour :Aug 11, 2026

    Utilisez un service d'autorisation personnalisé pour mettre en œuvre un contrôle d'accès granulaire sur les services qui communiquent via HTTP. Cette fonctionnalité vous permet d'adapter le mécanisme d'autorisation à vos besoins métier spécifiques, d'ajouter un flux d'autorisation aux communications inter-services et de garantir que seules les requêtes authentifiées et autorisées peuvent accéder aux ressources du service. Cela renforce la sécurité des communications entre les services. Cette rubrique utilise les applications sleep et httpbin comme exemple pour illustrer l'intégration d'un service d'autorisation personnalisé via HTTP.

    Prérequis

    Le cluster est ajouté à l'instance ASM.

    Étape 1 : Déployer le service d'autorisation personnalisé

    Déployez un service d'autorisation personnalisé dans un cluster ACK. Ce service doit être conforme à la spécification API du service d'autorisation personnalisé Istio et prendre en charge à la fois HTTP et gRPC pour implémenter la logique d'autorisation personnalisée. Le service d'exemple présenté dans cette rubrique exige que les requêtes incluent l'en-tête de requête x-ext-authz: allow pour passer le contrôle d'autorisation avec succès.

    Remarque

    Cette rubrique fournit un exemple de service d'autorisation personnalisé. Vous pouvez également utiliser le code de cet exemple d'application pour créer votre propre service d'autorisation personnalisé. Pour plus d'informations, consultez Autorisation personnalisée.

    1. Utilisez kubectl pour vous connecter au cluster et créez un fichier nommé ext-authz.yaml avec le contenu suivant.

      Pour savoir comment utiliser kubectl pour se connecter à un cluster, consultez Obtenir le fichier kubeconfig d'un cluster et utiliser kubectl pour s'y connecter.

      Développer pour afficher le fichier ext-authz.yaml

      # Copyright Istio Authors
#
#   Licensed under the Apache License, Version 2.0 (the "License");
#   you may not use this file except in compliance with the License.
#   You may obtain a copy of the License at
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
#   Unless required by applicable law or agreed to in writing, software
#   distributed under the License is distributed on an "AS IS" BASIS,
#   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#   See the License for the specific language governing permissions and
#   limitations under the License.

# Example configurations for deploying ext-authz server separately in the mesh.

apiVersion: v1
kind: Service
metadata:
  name: ext-authz
  labels:
    app: ext-authz
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 8000
  - name: grpc
    port: 9000
    targetPort: 9000
  selector:
    app: ext-authz
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ext-authz
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ext-authz
  template:
    metadata:
      labels:
        app: ext-authz
    spec:
      containers:
      - image: istio/ext-authz:0.6
        imagePullPolicy: IfNotPresent
        name: ext-authz
        ports:
        - containerPort: 8000
        - containerPort: 9000
---

    2. Exécutez la commande suivante pour déployer le service d'autorisation personnalisé dans le cluster :

      kubectl apply -f ext-authz.yaml

    3. Exécutez la commande suivante pour vérifier l'état du déploiement du pod :

      kubectl get pod

      Sortie attendue :

      NAME                         READY   STATUS    RESTARTS   AGE
ext-authz-6b5db88f86-2m7c6   2/2     Running   0          79m

    4. Exécutez la commande suivante pour vérifier que l'application fonctionne correctement :

      kubectl logs "$(kubectl get pod -l app=ext-authz -n default -o jsonpath={.items..metadata.name})" -n default -c ext-authz

      Sortie attendue :

      2023/12/20 08:15:39 Starting gRPC server at [::]:9000
2023/12/20 08:15:39 Starting HTTP server at [::]:8000

      La sortie indique que l'application fonctionne correctement et que le service d'autorisation personnalisé a été déployé.

    5. Récupérez le port HTTP du service d'autorisation ext-authz.

      1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

      2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Network > Services.

      3. Sur la page Services, cliquez sur ext-authz.

        Dans la section Endpoint, le port HTTP est 8000. L'adresse HTTP de ce service est ext-authz.default.svc.cluster.local:8000.

    Étape 2 : Déployer les exemples d'applications

    1. Créez un fichier nommé httpbin.yaml avec le contenu suivant :

      Développer pour afficher le fichier httpbin.yaml

      # Copyright Istio Authors
#
#   Licensed under the Apache License, Version 2.0 (the "License");
#   you may not use this file except in compliance with the License.
#   You may obtain a copy of the License at
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
#   Unless required by applicable law or agreed to in writing, software
#   distributed under the License is distributed on an "AS IS" BASIS,
#   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#   See the License for the specific language governing permissions and
#   limitations under the License.
##################################################################################################
# httpbin service
##################################################################################################
apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
---
apiVersion: v1
kind: Service
metadata:
  name: httpbin
  labels:
    app: httpbin
    service: httpbin
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpbin
      version: v1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      serviceAccountName: httpbin
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80

    2. Exécutez la commande suivante pour déployer l'application httpbin dans le cluster :

      kubectl apply -f httpbin.yaml

    3. Créez un fichier nommé sleep.yaml avec le contenu suivant :

      Développer pour afficher le fichier sleep.yaml

      # Copyright Istio Authors
#
#   Licensed under the Apache License, Version 2.0 (the "License");
#   you may not use this file except in compliance with the License.
#   You may obtain a copy of the License at
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
#   Unless required by applicable law or agreed to in writing, software
#   distributed under the License is distributed on an "AS IS" BASIS,
#   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#   See the License for the specific language governing permissions and
#   limitations under the License.
##################################################################################################
# Sleep service
##################################################################################################
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    service: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curlimages/curl
        command: ["/bin/sleep", "3650d"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true
---

    4. Exécutez la commande suivante pour déployer l'application sleep dans le cluster :

      kubectl apply -f sleep.yaml

    Étape 3 : Se connecter au service d'autorisation personnalisé

    Enregistrez le service que vous avez déployé à l'Étape 1 auprès du Service Mesh, afin que le Service Mesh puisse utiliser ce service pour l'autorisation.

    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 > Custom Authorization Service. Sur la page qui s'affiche, cliquez sur Define Custom Authorization Service.

    3. Sur la page Register External Authorization Service, cliquez sur l'onglet Custom authorization service (HTTP or gRPC protocol) implemented based on envoy.ext_authz, configurez les paramètres, puis cliquez sur Create.

      Type

      Parameter

      Description

      Paramètres obligatoires

      Protocol

      Sélectionnez le protocole de l'application d'autorisation personnalisée. Dans cette rubrique, sélectionnez HTTP.

      Name

      Nom du service d'autorisation personnalisé. Dans cette rubrique, saisissez test4http.

      Service Address

      Saisissez le nom de domaine complet de l'application d'autorisation personnalisée au format <Nom de l'application>.<namespace>.svc.<Domaine du cluster>. Dans cette rubrique, saisissez ext-authz.default.svc.cluster.local.

      Port(1 - 65535)

      Port de l'application d'autorisation personnalisée. Dans cette rubrique, saisissez 8000.

      Timeout(second)

      Si l'application d'autorisation ne répond pas dans ce délai, le service d'autorisation est considéré comme indisponible. Dans cette rubrique, définissez la valeur sur 10 secondes.

      Paramètres facultatifs

      Skip authentication while authorization service is unavailable

      Si cette option est activée, les requêtes sont autorisées à procéder même lorsque le service d'autorisation est indisponible. Dans cet exemple, cette option est désactivée.

      Error code returned by asm proxy while Auth-Service is not available

      Cette option n'est disponible que si l'option Skip authentication while authorization service is unavailable est désactivée. Si vous activez cette option, vous devez spécifier un code d'erreur à renvoyer au client lorsque le service d'autorisation est indisponible. Dans cette rubrique, cette option est désactivée.

      Carry origin header within auth request [includeRequestHeadersInCheck]

      Si vous activez cette option, vous devez spécifier les clés des en-têtes que vous souhaitez inclure. Les en-têtes correspondants sont envoyés au service d'autorisation personnalisé. Dans cette rubrique, configurez le paramètre comme indiqué dans Inclure des en-têtes dans la requête d'autorisation.

      Remarque

      Vous ne pouvez configurer ce paramètre que si le Protocol est défini sur HTTP.

      Add a header in the authentication request (if a header with the same name already exists, the original value will be overwritten) [includeAdditionalHeadersInCheck]

      Si vous activez cette option, vous devez spécifier les clés et les valeurs des en-têtes que vous souhaitez ajouter à la requête d'autorisation.

      Si un en-tête de requête porte le même nom qu'un en-tête que vous ajoutez, sa valeur est écrasée. Dans cet exemple, cette option est désactivée.

      Remarque

      Vous ne pouvez configurer ce paramètre que si le Protocol est défini sur HTTP.

      Overwrite Header when authentication passes (overwrite Header in the request to the target service by using Header in the authentication request Response) [headersToUpstreamOnAllow]

      Lorsque l'autorisation aboutit, le maillage de services utilise les en-têtes correspondants de la réponse d'autorisation pour écraser les en-têtes de la requête envoyée au service de destination. Dans cette rubrique, configurez le paramètre comme indiqué dans Écraser les en-têtes lors d'une autorisation réussie.

      Remarque

      Vous ne pouvez configurer ce paramètre que si le Protocol est défini sur HTTP.

      Overwrite Header when authentication fails (overwrite Header in Response using Header in authentication request Response) [headersToDownstreamOnDeny]

      Si l'autorisation échoue, le maillage de services utilise les en-têtes correspondants de la réponse d'autorisation pour écraser les en-têtes de la réponse envoyée au client. Dans cette rubrique, configurez le paramètre comme indiqué dans Écraser les en-têtes lors d'un échec d'autorisation.

      Remarque

      Vous ne pouvez configurer ce paramètre que si le Protocol est défini sur HTTP.

      Carry origin request body within auth request

      Si vous activez cette option, vous devez spécifier la longueur maximale du corps de la requête à envoyer dans la requête d'autorisation. Si vous activez également l'option Allow send incomplete message to Auth-Service(HTTP 413 will be returned if request body size beyond limitation and this option is disabled), lorsque la taille du corps de la requête dépasse la longueur maximale spécifiée, le système tronque le corps à cette longueur maximale et l'envoie au service d'autorisation.

      Figure 1. Inclure des en-têtes dans la requête d'autorisation

      Remarque

      La dernière ligne concerne l'en-tête x-ext-authz nouvellement ajouté.

      La liste complète des en-têtes à inclure dans la requête d'autorisation est : cookie, x-forwarded-access-token, x-forwarded-user, x-forwarded-email, authorization, x-forwarded-proto, proxy-authorization, user-agent, x-forwarded-host, from, x-forwarded-for, accept et x-ext-authz.

      Figure 2. Écraser les en-têtes lors d'une autorisation réussie

      Remarque

      La dernière ligne concerne l'en-tête x-ext-authz-check-result nouvellement ajouté.

      Les autres en-têtes configurés incluent authorization, cookie, path, x-auth-request-access-token et x-forwarded-access-token.

      Figure 3. Écraser les en-têtes lors d'un échec d'autorisation

      Remarque

      La dernière ligne concerne l'en-tête x-ext-authz-check-result nouvellement ajouté.

      La liste des en-têtes à écraser inclut également les en-têtes existants content-type et set-cookie.

    Étape 4 : Définir une politique d'autorisation

    Créez une politique d'autorisation pour spécifier quelles opérations de requête nécessitent une autorisation.

    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 > AuthorizationPolicy. Sur la page qui s'affiche, cliquez sur Create.

    3. Sur la page Create, configurez les paramètres et cliquez sur Create.

      Parameter

      Description

      Name

      Nom de la politique d'autorisation personnalisée. Dans cette rubrique, saisissez test1.

      Policy Type

      Sélectionnez Custom Authorization Service.

      Custom Authorization Service

      Sélectionnez httpextauth-test4http(HTTP).

      Namespace

      Dans l'onglet Workload Scope, sélectionnez le namespace default.

      Effective Scope

      Sélectionnez Service.

      Workload

      Sélectionnez httpbin.

      Request Matching Rules

      Dans la section Add Request Target, activez Paths et définissez la valeur sur /headers.

    Étape 5 : Vérifier l'autorisation personnalisée

    1. Exécutez la commande suivante pour accéder à httpbin.default:8000/ip :

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

      Un code d'état 200 est renvoyé, ce qui indique que l'autorisation n'a pas été déclenchée. En effet, le chemin de la requête /ip ne correspond pas au chemin /headers défini dans la politique d'autorisation. Par conséquent, la politique ne s'applique pas à cette requête.

    2. Exécutez la commande suivante pour envoyer une requête avec l'en-tête de requête x-ext-authz: deny vers httpbin.default:8000/headers :

      kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -ndefault -- curl "http://httpbin.default:8000/headers" -H "x-ext-authz: deny" -s -i

      Sortie attendue :

      HTTP/1.1 403 Forbidden
x-ext-authz-check-result: denied
content-length: 76
content-type: text/plain; charset=utf-8
date: Wed, 20 Dec 2023 09:53:28 GMT
server: envoy
x-envoy-upstream-service-time: 10
denied by ext_authz for not found header `x-ext-authz: allow` in the request

      La sortie indique que l'autorisation est déclenchée, mais que le contrôle d'autorisation a échoué. La réponse inclut le nouvel en-tête de réponse x-ext-authz-check-result: denied. L'autorisation est déclenchée car le chemin de la requête correspond au chemin /headers spécifié dans la politique d'autorisation.

    3. Exécutez la commande suivante pour envoyer une requête avec l'en-tête de requête x-ext-authz: allow vers httpbin.default:8000/headers :

      kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -n default -- curl "http://httpbin.default:8000/headers" -H "x-ext-authz: allow" -s

      Sortie attendue :

      {
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.default:8000",
    "User-Agent": "curl/8.5.0",
    "X-Envoy-Attempt-Count": "1",
    "X-Ext-Authz": "allow",
    "X-Ext-Authz-Check-Result": "allowed",
    "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/default/sa/httpbin;Hash=c3e5364e87add0f4f69e6b0d029f5961b404c8f209bf9004b3d21a82cf67****;Subject=\"\";URI=spiffe://cluster.local/ns/default/sa/sleep"
  }
}

      La sortie indique que l'autorisation est déclenchée et que le contrôle d'autorisation a réussi. La réponse inclut le nouvel en-tête "X-Ext-Authz-Check-Result": "allowed". L'autorisation est déclenchée car le chemin de la requête correspond au chemin /headers spécifié dans la politique d'autorisation.

    Opérations connexes