Versionshinweise zu Apigee-Adapter for Envoy

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Auf dieser Seite finden Sie Versionshinweise für alle Apigee Adapter for Envoy-Software für 2021 und früher.

Die aktuellen Versionshinweise finden Sie unter Adapter for Envoy (2022 und später).

v2.0.4

Am 3. Dezember 2021 wurde Version 2.0.4 von Apigee Adapter for Envoy veröffentlicht.

Funktionen und Verbesserungen

  • Die Liste der unterstützten Envoy- und Istio-Versionen für den CLI-Befehl samples wurde aktualisiert. Diese Versionen werden jetzt für Beispiele unterstützt:
    • Envoy-Versionen 1.18 bis 1.20
    • Istio-Versionen 1.10 bis 1.12

Behobene Probleme

  • Es wurde eine Nullprüfung für das Laden des privaten Schlüssels des PEM-Blocks hinzugefügt, um eine Panik zu vermeiden. (Problem Nr. 360)
  • Fehler bei der Remotedienst-Autorisierung werden jetzt auf Fehlerbehebungsebene protokolliert. Eine Ausnahme von dieser Kategorisierung erfolgt bei Tokenabruffehlern für API-Schlüssel. In diesem Fall werden Fehler auf Fehlerebene protokolliert, damit sie auch dann sichtbar sind, wenn die Fehlerbehebungs-Logebene für apigee-remote-service-envoy deaktiviert ist. Siehe Logebenen für Remotedienst festlegen. (Problem Nr. 104)

v2.0.3

Am 21. September 2021 wurde Version 2.0.3 von Apigee Adapter for Envoy veröffentlicht.

Behobene Probleme

  • Ein Analyse-Logging-Problem mit direkten Antworten wurde behoben. Das Problem ist nur unter bestimmten Umständen aufgetreten. Beispiel:
    • Für Anfragen, die keine authn/z-Prüfung erfordern, wurde kein authContext generiert und dynamische Metadaten waren null, was dazu führte, dass der Zugriffslogeintrag ignoriert wurde.
    • In der abgelehnten Antwort wurde RPC-Code anstelle von HTTP-Code verwendet, sodass Einträge in der Apigee-Benutzeroberfläche als Erfolg angezeigt wurden.

v2.0.2

Am 7. Juni 2021 wurde Version 2.0.2 von Apigee Adapter for Envoy veröffentlicht.

Behobene Probleme

  • Eine Race-Bedingung wurde behoben, die zu 403-Fehlern und Paniken geführt hat, wenn JWT-Anforderungsbereiche nil waren.

v2.0.1

Am Dienstag, dem 29. April 2021 haben wir Version 2.0.1 von Apigee Adapter for Envoy veröffentlicht.

Behobene Probleme

Feature Beschreibung
Fehler

Ein Problem wurde behoben, das bei Verwendung mit Apigee Hybrid v1.5.0 oder Apigee dazu führte, dass v2.0.0 nicht richtig funktionierte. Wenn Sie Ihre Apigee Hybrid-Installation auf Version 1.5.x aktualisieren, lautet der empfohlene Upgrade-Pfad für den Adapter:

  1. Aktualisieren Sie den Apigee-Adapter for Envoy auf v2.0.1.
  2. Führen Sie ein Upgrade von Apigee Hybrid auf Version 1.5.1 durch.

Wenn Sie Apigee verwenden, führen Sie einfach ein Upgrade des Adapters auf v2.0.1 durch.

v2.0.0

Am Dienstag, dem 6. April 2021 haben wir Version 2.0.0 von Apigee Adapter for Envoy veröffentlicht.

Funktionen und Verbesserungen

Feature Beschreibung
Unterstützung von Mehrmandanten-Umgebungen

Sie können den Adapter jetzt so aktivieren, dass mehrere Umgebungen in einer Apigee-Organisation bedient werden. Mit diesem Feature können Sie einen einzelnen Apigee Adapter for Envoy, der mit einer einzelnen Apigee-Organisation verknüpft ist, so verwenden, dass mehrere Umgebungen bedient werden. Vor dieser Änderung war ein Adapter immer mit einer Apigee-Umgebung verknüpft. Weitere Informationen zu diesem Feature finden Sie unter Unterstützung von Mehrmandanten-Umgebungen.
Unterstützung für Envoy v3 API
Unterstützung von Envoy-Metadaten

