Notes de version Apigee Adapter for Envoy

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d'Apigee Edge.

Cette page répertorie les notes de version de tous les logiciels Apigee Adapter for Envoy pour la version 2021 et les versions antérieures.

Consultez la section Adapter for Envoy pour obtenir les notes de version actuelles (2022 et versions ultérieures).

v2.0.4

Le 3 décembre 2021, nous avons lancé la version 2.0.4 d'Apigee Adapter for Envoy.

Fonctionnalités et améliorations

  • La liste des versions Envoy et Istio compatibles pour la commande samples de la CLI a été mise à jour. Ces versions sont désormais compatibles avec les exemples :
    • Versions 1.18 à 1.20 d'Envoy
    • Versions 1.10 à 1.12 d'Istio

Problèmes résolus

  • Une vérification nil a été ajoutée pour le chargement de la clé privée du bloc PEM afin d'éviter la panique. (Problème #360)
  • Les erreurs d'autorisation de service à distance sont désormais consignées au niveau Debug. Les jetons récupérant les erreurs pour les clés API constitue une exception à cette classification. Dans ce cas, les erreurs sont consignées au niveau "Erreur" afin qu'elles soient visibles même si le niveau de journalisation des données de débogage pour apigee-remote-service-envoy est désactivé. Consultez également la section Définir des niveaux de journalisation pour le service distant. (Problème 104)

v2.0.3

Le 21 septembre 2021, nous avons lancé la version 2.0.3 d'Apigee Adapter for Envoy.

Problèmes résolus

  • Un problème de journalisation d'analyse comportant des réponses directes a été résolu. Le problème ne s'est produit que dans certaines circonstances. Exemple :
    • Pour les requêtes ne nécessitant pas de vérification authn/z, aucun authContext n'a été généré et la valeur des métadonnées dynamiques était "nil", entraînant l'ignorance de l'entrée du journal d'accès.
    • La réponse refusée a utilisé du code RPC à la place du code HTTP, entraînant l'affichage réussi des enregistrements dans l'interface utilisateur d'Apigee.

v2.0.2

Le 7 juin 2021, nous avons lancé la version 2.0.2 d'Apigee Adapter for Envoy.

Problèmes résolus

  • Correction d'une condition de concurrence qui pouvait provoquer des erreurs 403 et des problèmes lorsque les champs d'application des revendications JWT étaient vides.

v2.0.1

Le mardi 29 avril 2021, nous avons lancé la version 2.0.1 d'Apigee Adapter for Envoy.

Problèmes résolus

Fonctionnalité Description
Bug

Un problème qui entraînait un dysfonctionnement de la version 2.0.0 lors de son utilisation avec Apigee Hybrid v1.5.0 ou Apigee a été résolu. Si vous mettez à niveau votre installation Apigee Hybrid vers la version 1.5.x, la séquence de mise à niveau recommandée pour l'adaptateur est la suivante :

  1. Mettez à niveau Apigee Adapter for Envoy vers la version 2.0.1.
  2. Mettez à niveau Apigee Hybrid vers la version 1.5.1.

Si vous utilisez Apigee, il vous suffit de mettre à niveau l'adaptateur vers la version 2.0.1.

v2.0.0

Le mardi 6 avril 2021, nous avons lancé la version 2.0.0 d'Apigee Adapter for Envoy.

Fonctionnalités et améliorations

Fonctionnalité Description
Compatibilité avec les environnements mutualisés

Vous pouvez désormais activer l'adaptateur pour gérer plusieurs environnements au sein d'une organisation Apigee. Cette fonctionnalité vous permet d'utiliser une instance d'Apigee Adapter for Envoy associée à une organisation Apigee afin de gérer plusieurs environnements. Avant ce changement, un adaptateur était nécessaire pour chaque environnement Apigee. Pour en savoir plus sur cette fonctionnalité, consultez la page Compatibilité avec les environnements mutualisés.
Compatibilité avec l'API Envoy v3
Compatibilité avec les métadonnées Envoy

Envoy 1.16+ permet d'envoyer des métadonnées ext_authz sans avoir à utiliser d'en-tête. Grâce à cela et à d'autres modifications associées, les codes de réponse HTTP pour les requêtes refusées sont plus précis et il n'est plus nécessaire d'installer un filtre RBAC dans Envoy. Voir

Cette fonctionnalité est uniquement compatible avec Envoy 1.16+ et Istio 1.9+.

