Versionshinweise zu Apigee-Adapter for Envoy

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

v2.1.1

Am 7. Juni 2023 haben wir Version 2.1.1 des Apigee-Adapters für Envoy veröffentlicht.

Behobene Probleme

  • Ein Problem wurde behoben, durch das Kontingente zwischen Vorgängen falsch dupliziert wurden. anstatt auf Produktebene freigegeben zu werden.

v2.1.0

Am 5. Juni 2023 haben wir Version 2.1.0 des Apigee-Adapters für Envoy veröffentlicht.

Behobene Probleme

  • Der Anspruch application_id wurde der /verifyApiKey-Antwort hinzugefügt.

v2.0.7

Am 9. März 2023 haben wir Version 2.0.7 des Apigee-Adapters für Envoy veröffentlicht.

Funktionen und Verbesserungen

  • JWTs können jetzt eine Anforderung mit dem Namen customattributes hinzufügen, die den Wert übergibt. in einem Header namens x-apigee-customattributes (wenn append_metadata_headers ist als true konfiguriert.

Behobene Probleme

  • Ein Problem wurde behoben, durch das ein ungültiger API-Schlüssel falsche Logeinträge und Analysen erstellen konnte Datensätze.
  • In einem Proxy wurde eine veraltete Versionsprüfung entfernt, die Probleme in neueren Versionen von verursacht hat. Apigee

v2.0.6

Am 18. Oktober 2022 haben wir Version 2.0.6 des Apigee-Adapters für Envoy veröffentlicht.

Behobene Probleme

  • Sicherheitsrelease zur Behebung einer DoS-Sicherheitslücke (Denial of Service) in einer Abhängigkeitsbibliothek. Siehe CVE-2022-28948.

v2.0.5

Am 3. März 2022 haben wir Version 2.0.5 des Apigee-Adapters für Envoy veröffentlicht.

Behobene Probleme

  • Sicherheitsrelease zur Behebung eines DoS-Risikos (Denial of Service) in der Prometheus-Bibliothek. Siehe CVE-2022-21698.

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

Nur für Apigee X und Apigee Hybrid verfügbar.

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.
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 an ein Remote-Dienstziel

Die Semantik des Konfigurationsattributs api_header bleibt erhalten entspricht der vorherigen target_header-Property (Standardeinstellung ist immer noch die Ziel-Hostname) und der Inhalt des angegebenen Headers entweder mit dem Attribut Remote-Dienstziel des API-Produkts oder Feld apiSource in einer API-Produktbetrieb (nur Apigee Hybrid und Apigee X).

Zum Überschreiben dieses Headerwerts mit Envoy-Metadaten können Sie den apigee_api übergeben Metadatenelement von Envoy an den Adapter senden, um den Parameter Das Remote-Dienstziel des API-Produkts oder die API-Quelle des API-Produktvorgangs. 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. Das ist mehr effizient und erfordert, dass keine Metadaten an die Anfrage angehängt werden.
Unterstützung für UDCA wurde entfernt

Das Streaming in den Universal Data Collection Agent (UDCA) von Apigee in Apigee hybrid und Apigee X 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.

Behobene Probleme

  • 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 Edge for Public Cloud, Apigee Edge 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, wurde die Version 1.3.0 des Apigee-Adapters 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 dieser Version werden die folgenden Plattformen unterstützt:

  • Apigee hybrid-Version 1.3.x, 1.4.x (Veröffentlichungsdatum ausstehend), Apigee Edge for Public Cloud, Apigee Edge 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.
(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 HOST-Header einfügen, wenn der Hostname vom Zielhost des Remote-Dienstes unterscheidet, der im API-Produkt festgelegt ist. Für 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 die Verwendung des Edge-APIs verwendet, um Remote-Dienstziele für API-Produkte zu aktualisieren: <ph type="x-smartling-placeholder">
    </ph>
  • apigee-remote-service-cli bindings add
  • apigee-remote-service-cli bindings remove
Neuen Befehlszeilenbefehl hinzugefügt. Der Befehl: 
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, 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, wurde Version 1.1.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 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 Edge aktiviert. 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, wurde die GA-Version 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 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 die Apigee Edge Cloud verwenden.
    --opdk Legen Sie dieses Flag fest, wenn Sie Apigee Edge für Private Cloud verwenden.