Mit Envoy 1.16+ können Sie ext_authz-Metadaten senden, ohne Header verwenden zu müssen. Durch die Verwendung dieser und ähnlicher Änderungen stellen wir nun bessere HTTP-Antwortcodes für abgelehnte Anfragen bereit und müssen keine RBAC-Filter in Envoy mehr installieren. Weitere Informationen finden Sie im Hilfeartikel

Dieses Feature wird nur für Envoy 1.16+ und Istio 1.9+ unterstützt.

Durch diese Änderung wird die folgende Konfiguration nicht mehr der Envoy-Konfigurationsdatei (envoy-config.yaml) hinzugefügt: 


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

Wenn Sie Header an Anfragen für einen Sonderfall anhängen möchten, legen Sie in der config.yaml-Datei des Adapters das Attribut append_metadata_headers:true fest.
Proxy remote-token von Proxy remote-service teilen

Der Proxy remote-service wurde in zwei separate Proxys umgewandelt. Mit der Bereitstellung v2.0.x werden zwei API-Proxys installiert: remote-service und remote-token. Die Endpunkte /token und /certs wurden vom remote-service-Proxy zu remote-token verschoben.

Durch diese Änderung entsteht eine nützliche Trennung von Funktionen. Jetzt wird der remote-service-Proxy nur für die interne Adapterkommunikation verwendet, während der Proxy remote-token einen OAuth-Beispielworkflow bereitstellt, den Sie anpassen können. Wir überschreiben Ihren benutzerdefinierten remote-token-Proxy niemals, auch wenn der Befehl provision --force-proxy-install verwendet wird.

Unterstützung der Datenerfassung

Der Adapter unterstützt die Übergabe von Envoy-Metadaten an das Apigee-Feature zur Datenerfassung, das erfasste Daten in Variablen sendet, die Sie in Apigee Analytics für benutzerdefinierte Berichte angeben. Dieses Feature bietet eine Funktion, die der Datenerfassungsrichtlinie von Apigee ähnelt. Weitere Informationen zu dieser Funktion finden Sie unter Daten für benutzerdefinierte Berichte erfassen.

RBAC nicht erforderlich

Wie bereits unter Unterstützung für Envoy-Metadaten beschrieben, lehnen wir jetzt nicht autorisierte Anfragen sofort ab, ohne dass ein separater RBAC-Filter erforderlich ist. Da RBAC nicht verwendet wird, erhalten Clients die folgenden HTTP-Statuscodes jetzt je nach Adapter

  • 401 Nicht autorisiert
  • 403 Unzulässig
  • 429 Zu viele Anfragen
  • 500 Interner Serverfehler

Wenn Sie zulassen möchten, dass nicht autorisierte Anfragen weiter bearbeitet werden, legen Sie auth:allow_unauthorized:true in der config.yaml-Datei des Adapters fest.

x-apigee-*-Header werden nicht mehr standardmäßig angehängt

Wie zuvor im Abschnitt Unterstützung von Envoy-Metadaten erwähnt, werden x-apigee-*-Header nicht mehr standardmäßig angehängt. Wenn Sie sie hinzufügen möchten, legen Sie in der Datei config.yaml append_metadata_headers:true fest. Diese Konfiguration ist optional und sollte nur verwendet werden, wenn Header an den vorgelagerten Zieldienst weitergeleitet werden sollen.

Benutzerdefinierter Abgleich einer Anfrage mit einem Apigee API-Produktvorgang

Die Semantik des api_header-Konfigurationsattributs bleibt gegenüber der vorherigen des target_header-Attributs unverändert (die Standardeinstellung ist weiterhin der Zielhostname), und der Inhalt des angegebenen Headers stimmt weiterhin mit dem Attribut Remote-Dienstziel des API-Produkts oder mit dem Feld Quelle in der Konfiguration eines API-Produktvorgangs überein.