Avec cette modification, la configuration suivante n'est plus ajoutée au fichier de configuration Envoy (envoy-config.yaml) : 

additional_request_headers_to_log:
    - x-apigee-accesstoken
    - x-apigee-api
    - x-apigee-apiproducts
    - x-apigee-application
    - x-apigee-clientid
    - x-apigee-developeremail
    - x-apigee-environment

Si vous souhaitez ajouter des en-têtes aux requêtes pour un cas spécifique, il vous suffit de définir la propriété append_metadata_headers:true dans le fichier config.yaml de l'adaptateur.
Séparer le proxy remote-token du proxy remote-service

Le proxy remote-service a été refactorisé en deux proxys distincts. Avec la version 2.0.x, le provisionnement installe deux proxys d'API : remote-service et remote-token. Les points de terminaison /token et /certs ont été déplacés du proxy remote-service vers remote-token.

Cette modification crée une séparation utile des fonctions. Désormais, le proxy remote-service n'est utilisé que pour les communications internes de l'adaptateur, tandis que le proxy remote-token fournit un exemple de workflow OAuth que vous pouvez personnaliser. Nous ne remplacerons jamais votre proxy remote-token personnalisé, même si la commande provision --force-proxy-install est utilisée.

Compatibilité avec la capture de données

L'adaptateur est désormais compatible avec la transmission de métadonnées Envoy vers la fonctionnalité de capture de données d'Apigee qui envoie les données capturées dans des variables que vous spécifiez à Apigee Analytics afin de les utiliser ultérieurement dans des rapports personnalisés. Cette fonctionnalité offre une capacité semblable à la stratégie de capture de données d'Apigee. Pour plus d'informations sur cette fonctionnalité, consultez la section Collecter des données pour les rapports personnalisés.

RBAC non requis

Comme indiqué précédemment sous Compatibilité avec les métadonnées Envoy, les requêtes non autorisées sont désormais rejetées automatiquement sans que cela ne nécessite de filtre RBAC distinct. Le RBAC n'étant plus utilisé, les clients recevront désormais les codes d'état HTTP appropriés en provenance de l'adaptateur :

  • 401 Unauthorized
  • 403 Interdit
  • 429 Trop de requêtes
  • 500 Erreur interne au serveur.

Si vous souhaitez autoriser les requêtes non autorisées à se poursuivre, vous pouvez définir le paramètre auth:allow_unauthorized:true dans le fichier config.yaml de l'adaptateur.

Les en-têtes x-apigee-* ne sont plus ajoutés par défaut

Comme indiqué précédemment dans la section Compatibilité avec les métadonnées Envoy, les en-têtes x-apigee-* ne sont plus ajoutés par défaut. Si vous souhaitez les ajouter, définissez append_metadata_headers:true dans le fichier config.yaml. Cette configuration est entièrement facultative et ne doit être utilisée que si vous souhaitez transférer des en-têtes au service cible en amont.

Mise en correspondance personnalisée d'une requête avec une opération de produit d'API Apigee

La sémantique de la propriété de configuration api_header reste la même que l'ancienne propriété target_header (la valeur par défaut est toujours le nom d'hôte cible). Le contenu de l'en-tête spécifié doit toujours correspondre à l'attribut de cible de service distant du produit d'API ou au champ Source dans une configuration d'opérations de produits d'API.

