Note di rilascio di Apigee Adapter for Envoy

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Questa pagina contiene le note di rilascio di tutto il software Apigee Adapter for Envoy per il 2021 e le versioni precedenti.

Consulta Adapter for Envoy per le note di rilascio attuali (2022 e versioni successive).

v2.0.4

Il 3 dicembre 2021 abbiamo rilasciato la versione 2.0.4 di Apigee Adapter for Envoy.

Funzionalità e miglioramenti

  • L'elenco delle versioni di Envoy e Istio supportate per il comando samples della CLI è stato aggiornato. Ora queste versioni sono supportate per i sample:
    • Versioni di Envoy da 1.18 a 1.20
    • Versioni di Istio da 1.10 a 1.12

Problemi risolti

  • Per evitare un panico, è stato aggiunto un controllo di nullità per il caricamento della chiave privata del blocco PEM. (Issue #360)
  • Gli errori di autorizzazione del servizio remoto vengono ora registrati a livello di debug. Un'eccezione a questa classificazione è fatta per gli errori di recupero dei token per le chiavi API. In questo caso, gli errori vengono registrati a livello di Errore in modo che siano visibili anche se il livello di log di debug per apigee-remote-service-envoy è disattivato. Consulta anche Impostare i livelli di log del servizio remoto. (Issue #104)

v2.0.3

Il 21 settembre 2021 abbiamo rilasciato la versione 2.0.3 di Apigee Adapter for Envoy.

Problemi risolti

  • È stato risolto un problema di logging di Dati con le risposte dirette. Il problema si è verificato solo in determinate circostanze. Ad esempio:
    • Per le richieste che non richiedono il controllo authn/z, non è stato generato alcun authContext e i metadati dinamici erano nulli, causando l'ignoramento della voce di log di accesso.
    • La risposta di rifiuto ha utilizzato il codice RPC anziché il codice HTTP, causando la visualizzazione dei record come riusciti nell'interfaccia utente di Apigee.

v2.0.2

Il 7 giugno 2021 abbiamo rilasciato la versione 2.0.2 di Apigee Adapter for Envoy.

Problemi risolti

  • È stata corretta una race condition che poteva causare errori 403 e panic quando gli ambiti delle rivendicazioni JWT erano null.

v2.0.1

Martedì 29 aprile 2021 abbiamo rilasciato la versione 2.0.1 di Apigee Adapter for Envoy.

Problemi risolti

Funzionalità Descrizione
Bug

È stato risolto un problema che causava il malfunzionamento della versione 2.0.0 se utilizzata con Apigee hybrid 1.5.0 o Apigee. Se stai eseguendo l'upgrade dell'installazione di Apigee hybrid alla versione 1.5.x, il percorso di upgrade consigliato per l'adattatore è:

  1. Esegui l'upgrade di Apigee Adapter for Envoy alla versione 2.0.1.
  2. Esegui l'upgrade di Apigee hybrid alla versione 1.5.1.

Se utilizzi Apigee, esegui l'upgrade dell'adattatore alla versione 2.0.1.

v2.0.0

Martedì 6 aprile 2021 abbiamo rilasciato la versione 2.0.0 di Apigee Adapter for Envoy.

Funzionalità e miglioramenti

Funzionalità Descrizione
Supporto dell'ambiente multi-tenant

Ora puoi consentire all'adattatore di gestire più ambienti in un'organizzazione Apigee. Questa funzionalità ti consente di utilizzare un Apigee Adapter for Envoy associato a un'organizzazione Apigee per gestire più ambienti. Prima di questa modifica, un'adattatore era sempre associato a un ambiente Apigee. Per ulteriori informazioni su questa funzionalità, consulta la pagina Supporto dell'ambiente multi-tenant.
Supporto dell'API Envoy v3
Supporto dei metadati di Envoy

Envoy 1.16 e versioni successive consente di inviare metadati ext_authz senza dover utilizzare intestazioni. Utilizzando questa modifica e altre correlate, ora forniamo codici di risposta HTTP migliori per le richieste denied e non è più necessario installare un filtro RBAC in Envoy. Consulta

Questa funzionalità è supportata solo per Envoy 1.16 e versioni successive e Istio 1.9 e versioni successive.

Con questa modifica, la seguente configurazione non viene più aggiunta al file di configurazione di 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

Se vuoi aggiungere intestazioni alle richieste per un caso speciale, imposta la proprietà append_metadata_headers:true nel file config.yaml dell'adattatore.
Separare il proxy remote-token dal proxy remote-service

Il proxy remote-service è stato sottoposto a refactoring in due proxy distinti. Il provisioning della versione 2.0.x installerà due proxy API: remote-service e remote-token. Gli endpoint /token e /certs sono stati spostati dal proxy remote-service a remote-token.

Questa modifica crea una separazione utile delle funzioni. Ora il proxy remote-service viene utilizzato solo per le comunicazioni interne dell'adattatore, mentre il proxy remote-token fornisce un flusso di lavoro OAuth di esempio che puoi personalizzare. Non eseguiremo mai la sovrascrittura del proxy remote-token personalizzato, anche se viene utilizzato il comando provision --force-proxy-install.

Assistenza per l'acquisizione dei dati

Ora l'adattatore supporta il passaggio dei metadati di Envoy alla funzionalità di acquisizione dei dati di Apigee, che invia i dati acquisiti nelle variabili specificate ad Apigee Analytics per l'utilizzo nei report personalizzati. Questa funzionalità offre una funzionalità simile al criterio di acquisizione dei dati di Apigee. Per ulteriori informazioni su questa funzionalità, consulta Acquisizione dei dati per i report personalizzati.

RBAC non obbligatorio

Come indicato in precedenza nella sezione Supporto dei metadati di Envoy, ora respingiamo immediatamente le richieste non autorizzate senza richiedere un filtro RBAC separato. Poiché l'RBAC non viene utilizzato, i client ora riceveranno questi codici di stato HTTP dall'adattatore come appropriato:

  • 401 Non autorizzato
  • 403 Forbidden
  • 429 Too Many Requests
  • 500 - Errore interno del server

Se vuoi consentire la continuazione delle richieste non autorizzate, puoi farlo impostando auth:allow_unauthorized:true nel file config.yaml dell'adattatore.

Le intestazioni x-apigee-* non vengono più aggiunte per impostazione predefinita

Come indicato in precedenza nella sezione Supporto dei metadati di Envoy, le intestazioni x-apigee-* non vengono più aggiunte per impostazione predefinita. Se vuoi aggiungerli, imposta append_metadata_headers:true nel file config.yaml. Questa configurazione è completamente facoltativa e deve essere utilizzata solo quando è opportuno inoltrare le intestazioni al servizio di destinazione a monte.

Corrispondenza personalizzata di una richiesta a un'operazione di prodotto API Apigee

La semantica della proprietà di configurazione api_header rimane immutata rispetto alla precedente proprietà target_header (il valore predefinito è ancora il nome dell'host di destinazione) e i contenuti dell'intestazione specificata corrisponderanno comunque all'attributo Destinazione servizio remoto del prodotto API o al campo Origine in una configurazione delle operazioni del prodotto API.

Per eseguire l'override di questo valore dell'intestazione utilizzando i metadati di Envoy, puoi passare l'elemento di metadati apigee_api da Envoy all'adattatore per specificare direttamente il Target del servizio remoto del prodotto API o l'origine API dell'operazione del prodotto API. Per la configurazione, aggiungi codice simile al seguente al file di configurazione di Envoy (che puoi generare utilizzando l'interfaccia a riga di comando dell'adattatore): 

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
Gli analytics per le richieste rifiutate vengono registrati immediatamente

Ora l'adattatore Envoy registrerà immediatamente le richieste rifiutate in Analytics come richiesto, anziché attendere che la richiesta venga restituita nel log di accesso. Questo metodo è più efficiente e non richiede l'aggiunta di metadati alla richiesta.
Il supporto UDCA è stato rimosso

Lo streaming verso l'Universal Data Collection Agent (UDCA) di Apigee in Apigee Hybrid e Apigee non è più necessario per le analisi, in quanto è stato sostituito dal caricamento diretto. Questa modifica rimuove semplicemente il supporto precedente per questa opzione.

È stato aggiunto il supporto di mTLS per Edge for Private Cloud nei comandi CLI di provision/bindings

Gli utenti di Apigee Edge per Private Cloud possono fornire i certificati TLS lato client e il certificato principale tramite ‑‑tls‑cert, ‑‑tls‑key e ‑‑tls‑ca rispettivamente durante il provisioning o l'elenco delle associazioni dei prodotti utilizzando la CLI.

Supporto di mTLS tra l'adattatore e il runtime Apigee

Puoi fornire certificati TLS lato client nella sezione tenant del file config.yaml dell'adattatore per utilizzare mTLS tra l'adattatore e il runtime Apigee. Questa modifica si applica a tutte le piattaforme Apigee supportate. Inoltre, abilita mTLS per le analisi per la piattaforma Apigee Edge for Private Cloud. Per ulteriori informazioni, consulta Configurare mTLS tra l'adattatore e il runtime Apigee.

Altri problemi e correzioni

  • È stato risolto un problema per cui più configurazioni di operazioni con la stessa origine API condividevano gli stessi identificatori dei bucket delle quote e causavano conflitti nel calcolo delle quote. (Problema #34)
  • È stato risolto un problema per cui le operazioni senza verbi specificati causavano il rifiuto della richiesta (il comportamento previsto è consentire tutti i verbi se non ne viene specificato nessuno). (Problema #39)

v1.4.0

Mercoledì 16 dicembre 2020 abbiamo rilasciato la versione 1.4.0 di Apigee Adapter for Envoy.

Piattaforme supportate

Pubblichiamo i binari per MacOS, Linux e Windows.

Pubblichiamo immagini Docker da distroless, Ubuntu e Ubuntu con Boring Crypto di Google.

In questa versione supportiamo le seguenti piattaforme:

  • Apigee hybrid versione 1.3.x, 1.4.x (data di rilascio in attesa), Apigee per il cloud pubblico, Apigee per il cloud privato e Apigee su Google Cloud
  • Versioni di Istio 1.5, 1.6, 1.7, 1.8
  • Versioni di Envoy 1.14, 1.15, 1.16

Funzionalità e miglioramenti

Funzionalità Descrizione
Il proxy remote-service non richiede più l'associazione con un prodotto API che utilizza i target di servizio remoto.

Poiché questa associazione non è più obbligatoria, tieni presente le seguenti modifiche:

  • Durante il provisioning non viene più creato un prodotto API remote-service.
  • Il comando bindings verify della CLI non è più pertinente ed è stato ritirato.
Il ruolo Amministratore dell'organizzazione Apigee non è più necessario per il provisioning.

Anziché richiedere l'autorizzazione di amministratore dell'organizzazione per il provisioning, ora puoi utilizzare i ruoli IAM Creator e Deployer dell'API. Per eseguire correttamente il provisioning, devi concedere entrambi i ruoli.
(si applica solo ad Apigee su Google Cloud e ad Apigee hybrid)

Altri problemi e correzioni

  • È stato risolto un problema per cui il provisioning di Apigee senza l'opzione --rotate terminava con un errore.
  • La CLI di provisioning ora legge e riutilizza le credenziali dell'account di servizio di analisi da un determinato file config.yaml (Issue #133).

v1.3.0

Lunedì 23 novembre 2020 abbiamo rilasciato la versione 1.3.0 di Apigee Adapter for Envoy.

Piattaforme supportate

Pubblichiamo i binari per MacOS, Linux e Windows.

Pubblichiamo immagini Docker da distroless, Ubuntu e Ubuntu con Boring Crypto di Google.

In questa versione supportiamo le seguenti piattaforme:

  • Apigee hybrid versione 1.3.x, 1.4.x (data di rilascio in attesa), Apigee per il cloud pubblico, Apigee per il cloud privato e Apigee su Google Cloud
  • Versioni di Istio 1.5, 1.6, 1.7, 1.8
  • Versioni di Envoy 1.14, 1.15, 1.16

Funzionalità e miglioramenti

Funzionalità Descrizione
Supporto per OperationGroups dei prodotti API. OperationGroups lega le risorse e l'applicazione delle quote associate in un proxy o un servizio remoto con metodi HTTP. Per maggiori dettagli, consulta OperationGroup.
(si applica solo ad Apigee su Google Cloud e ad Apigee hybrid)
Rimuovi il supporto del proxy inoltrante dinamico dalla generazione di sample. A causa di questa modifica, i client devono includere l'intestazione HOST se il nome host è diverso dall'host di destinazione del servizio remoto impostato nel prodotto API. Ad esempio: 
curl -i http://localhost:8080/httpbin/headers -H "HOST:httpbin.org"

Consulta Creare un prodotto API.

Supporta gli account di servizio e Workload Identity. Per consentire il caricamento dei dati di analisi su Apigee quando esegui l'adattatore al di fuori di un cluster ibrido Apigee, devi utilizzare il parametro analytics-sa con il comando apigee-remote-service-cli provision. Inoltre, ora l'adattatore supporta Workload Identity su Google Kubernetes Engine (GKE). Vedi Comando di provisioning.
(si applica solo ad Apigee su Google Cloud e ad Apigee hybrid)
Nuovo attributo di configurazione jwt_provider_key. Questa chiave viene aggiunta al file di configurazione. Rappresenta la chiave payload_in_metadata del provider JWT in configurazione di Envoy o l'emittente JWT RequestAuthentication nella configurazione di Istio.
L'attributo di configurazione KeepAliveMaxConnectionAge ora è impostato per impostazione predefinita su 1 minuto. Il valore predefinito precedente era 10 minuti. Questa modifica consente una scalabilità più fluida. Questo valore viene utilizzato anche per la durata dello stream del log di accesso. Vedi file di configurazione.
Comandi dell'interfaccia a riga di comando rimossi. I seguenti comandi dell'interfaccia a riga di comando sono stati ritirati. Ti consigliamo di utilizzare le API Apigee per aggiornare i target di servizio remoto per i prodotti API:
  • apigee-remote-service-cli bindings add
  • apigee-remote-service-cli bindings remove
È stato aggiunto un nuovo comando CLI. Il comando: 
apigee-remote-service-cli samples templates

elenca le opzioni disponibili che puoi utilizzare con il flag --template nel comando samples create. Consulta il riferimento all'interfaccia a riga di comando.
È stato modificato il comando CLI esistente. È stata apportata una modifica al comando apigee-remote-service-cli samples create. I flag specifici per i modelli Envoy o Istio vengono controllati rigorosamente e vengono restituiti errori per i flag utilizzati in modo errato. L'opzione di modello native è deprecata. Per ottenere un elenco dei modelli disponibili, utilizza il comando apigee-remote-service-cli samples templates. Consulta anche il riferimento all'interfaccia a riga di comando.
La risposta dell'endpoint /token ora segue la specifica OAuth2. Il parametro access_token è stato aggiunto alla risposta e il parametro token è stato ritirato.

v1.2.0

Mercoledì 30 settembre 2020 abbiamo rilasciato la versione 1.2.0 di Apigee Adapter for Envoy.

Piattaforme supportate

Pubblichiamo i binari per MacOS, Linux e Windows.

Pubblichiamo immagini Docker da distroless, Ubuntu e Ubuntu con Boring Crypto di Google.

In questa versione supportiamo le seguenti piattaforme:

  • Apigee hybrid versione 1.3.x
  • Versioni di Istio 1.5, 1.6, 1.7
  • Versioni di Envoy 1.14, 1.15

Funzionalità e miglioramenti

Funzionalità Descrizione
Assistenza per Apigee su Google Cloud Ora puoi utilizzare Apigee Adapter for Envoy con Apigee su Google Cloud. Puoi eseguire l'adattatore nel suo cluster o eseguendo il servizio remoto per Envoy come file binario nativo o in un contenitore. Esegui il provisioning dell'adattatore su Apigee utilizzando il comando provision.
Caricamento diretto per i dati di analisi Ora puoi configurare l'Apigee Adapter per caricare i dati di analisi direttamente in Apigee. Se utilizzi Apigee hybrid, questa nuova funzionalità consente di eseguire il deployment dell'adattatore nel proprio cluster Kubernetes, al di fuori del cluster in cui è installato Apigee hybrid. Per attivare il caricamento diretto, utilizza il nuovo --analytics-sa flag con il comando provision. Vedi comando di provisioning.
Il controllo dell'integrità restituisce "Pronto" dopo il caricamento dei dati di prodotto dell'API da Apigee Il controllo di integrità di Kubernetes non restituirà "Pronto" finché i dati di prodotto dell'API non vengono caricati da Apigee. Questa modifica è utile per il ridimensionamento e l'upgrade, perché nessun traffico verrà inviato all'adattatore appena creato finché non sarà pronto.

Altri problemi e correzioni

  • È stato risolto un problema relativo a un potenziale deadlock della sincronizzazione delle quote (Issue #17).
  • Le annotazioni di Prometheus sono state spostate nella specifica del pod (Issue #69).
  • È stato risolto un problema relativo agli errori di verifica emessi in modo improprio (Issue #62).

v1.1.0

Mercoledì 26 agosto 2020 abbiamo rilasciato la versione 1.1.0 di Apigee Adapter for Envoy.

Piattaforme supportate

Pubblichiamo i binari per MacOS, Linux e Windows.

Pubblichiamo immagini Docker da distroless, Ubuntu e Ubuntu con Boring Crypto di Google.

Nella versione 1.1.0 supportiamo le seguenti piattaforme:

  • Versione 1.3 di Apigee hybrid
  • Versioni di Istio 1.5, 1.6, 1.7
  • Versioni di Envoy 1.14, 1.15

Funzionalità e miglioramenti

Funzionalità Descrizione
Verificare le associazioni È stato aggiunto un nuovo comando apigee-remote-service-cli bindings verify alla CLI. Questo comando verifica che al prodotto API associato e alle sue app per sviluppatori associate sia associato anche un prodotto di servizio remoto. Consulta Verificare una associazione.
Genera campioni È stato aggiunto un nuovo comando apigee-remote-service-cli samples create alla CLI. Questo comando crea file di configurazione di esempio per i deployment di Envoy o Istio nativi. I file di configurazione generati con questo comando sostituiscono i file di esempio installati con l'adattatore per Envoy nelle versioni precedenti. Vedi Comando Samples.
Autenticazione OAuth2 Ora l'adattatore utilizza l'autenticazione OAuth2 quando l'autenticazione a più fattori (MFA) è attivata per Apigee. Utilizza il flag --mfa ogni volta che utilizzi il --legacy.
Contenitore Distroless Ora l'adattatore utilizza l'immagine distroless (gcr.io/distroless/base) di Google anziché scratch come base dell'immagine Docker predefinita.

Altri problemi e correzioni

  • È stato risolto un problema relativo alla CLI per i comandi di binding in OPDK. (#29)
  • La quota potrebbe bloccarsi in caso di perdita di connessione (apigee/apigee-remote-service-envoy. (#31)
  • Le immagini Docker vengono ora create con un utente non root (999).
  • I campioni Kubernetes richiedono che l'utente non sia root.
  • --http1.1 non è più necessario per i comandi curl contro gli endpoint proxy. L'indicatore è stato rimosso dagli esempi.

v1.0.0

Venerdì 31 luglio 2020 abbiamo rilasciato la versione GA di Apigee Adapter for Envoy.

Piattaforme supportate

Pubblichiamo i binari per MacOS, Linux e Windows.

Pubblichiamo immagini Docker da zero, Ubuntu e Ubuntu con Boring Crypto.

Nella versione 1.0.0 supportiamo le seguenti piattaforme:

  • Versione 1.3 di Apigee hybrid
  • Versioni Istio 1.5, 1.6
  • Versioni di Envoy 1.14, 1.15

Aggiunte e modifiche

Tra la versione 1.0-beta4 e la versione GA, sono state apportate le seguenti modifiche all'adattatore:

  • Esegui build noiose

    Ora è disponibile una nuova build che utilizza librerie Go BoringSSL conformi a FIPS.

  • Modifiche ai flag del livello di log

    I flag di livello di logging per il servizio apigee-remote-service-envoy sono stati modificati per motivi di coerenza:

    Bandiera vecchia Nuovo flag
    log_level log-level
    json_log json-log
  • Nuovi flag della CLI

    Sono stati aggiunti nuovi flag ai comandi token della CLI:

    Bandiera Descrizione
    --legacy Imposta questo flag se utilizzi Apigee Cloud.
    --opdk Imposta questo flag se utilizzi Apigee per il cloud privato.