Wenn Sie diesen Headerwert mit Envoy-Metadaten überschreiben möchten, können Sie das Metadatenelement apigee_api von Envoy an den Adapter übergeben und so das Remote-Dienstziel des API-Produkts oder die API-Quelle des API-Produktvorgangs direkt angeben. Zur Konfiguration fügen Sie der Konfigurationsdatei von Envoy einen Code wie den folgenden hinzu (den Sie mithilfe der Befehlszeile des Adapters generieren können): 


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
Analytics für abgelehnte Anfragen werden sofort protokolliert.

Envoy Adapter protokolliert jetzt abgelehnte Anfragen je nach Bedarf sofort in Analytics, ohne zu warten, bis die Anfrage im Zugriffslog zurückgegeben wird. Dies ist effizienter und erfordert keinerlei Metadaten, die an die Anfrage angehängt sind.
Unterstützung für UDCA wurde entfernt

Das Streaming in den Universal Data Collection Agent (UDCA) von Apigee in Apigee hybrid und Apigee wird für Analytics nicht mehr benötigt, da es durch einen direkten Upload ersetzt wurde. Durch diese Änderung wird schlicht die Legacy-Unterstützung für diese Option entfernt.

mTLS-Unterstützung für Edge for Private Cloud in den Befehlszeilenbefehlen für Bereitstellung/Bindungen

Nutzer von Apigee Edge for Private Cloud können clientseitige TLS-Zertifikate und Root-Zertifikate über ‑‑tls‑cert, ‑‑tls‑key bzw. ‑‑tls‑ca bereitstellen, wenn Sie Produktbindungen über die Befehlszeile bereitstellen oder auflisten.

mTLS-Unterstützung zwischen dem Adapter und der Apigee-Laufzeit

Sie können clientseitige TLS-Zertifikate im Abschnitt tenant der Datei config.yaml des Adapters bereitstellen, um mTLS zwischen dem Adapter und der Apigee-Laufzeit zu verwenden. Diese Änderung gilt für alle unterstützten Apigee-Plattformen. Außerdem wird mTLS für Analysen für die Apigee Edge for Private Cloud-Plattform aktiviert. Weitere Informationen finden Sie unter mTLS zwischen dem Adapter und der Apigee-Laufzeit konfigurieren.