Pour remplacer cette valeur d'en-tête à l'aide des métadonnées Envoy, vous pouvez transmettre l'élément de métadonnées apigee_api depuis Envoy à l'adaptateur pour spécifier directement la cible de service distant du produit d'API ou la source des opérations de produits d'API. Pour la configuration, ajoutez du code semblable au suivant au fichier de configuration Envoy (que vous pouvez générer à l'aide de l'interface de ligne de commande de l'adaptateur) : 

typed_per_filter_config:
  envoy.filters.http.ext_authz:
    "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthzPerRoute
    check_settings:
      context_extensions:
        apigee_api: httpbin.org
Les données analytiques des requêtes refusées sont immédiatement consignées dans le journal

Désormais, l'adaptateur Envoy journalise immédiatement les requêtes refusées dans les analyses au besoin, plutôt que d'attendre que la requête apparaisse à nouveau dans le journal d'accès. Cette méthode est plus efficace et ne nécessite pas d'ajouter des métadonnées à la requête.
La compatabilité avec UDCA a été supprimée

Le streaming vers l'agent de collecte de données universel (UDCA) d'Apigee Hybrid et d'Apigee n'est plus nécessaire pour l'analytique. Cette fonction a été remplacée par l'importation directe. Cette modification supprime simplement la compatibilité avec cette option.

Ajout de la compatibilité de mTLS avec Edge pour le cloud privé dans les commandes CLI pour le provisionnement/les liaisons.

Les utilisateurs d'Apigee Edge pour le cloud privé peuvent fournir respectivement des certificats TLS côté client et un certificat racine via ‑‑tls‑cert, ‑‑tls‑key et ‑‑tls‑ca lors du provisionnement ou de la création de liaisons de produits à l'aide de l'interface de ligne de commande.

Compatibilité mTLS entre l'adaptateur et l'environnement d'exécution Apigee

Pour utiliser l'authentification mTLS entre l'adaptateur et l'environnement d'exécution Apigee, vous pouvez fournir des certificats TLS côté client dans la section tenant du fichier config.yaml de l'adaptateur. Cette modification s'applique à toutes les plates-formes Apigee compatibles. Elle active également mTLS pour l'analytique sur Apigee Edge pour Cloud Platform. Pour en savoir plus, consultez la section Configurer l'authentification mTLS entre l'adaptateur et l'environnement d'exécution Apigee.

Autres problèmes et correctifs

  • Un problème a été résolu : plusieurs configurations d'opération avec la même source d'API partagent les mêmes identifiants de bucket de quota, ce qui entraînait des conflits lors du calcul des quotas. (Problème n°34)
  • Un problème a été résolu : les opérations sans verbes spécifiés entraînaient le refus de la requête (le comportement attendu est d'autoriser tous les verbes si aucun n'est spécifié). (Problème n°39)

v1.4.0

Le mercredi 16 décembre 2020, nous avons lancé la version 1.4.0 d'Apigee Adapter for Envoy.

Plates-formes compatibles

Nous publions des fichiers binaires pour MacOS, Linux et Windows.

Nous publions des images Docker à partir des images distroless de Google, Ubuntu et Ubuntu avec Boring Crypto.

Cette version est compatible avec les plates-formes suivantes :

  • Apigee hybrid version 1.3.x, 1.4.x (date de disponibilité en attente), Apigee pour le cloud public, Apigee pour le cloud privé et Apigee sur Google Cloud
  • Versions 1.5, 1.6, 1.7 et 1.8 d'Istio
  • Versions 1.14, 1.15 et 1.16 d'Envoy

Fonctionnalités et améliorations

Fonctionnalité Description
Le proxy remote-service ne nécessite plus d'association à un produit d'API utilisant des cibles de service distant.

Cette association n'étant plus nécessaire, veuillez noter les modifications suivantes :

  • Il n'y a plus de création d'un produit d'API remote-service lors du provisionnement.
  • La commande CLI bindings verify n'est plus pertinente et a été abandonnée.
Le rôle Administrateur de l'organisation Apigee n'est plus requis pour le provisionnement.

Au lieu d'exiger l'autorisation "Administrateur de l'organisation" pour le provisionnement, vous pouvez désormais utiliser les rôles IAM "Créateur d'API" et déployeur d'API". Vous devez attribuer ces deux rôles pour que le provisionnement puisse s'effectuer correctement.
(S'applique à Apigee sur Google Cloud et Apigee hybrid uniquement)

Autres problèmes et correctifs

  • Nous avons résolu le problème d'erreur générant un arrêt prématuré lors des tentatives de nouveau provisionnement n'incluant pas l'option --rotate.
  • Désormais, la CLI de provisionnement lit et réutilise les identifiants du compte de service d'analyse à partir d'un fichier config.yaml donné (Problème n° 133).

v1.3.0

Le lundi 23 novembre 2020, nous avons lancé la version 1.3.0 d'Apigee Adapter for Envoy.

Plates-formes compatibles

Nous publions des fichiers binaires pour MacOS, Linux et Windows.

Nous publions des images Docker à partir des images distroless de Google, Ubuntu et Ubuntu avec Boring Crypto.

Cette version est compatible avec les plates-formes suivantes :

  • Apigee hybrid version 1.3.x, 1.4.x (date de disponibilité en attente), Apigee pour le cloud public, Apigee pour le cloud privé et Apigee sur Google Cloud
  • Versions 1.5, 1.6, 1.7 et 1.8 d'Istio
  • Versions 1.14, 1.15 et 1.16 d'Envoy

Fonctionnalités et améliorations

Fonctionnalité Description
Compatibilité avec le produit d'API OperationGroups. L'élément OperationGroups associe les ressources et l'application des quotas associée à un proxy ou à un service distant à l'aide de méthodes HTTP. Pour en savoir plus, consultez la page OperationGroup.
(S'applique à Apigee sur Google Cloud et Apigee hybrid uniquement)
Suppression de la compatibilité du proxy de transfert dynamique de la génération d'exemples. En raison de cette modification, les clients doivent inclure l'en-tête HOST si le nom d'hôte est différent de l'hôte cible du service distant défini dans le produit d'API. Par exemple : 
curl -i http://localhost:8080/httpbin/headers -H "HOST:httpbin.org"

Consultez Créer un produit d'API.

Compatibilité avec les comptes de service et Workload Identity. Pour permettre l'importation de données d'analyse dans Apigee lorsque vous exécutez l'adaptateur en dehors d'un cluster Apigee hybrid, vous devez utiliser le paramètre analytics-sa avec la commande apigee-remote-service-cli provision. De plus, l'adaptateur est désormais compatible avec Workload Identity sur Google Kubernetes Engine (GKE). Consultez la section Commande de provisionnement.
(S'applique à Apigee sur Google Cloud et Apigee hybrid uniquement)
Nouvel attribut de configuration jwt_provider_key. Cette clé est ajoutée au fichier de configuration. Elle représente la clé payload_in_metadata du fournisseur JWT dans la configuration Envoy ou l'émetteur JWT RequestAuthentication de la configuration Istio.
L'attribut de configuration KeepAliveMaxConnectionAge est maintenant défini par défaut sur 1 minute. La valeur par défaut précédente était de 10 minutes. Cette modification permet un scaling plus fluide. Cette valeur est également utilisée pour la durée de vie du flux des journaux d'accès. Consultez le fichier de configuration.
Suppression de commandes CLI. Les commandes CLI suivantes sont désormais obsolètes. Nous vous recommandons plutôt d'utiliser les API Apigee pour mettre à jour les cibles de services distants pour les produits d'API :
  • apigee-remote-service-cli bindings add
  • apigee-remote-service-cli bindings remove
Ajout d'une nouvelle commande CLI. La commande 
apigee-remote-service-cli samples templates

répertorie les options disponibles que vous pouvez utiliser avec l'option --template dans la commande samples create. Consultez la documentation de référence sur la CLI.
Modification de la commande CLI existante. Une modification a été apportée à la commande apigee-remote-service-cli samples create. Les options spécifiques aux modèles Envoy ou Istio sont strictement vérifiées, et des erreurs sont renvoyées en cas d'utilisation incorrecte. L'option de modèle native est obsolète. Pour obtenir la liste des modèles disponibles, utilisez la commande apigee-remote-service-cli samples templates. Consultez également la documentation de référence sur la CLI.
La réponse du point de terminaison /token suit désormais la spécification OAuth2. Le paramètre access_token a été ajouté à la réponse et le paramètre token est obsolète.

v1.2.0

Le mercredi 30 septembre 2020, nous avons lancé la version 1.2.0 d'Apigee Adapter for Envoy.

Plates-formes compatibles

Nous publions des fichiers binaires pour MacOS, Linux et Windows.

Nous publions des images Docker à partir des images distroless de Google, Ubuntu et Ubuntu avec Boring Crypto.

Cette version est compatible avec les plates-formes suivantes :

  • Apigee hybrid version 1.3.x
  • Versions 1.5, 1.6 et 1.7 d'Istio
  • Versions 1.14, 1.15 d'Envoy

Fonctionnalités et améliorations

Fonctionnalité Description
Compatibilité avec Apigee sur Google Cloud Vous pouvez désormais utiliser Apigee Adapter for Envoy avec Apigee sur Google Cloud. Vous pouvez exécuter l'adaptateur dans son propre cluster ou en exécutant le service distant pour Envoy en tant que fichier binaire natif ou dans un conteneur. Provisionnez l'adaptateur sur Apigee à l'aide de la commande de provisionnement.
Importation directe des données d'analyse Vous pouvez maintenant configurer l'adaptateur Apigee pour importer directement des données d'analyse dans Apigee. Si vous utilisez Apigee hybrid, cette nouvelle fonctionnalité permet de déployer l'adaptateur sur son propre cluster Kubernetes, en dehors du cluster où Apigee hybrid est installé. Pour activer l'importation directe, utilisez la nouvelle option --analytics-sa avec la commande provision. Consultez la section Commande de provisionnement.
La vérification de l'état renvoie "Ready" (Prêt) une fois les données produit de l'API chargées depuis Apigee. La vérification de l'état de Kubernetes ne renverra pas "Ready" tant que les données produit de l'API ne seront pas chargées depuis Apigee. Cette modification facilite le scaling et la mise à niveau, car aucun trafic ne sera envoyé à l'adaptateur nouvellement instancié jusqu'à ce qu'il soit prêt.

Autres problèmes et correctifs

  • Un problème a été résolu pour corriger un blocage potentiel de la synchronisation des quotas (problème #17).
  • Les annotations Prometheus ont été déplacées vers une spécification de pod (problème #69).
  • Un problème a été résolu pour corriger des erreurs de vérification émises à tort (problème #62).

v1.1.0

Le mercredi 26 août 2020, nous avons lancé la version 1.1.0 d'Apigee Adapter for Envoy.

Plates-formes compatibles

Nous publions des fichiers binaires pour MacOS, Linux et Windows.

Nous publions des images Docker à partir des images distroless de Google, Ubuntu et Ubuntu avec Boring Crypto.

La version 1.1.0 est compatible avec les plates-formes suivantes :

  • Apigee hybrid version 1.3
  • Versions 1.5, 1.6 et 1.7 d'Istio
  • Versions 1.14, 1.15 d'Envoy

Fonctionnalités et améliorations

Fonctionnalité Description
Valider les liaisons Une nouvelle commande apigee-remote-service-cli bindings verify a été ajoutée à la CLI. Cette commande vérifie que le produit d'API spécifié et les applications de développeur associées sont également liés à un produit de service distant. Consultez la section Valider une liaison.
Générer des échantillons Une nouvelle commande apigee-remote-service-cli samples create a été ajoutée à la CLI. Cette commande crée des exemples de fichiers de configuration pour les déploiements Envoy ou Istio natifs. Les fichiers de configuration que vous générez avec cette commande remplacent les exemples de fichiers installés avec Adapter for Envoy dans les versions précédentes. Consultez la section Commande d'exemples.
Authentification OAuth L'adaptateur utilise désormais l'authentification OAuth2 lorsque l'authentification multifacteur (MFA) est activée pour Apigee. Utilisez l'option --mfa chaque fois que vous utilisez l'option --legacy.
Conteneur Distroless L'adaptateur utilise désormais les images distroless de Google (gcr.io/distroless/base) au lieu de scratch pour la base d'images Docker par défaut.

Autres problèmes et correctifs

  • Un problème de CLI a été résolu pour les commandes de liaison dans OPDK. (#29)
  • Le quota pouvait se bloquer en cas de perte de connexion (apigee/apigee-remote-service-envoy). (#31)
  • Les images Docker sont désormais créées avec un utilisateur non racine (999).
  • Les exemples Kubernetes imposent qu'il s'agisse d'un utilisateur non racine.
  • Le paramètre --http1.1 n'est plus nécessaire pour les commandes curl sur les points de terminaison du proxy. L'option a été supprimée des exemples.

v1.0.0

Le vendredi 31 juillet 2020, nous avons lancé la version en disponibilité générale d'Apigee Adapter for Envoy.

Plates-formes compatibles

Nous publions des fichiers binaires pour MacOS, Linux et Windows.

Nous publions à partir de zéro des images Docker, Ubuntu et Ubuntu avec Boring Crypto.

La version 1.0.0 est compatible avec les plates-formes suivantes :

  • Apigee hybrid version 1.3
  • Versions 1.5 et 1.6 d'Istio
  • Versions 1.14, 1.15 d'Envoy

Ajouts et modifications

Entre la version v1.0-beta4 et la disponibilité générale, les modifications suivantes ont été apportées à l'adaptateur :

  • Builds Go Boring

    Un nouveau build est désormais disponible. Il utilise les bibliothèques Go BoringSSL conformes avec la norme FIPS.

  • Modifications des indicateurs de niveau de journalisation

    Les indicateurs de niveau de journalisation pour le service apigee-remote-service-envoy ont été modifiés pour des raisons de cohérence :

    Ancien indicateur Nouvel indicateur
    log_level log-level
    json_log json-log
  • Nouveaux indicateurs CLI

    De nouveaux indicateurs ont été ajoutés aux commandes token de la CLI :

    Option Description
    --legacy Définissez cette option si vous utilisez Apigee Cloud.
    --opdk Définissez cette option si vous utilisez Apigee pour le cloud privé.