Notes de version Apigee Adapter for Envoy

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X.
en savoir plus

v2.1.1

Le 7 juin 2023, nous avons publié la version 2.1.1 d'Apigee Adapter for Envoy.

Problèmes résolus

  • Correction d'un problème qui empêchait la duplication des quotas entre les opérations au lieu d'être partagés au niveau du produit.

v2.1.0

Le 5 juin 2023, nous avons publié la version 2.1.0 d'Apigee Adapter for Envoy.

Problèmes résolus

  • La revendication application_id a été ajoutée à la réponse /verifyApiKey.

v2.0.7

Le 9 mars 2023, nous avons publié la version 2.0.7 d'Apigee Adapter for Envoy.

Fonctionnalités et améliorations

  • Les jetons JWT peuvent désormais ajouter une revendication nommée customattributes qui transmet la valeur à la cible dans un en-tête appelé x-apigee-customattributes (si append_metadata_headers est configuré pour être true).

Problèmes résolus

  • Correction d'un problème où une clé API non valide pouvait créer de fausses entrées de journal et de faux enregistrements d'analyse.
  • Suppression d'une vérification de version obsolète d'un proxy qui entraînait des problèmes dans les versions plus récentes d'Apigee.

v2.0.6

Le 18 octobre 2022, nous avons publié la version 2.0.6 d'Apigee Adapter for Envoy.

Problèmes résolus

  • Version de sécurité destinée à corriger une faille par déni de service (DoS) dans une bibliothèque de dépendances. Consultez la page CVE-2022-28948.

v2.0.5

Le 3 mars 2022, nous avons publié la version 2.0.5 d'Apigee Adapter for Envoy.

Problèmes résolus

  • Version de sécurité destinée à répondre à un risque de déni de service (DoS) dans la bibliothèque Prometheus. Consultez la page CVE-2022-21698.

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.0

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

Fonctionnalités et améliorations

Caractéristique 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. Pour en savoir plus, consultez

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

Disponible uniquement pour Apigee X et Apigee hybrid.

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.

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 Opération non autorisée
  • 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 cible de service distant

La sémantique de la propriété de configuration api_header reste la même que celle de 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é correspond toujours à l'attribut Cible de service à distance du produit d'API ou au champ apiSource d'une opération de produit d'API (Apigee hybrid et Apigee X uniquement).

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 d'Envoy à l'adaptateur pour spécifier directement la Cible de service à distance ou la source de l'API du produit d'API du produit 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'associer 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 X 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.

Problèmes résolus

  • 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 #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 #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 binaires pour macOS, Linux et Windows.

Nous publions des images Docker à partir d'Ubuntu et d'Ubuntu de Google, à l'aide de Boring Crypto.

Cette version est compatible avec les plates-formes suivantes:

  • Apigee hybrid, version 1.3.x, 1.4.x (date de version en attente), Apigee Edge pour le cloud public, Apigee Edge 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

Caractéristique 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 solutions

  • 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

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

Plates-formes compatibles

Nous publions des binaires pour macOS, Linux et Windows.

Nous publions des images Docker à partir d'Ubuntu et d'Ubuntu de Google, à l'aide de Boring Crypto.

Cette version est compatible avec les plates-formes suivantes:

  • Apigee hybrid, version 1.3.x, 1.4.x (date de version en attente), Apigee Edge pour le cloud public, Apigee Edge 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

Caractéristique 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.
(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. 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 Edge pour mettre à jour les cibles de service distantes des 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, nous avons lancé la version 1.2.0 de Apigee Adapter for Envoy.

Plates-formes compatibles

Nous publions des binaires pour macOS, Linux et Windows.

Nous publions des images Docker à partir d'Ubuntu et d'Ubuntu de Google, à l'aide de 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

Caractéristique 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 solutions

  • Un problème a été résolu pour résoudre un éventuel interblocage de 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, nous avons lancé la version 1.1.0 d'Apigee Adapter for Envoy.

Plates-formes compatibles

Nous publions des binaires pour macOS, Linux et Windows.

Nous publions des images Docker à partir d'Ubuntu et d'Ubuntu de Google, à l'aide de Boring Crypto.

La version 1.1.0 prend en charge 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

Caractéristique 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 Edge. 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 solutions

  • 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, nous avons lancé la version en disponibilité générale d'Apigee Adapter for Envoy.

Plates-formes compatibles

Nous publions des binaires pour macOS, Linux et Windows.

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

La version 1.0.0 prend en charge 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 version en disponibilité générale, les modifications suivantes ont été apportées à l'adaptateur:

  • Builds Go Boring

    Une nouvelle version utilisant les bibliothèques Go BoringSSL conformes à la norme FIPS est désormais disponible.

  • Modifications des indicateurs au niveau du journal

    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
  • Nouvelles options de CLI

    Des indicateurs ont été ajoutés aux commandes CLI token:

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