2.11. Utilisation de l'adaptateur 3scale Istio

Service Mesh recherche la clé API dans les paramètres de requête et les en-têtes de demande spécifiés dans l'option user du paramètre de ressource personnalisée subject. Il vérifie les valeurs dans l'ordre indiqué dans le fichier de ressources personnalisées. Vous pouvez limiter la recherche de la clé API aux paramètres de requête ou aux en-têtes de requête en omettant l'option indésirable.

Dans cet exemple, Service Mesh recherche la clé API dans le paramètre de requête user_key. Si la clé API ne figure pas dans le paramètre de la requête, Service Mesh vérifie alors l'en-tête user-key.

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
  namespace: istio-system
spec:
  template: authorization
  params:
    subject:
      user: request.query_params["user_key"] | request.headers["user-key"] | ""
    action:
      path: request.url_path
      method: request.method | "get"

Si vous souhaitez que l'adaptateur examine un paramètre de requête ou un en-tête de requête différent, modifiez le nom en conséquence. Par exemple, pour vérifier la clé API dans un paramètre de requête nommé "key", remplacez request.query_params["user_key"] par request.query_params["key"].

Service Mesh recherche l'identifiant et la clé de l'application dans les paramètres de la requête et les en-têtes de la demande, comme spécifié dans l'option properties du paramètre de ressource personnalisée subject. La clé d'application est facultative. Il vérifie les valeurs dans l'ordre indiqué dans le fichier de ressources personnalisées. Vous pouvez limiter la recherche des informations d'identification aux paramètres de requête ou aux en-têtes de requête en n'incluant pas l'option "unwanted".

Dans cet exemple, Service Mesh recherche d'abord l'identifiant et la clé de l'application dans les paramètres de la requête, puis passe aux en-têtes de la requête si nécessaire.

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
  namespace: istio-system
spec:
  template: authorization
  params:
    subject:
        app_id: request.query_params["app_id"] | request.headers["app-id"] | ""
        app_key: request.query_params["app_key"] | request.headers["app-key"] | ""
    action:
      path: request.url_path
      method: request.method | "get"

Si vous souhaitez que l'adaptateur examine un paramètre de requête ou un en-tête de requête différent, modifiez le nom en conséquence. Par exemple, pour vérifier l'ID de l'application dans un paramètre de requête nommé identification, remplacez request.query_params["app_id"] par request.query_params["identification"].

Pour utiliser le champ OpenID Connect (OIDC) authentication method, utilisez la valeur properties sur le champ subject pour définir client_id, et éventuellement app_key.

Vous pouvez manipuler cet objet à l'aide des méthodes décrites précédemment. Dans l'exemple de configuration ci-dessous, l'identifiant du client (ID de l'application) est extrait du jeton Web JSON (JWT) sous l'étiquette azp. Vous pouvez le modifier si nécessaire.

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
spec:
  template: threescale-authorization
  params:
    subject:
      properties:
        app_key: request.query_params["app_key"] | request.headers["app-key"] | ""
        client_id: request.auth.claims["azp"] | ""
      action:
        path: request.url_path
        method: request.method | "get"
        service: destination.labels["service-mesh.3scale.net/service-id"] | ""

Pour que cette intégration fonctionne correctement, l'OIDC doit toujours être effectué dans 3scale pour que le client soit créé dans le fournisseur d'identité (IdP). Vous devez créer une autorisation de demande pour le service que vous voulez protéger dans le même espace de noms que ce service. Le JWT est transmis dans l'en-tête Authorization de la requête.

Dans l'exemple RequestAuthentication défini ci-dessous, remplacez issuer, jwksUri, et selector comme il convient.

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-example
  namespace: info
spec:
  selector:
    matchLabels:
      app: productpage
  jwtRules:
  - issuer: >-
      http://keycloak-keycloak.34.242.107.254.nip.io/auth/realms/3scale-keycloak
    jwksUri: >-
      http://keycloak-keycloak.34.242.107.254.nip.io/auth/realms/3scale-keycloak/protocol/openid-connect/certs

Vous pouvez choisir de ne pas appliquer une méthode d'authentification particulière et d'accepter toutes les informations d'identification valides pour l'une ou l'autre méthode. Si une clé API et une paire ID d'application/clé d'application sont fournies, Service Mesh utilise la clé API.

Dans cet exemple, Service Mesh vérifie la présence d'une clé API dans les paramètres de la requête, puis dans les en-têtes de la requête. S'il n'y a pas de clé API, il recherche alors un identifiant et une clé d'application dans les paramètres de la requête, puis dans les en-têtes de la requête.

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: threescale-authorization
spec:
  template: authorization
  params:
    subject:
      user: request.query_params["user_key"] | request.headers["user-key"] |
      properties:
        app_id: request.query_params["app_id"] | request.headers["app-id"] | ""
        app_key: request.query_params["app_key"] | request.headers["app-key"] | ""
        client_id: request.auth.claims["azp"] | ""
    action:
      path: request.url_path
      method: request.method | "get"
      service: destination.labels["service-mesh.3scale.net/service-id"] | ""