Sonstige Probleme und Korrekturen

  • Ein Problem wurde behoben, bei dem mehrere Vorgangskonfigurationen mit derselben API-Quelle dieselben Kontingent-Bucket-IDs gemeinsam verwendet und dadurch Konflikte bei der Kontingentberechnung verursacht haben. (Problem #34)
  • Ein Problem wurde behoben, bei dem durch Vorgänge ohne angegebene Verben die Anfrage abgelehnt wurde (das erwartete Verhalten ist, dass alle Verben zugelassen werden, wenn keines angegeben wird). (Problem #39)

v1.4.0

Am Mittwoch, dem 16. Dezember 2020, wurde die Version 1.4.0 von Apigee Adapter for Envoy veröffentlicht.

Unterstützte Plattformen

Wir veröffentlichen Binärprogramme für MacOS, Linux und Windows.

Wir veröffentlichen Docker-Images von Ubuntu und Ubuntu mit Boring Crypto sowie Distroless-Images von Google.

In dieser Version werden die folgenden Plattformen unterstützt:

  • Apigee Hybrid-Version 1.3.x, 1.4.x (Veröffentlichungsdatum ausstehend), Apigee for Public Cloud, Apigee for Private Cloud und Apigee in Google Cloud
  • Istio-Versionen 1.5, 1.6, 1.7, 1.8
  • Envoy-Versionen 1.14, 1.15, 1.16

Funktionen und Verbesserungen

Feature Beschreibung
Der Proxy remote-service muss keine Verbindung mehr zu einem API-Produkt herstellen, das Remotedienstziele verwendet.

Da diese Verknüpfung nicht mehr benötigt wird, beachten Sie die folgenden Änderungen:

  • Ein remote-Dienst API-Produkt wird während der Bereitstellung nicht mehr erstellt.
  • Der Befehlszeilenbefehl bindings verify ist nicht mehr relevant und wurde verworfen.
Die Rolle „Apigee-Organisationsadministrator“ ist für die Bereitstellung nicht mehr erforderlich.

Anstatt die Berechtigung "Organisationsadministrator" für die Bereitstellung zu benötigen, können Sie jetzt die IAM-Rollen "API-Ersteller" und "Bereitsteller" verwenden. Sie müssen beide Rollen zuweisen, damit die Bereitstellung erfolgen kann.
(Gilt nur für Apigee in Google Cloud und Apigee hybrid)

Sonstige Probleme und Korrekturen

  • Ein Problem wurde behoben, bei dem die erneute Bereitstellung von Apigee ohne die Option --rotate mit einem Fehler beendet wurde.
  • Mit der Bereitstellungsbefehlszeile werden nun die Anmeldedaten des Analyse-Dienstkontos aus einer bestimmten config.yaml-Datei gelesen und wiederverwendet (Problem Nr. 133).

v1.3.0

Am Montag, dem 23. November 2020, haben wir die Version 1.3.0 von Apigee Adapter for Envoy veröffentlicht.

Unterstützte Plattformen

Wir veröffentlichen Binärprogramme für MacOS, Linux und Windows.

Wir veröffentlichen Docker-Images von Ubuntu und Ubuntu mit Boring Crypto sowie Distroless-Images von Google.

In dieser Version werden die folgenden Plattformen unterstützt:

  • Apigee Hybrid-Version 1.3.x, 1.4.x (Veröffentlichungsdatum ausstehend), Apigee for Public Cloud, Apigee for Private Cloud und Apigee in Google Cloud
  • Istio-Versionen 1.5, 1.6, 1.7, 1.8
  • Envoy-Versionen 1.14, 1.15, 1.16

Funktionen und Verbesserungen

Feature Beschreibung
Support für API OperationsGroups Vorgangsgruppen binden die Ressourcen und die zugehörige Kontingentersetzung in einem Proxy oder Remotedienst mit HTTP-Methoden. Details finden Sie unter OperationGroup.
(Gilt nur für Apigee in Google Cloud und Apigee Hybrid)
Unterstützung für dynamischen Weiterleitungsproxy aus der Generierung von Stichproben entfernen. Aufgrund dieser Änderung müssen Clients den Header HOST enthalten, wenn sich der Hostname vom im Ziel-API des Remote-Diensts angegebenen Host unterscheidet. Zum Beispiel: 

curl -i http://localhost:8080/httpbin/headers -H "HOST:httpbin.org"

Siehe API-Produkt erstellen.

Support für Dienstkonten und Workload Identity Damit Analysedaten in Apigee hochgeladen werden können, wenn der Adapter außerhalb eines Apigee Hybrid-Clusters ausgeführt wird, müssen Sie den Parameter analytics-sa mit dem Befehl apigee-remote-service-cli provision verwenden. Darüber hinaus unterstützt der Adapter jetzt Workload Identity in Google Kubernetes Engine (GKE). Siehe Bereitstellungsbefehl.
(Gilt nur für Apigee in Google Cloud und Apigee Hybrid)
Neues jwt_provider_key-Konfigurationsattribut. Dieser Schlüssel wird der Konfigurationsdatei hinzugefügt. Sie steht für den Schlüssel payload_in_metadata des JWT-Anbieters in Envoy Config oder den JWT-Aussteller von RequestAuthentication in der Istio-Konfiguration.
Das Konfigurationsattribut KeepAliveMaxConnectionAge hat jetzt standardmäßig den Wert 1 Minute. Die vorherige Standardeinstellung betrug 10 Minuten. Diese Änderung ermöglicht eine reibungslosere Skalierung. Dieser Wert wird auch für die Lebensdauer des Zugriffslogstreams verwendet. Siehe Konfigurationsdatei.
Entfernte Befehlszeilenbefehle. Die folgenden Befehle der Befehlszeile wurden eingestellt. Wir empfehlen, für die Aktualisierung von Remotedienstzielen für API-Produkte stattdessen die Apigee APIs zu verwenden:
  • apigee-remote-service-cli bindings add
  • apigee-remote-service-cli bindings remove
Neuen Befehlszeilenbefehl hinzugefügt. Der Befehl bewirkt Folgendes: 

apigee-remote-service-cli samples templates

Listet die verfügbaren Optionen auf, die Sie mit dem Flag --template im Befehl samples create verwenden können. Siehe Referenz zur Befehlszeile.
Vorhandener Befehl der Befehlszeile wurde geändert. An dem Befehl apigee-remote-service-cli samples create wurde eine Änderung vorgenommen. Flags, die sich auf Envoy- oder Istio-Vorlagen beziehen, werden streng geprüft und Fehler bei falsch verwendeten Flags zurückgegeben. Die Vorlagenoption native wurde verworfen. Eine Liste der verfügbaren Vorlagen können Sie mit dem Befehl apigee-remote-service-cli samples templates abrufen: Siehe auch Befehlszeilenreferenz.
Die Endpunktantwort /token entspricht nun der OAuth2-Spezifikation. Der Parameter access_token wurde zur Antwort hinzugefügt und der Parameter token wurde verworfen.

v1.2.0

Am Mittwoch, dem 30. September 2020, wurde Version 1.2.0 von Apigee Adapter for Envoy veröffentlicht.

Unterstützte Plattformen

Wir veröffentlichen Binärprogramme für MacOS, Linux und Windows.

Wir veröffentlichen Docker-Images von Ubuntu und Ubuntu mit Boring Crypto sowie Distroless-Images von Google.

In dieser Version werden die folgenden Plattformen unterstützt:

  • Apigee hybrid-Version 1.3.x
  • Istio-Versionen 1.5, 1.6, 1.7
  • Envoy-Versionen 1.14, 1.15

Funktionen und Verbesserungen

Feature Beschreibung
Unterstützung für Apigee in Google Cloud Sie können jetzt Apigee Adapter for Envoy mit Apigee in Google Cloud verwenden. Sie können den Adapter in einem eigenen Cluster ausführen oder den Remote Service for Envoy als natives Binärprogramm oder in einem Container ausführen. Stellen Sie den Adapter in Apigee mit dem Bereitstellungsbefehl bereit.
Direktes Hochladen von Analysedaten Sie können den Apigee-Adapter jetzt so konfigurieren, dass Analysedaten direkt in Apigee hochgeladen werden. Wenn Sie Apigee hybrid verwenden, können Sie mit diesem neuen Feature den Adapter auf einem eigenen Kubernetes-Cluster außerhalb des Clusters bereitstellen, in dem Apigee hybrid installiert ist. Wenn Sie das direkte Hochladen aktivieren möchten, verwenden Sie das neue Flag --analytics-sa mit dem Befehl provision. Siehe Bereitstellungsbefehl.
Die Systemdiagnose gibt „Bereit“ zurück, nachdem API-Produktdaten aus Apigee geladen wurden. Die Kubernetes-Systemdiagnose gibt erst dann „Bereit“ zurück, wenn die API-Produktdaten aus Apigee geladen wurden. Diese Änderung hilft bei der Skalierung und Aktualisierung, da Traffic erst an den neu instanziierten Adapter gesendet wird, wenn er einsatzbereit ist.

Sonstige Probleme und Korrekturen

  • Ein Problem bezüglich eines potenziellen Deadlocks der Kontingentsynchronisierung wurde behoben (Problem Nr. 17).
  • Prometheus-Annotationen wurden in die Pod-Spezifikation verschoben (Problem Nr. 69).
  • Ein Problem wurde behoben, durch das fehlerhafte Fehler zur Überprüfung abgelehnt wurden (Problem Nr. 62).

v1.1.0

Am Mittwoch, dem 26. August 2020, wurde Version 1.1.0 von Apigee Adapter für Envoy veröffentlicht.

Unterstützte Plattformen

Wir veröffentlichen Binärprogramme für MacOS, Linux und Windows.

Wir veröffentlichen Docker-Images von Ubuntu und Ubuntu mit Boring Crypto sowie Distroless-Images von Google.

In Version 1.1.0 werden folgende Plattformen unterstützt:

  • Apigee Hybrid-Version 1.3
  • Istio-Versionen 1.5, 1.6, 1.7
  • Envoy-Versionen 1.14, 1.15

Funktionen und Verbesserungen

Feature Beschreibung
Bindungen überprüfen Der Befehlszeile wurde der neue Befehl apigee-remote-service-cli bindings verify hinzugefügt. Dieser Befehl prüft, ob das angegebene gebundene API-Produkt und die zugehörigen Entwickleranwendungen auch mit einem Remote-Dienstprodukt verknüpft sind. Siehe Bindung prüfen.
Stichproben generieren Der Befehlszeile wurde der neue Befehl apigee-remote-service-cli samples create hinzugefügt. Mit diesem Befehl werden Beispielkonfigurationsdateien für native Envoy- oder Istio-Bereitstellungen erstellt. Die Konfigurationsdateien, die mit diesem Befehl generiert werden, ersetzen die Beispieldateien, die mit Adapter for Envoy in früheren Versionen installiert wurden. Siehe Beispielbefehl.
Authentifizierung mit OAuth2 Der Adapter verwendet jetzt die OAuth2-Authentifizierung, wenn die Multi-Faktor-Authentifizierung (MFA) für Apigee aktiviert ist. Verwenden Sie das Flag --mfa, wenn Sie das Flag --legacy verwenden.
Distroless-Container Der Adapter verwendet jetzt das Distroless-Image von Google (gcr.io/distroless/base) anstelle von scratch für die standardmäßige Docker-Image-Basis.

Sonstige Probleme und Korrekturen

  • Ein Befehlszeilenproblem wurde für Bindungsbefehle in OPDK behoben. (#29)
  • Das Kontingent könnte hängen bleiben, wenn die Verbindung verloren geht (apigee/apigee-remote-service-envoy). (#31)
  • Docker-Images werden jetzt von einem Nicht-Root-Nutzer (999) erstellt.
  • In Kubernetes-Beispielen wird erzwungen, dass der Nutzer nicht Rootberechtigungen hat.
  • --http1.1 wird für curl-Befehle für Proxy-Endpunkte nicht mehr benötigt. Das Flag wurde aus den Beispielen entfernt.

v1.0.0

Am Freitag, dem 31. Juli 2020, wurde die GA-Version von Apigee Adapter für Envoy veröffentlicht.

Unterstützte Plattformen

Wir veröffentlichen Binärprogramme für MacOS, Linux und Windows.

Wir veröffentlichen Docker-Images von Ubuntu und Ubuntu mit Boring Crypto sowie Scratch-Images.

In Version 1.0.0 werden folgende Plattformen unterstützt:

  • Apigee Hybrid-Version 1.3
  • Istio-Versionen 1.5, 1.6
  • Envoy-Versionen 1.14, 1.15

Hinzufügungen und Änderungen

Zwischen Version v1.0-beta4 und GA wurden die folgenden Ergänzungen Änderungen am Adapter vorgenommen:

  • Go Boring Builds

    Ein neuer Build ist jetzt verfügbar, der verwendet FIPS-konformen Go BoringSSL-Bibliotheken.

  • Änderungen an den Flags auf Logebene

    Die Flags auf Logging-Ebene für den Dienst apigee-remote-service-envoy wurden aus Konsistenzgründen geändert:

    Altes Flag Neues Flag
    log_level log-level
    json_log json-log
  • Neue Befehlszeilen-Flags

    Den Befehlszeilen-token-Befehlen wurden neue Flags hinzugefügt:

    Flag Beschreibung
    --legacy Legen Sie dieses Flag fest, wenn Sie Apigee Cloud verwenden.
    --opdk Legen Sie dieses Flag fest, wenn Sie Apigee for Private Cloud verwenden.