Note di rilascio di Apigee Adapter per Envoy

Questa pagina si applica a Apigee e Apigee ibridi.

Visualizza documentazione di Apigee Edge.

Questa pagina documenta le note di rilascio per tutti i software Apigee Adapter for Envoy per il 2021 e precedenti.

Vedi Alimentatore per Envoy per le note di rilascio attuali (2022 e successive).

v2.0.4

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

Funzionalità e miglioramenti

  • L'elenco di versioni Envoy e Istio supportate per il comando samples dell'interfaccia a riga di comando è stato aggiornato. Queste versioni sono ora supportate per gli esempi:
    • Versioni di Envoy da 1.18 a 1.20
    • Versioni di Istio dalla 1.10 alla 1.12

Problemi risolti

  • Per evitare il panico, è stato aggiunto un controllo null per il caricamento della chiave privata del blocco PEM. (Numero 360)
  • Gli errori di autorizzazione del servizio remoto vengono ora registrati a livello di debug. Un'eccezione a questa categorizzazione per gli errori di recupero dei token per le chiavi API. In questo caso, gli errori vengono registrati nel campo in modo che siano visibili anche se il livello di log di debug per apigee-remote-service-envoy è disattivato. Vedi anche Impostazione dei livelli di log di servizio remoto. (Numero 104)

v2.0.3

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

Problemi risolti

  • È stato risolto un problema di logging delle analisi con le risposte dirette. Il problema si è verificato solo in determinate circostanze. Ad esempio:
    • Per le richieste che non richiedono il controllo auth/z, non è stato generato alcun authContext. i metadati dinamici erano nulli, di conseguenza la voce di log di accesso è stata ignorata.
    • La risposta negata ha utilizzato codice RPC anziché codice HTTP, causando la ricezione dei record indicato nella UI di Apigee come operazione completata.

v2.0.2

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

Problemi risolti

  • È stata corretta una race condition che poteva causare errori 403 e problemi di panico quando gli ambiti delle richieste JWT venivano zero.

v2.0.1

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

Problemi risolti

Funzionalità Descrizione
Insetto

È stato risolto un problema che causava il malfunzionamento della versione v2.0.0 quando veniva utilizzata con Apigee hybrid v1.5.0 o Apigee. Se stai eseguendo l'upgrade dell'installazione ibrida di Apigee alla versione 1.5.x, il percorso di upgrade consigliato per l'adattatore è:

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

Se utilizzi Apigee, è sufficiente eseguire 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 per Envoy.

Funzionalità e miglioramenti

Funzionalità Descrizione
Supporto dell'ambiente multi-tenant

Ora puoi abilitare l'adattatore per il servizio di più in un'organizzazione Apigee. Questa funzionalità ti consente di usare Adattatore per Envoy associato a un'organizzazione Apigee per gestire più ambienti. Prima del giorno questa modifica, un adattatore era sempre legato a un ambiente Apigee. Per ulteriori informazioni su questa funzione, vedi Supporto dell'ambiente multi-tenant.
Supporto per l'API Envoy v3
Supporto dei metadati di Envoy

Envoy 1.16 e versioni successive consente inviare metadati a ext_authz senza dover utilizzare le intestazioni. Utilizzando questa e le relative modifiche, ora forniamo codici di risposta HTTP migliori per le richieste 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 a Envoy di configurazione del deployment (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.
Suddividi il proxy remote-token dal proxy remote-service

Il proxy remote-service è stato sottoposto a refactoring in due proxy separati. La versione v2.0.x, provisioning installerà due proxy API: remote-service e remote-token. /token e /certs endpoint sono stati spostati dal proxy remote-service a remote-token.

Questa modifica crea un'utile separazione tra le funzioni. Ora, il servizio remoto il proxy viene utilizzato solo per comunicazioni interne con l'adattatore, mentre il token-remote fornisce un flusso di lavoro OAuth di esempio che puoi personalizzare. Non faremo mai sovrascrivere il proxy remote-token personalizzato, anche se viene utilizzato il comando provision --force-proxy-install.

Supporto dell'acquisizione dei dati

L'adattatore ora supporta il passaggio di metadati Envoy alla funzionalità di acquisizione dati di Apigee, invia i dati acquisiti nelle variabili da te specificate ad analisi di Apigee per utilizzarli nei report personalizzati. Questa funzionalità offre una funzionalità simile ad Apigee Norme di acquisizione dei dati. Per ulteriori informazioni su questa funzione, vedi Acquisizione dei dati per i report personalizzati.

RBAC non richiesto

Come già detto in Supporto per i metadati Envoy, ora rifiutare le richieste non autorizzate senza richiedere un filtro RBAC separato. Poiché RBAC non viene utilizzato. I client riceveranno questi codici di stato HTTP come appropriato da l'adattatore:

  • 401 Non autorizzato
  • 403 Accesso negato
  • 429 Troppe richieste
  • 500 Errore interno del server

Se vuoi consentire il proseguimento 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 già detto nella sezione Supporto per i 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 facoltativo e dovrebbe essere utilizzato solo quando opportuno al servizio di destinazione upstream.

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

La semantica della proprietà di configurazione api_header rimane uguale alla precedente proprietà target_header (l'impostazione predefinita è sempre nome host di destinazione) e i contenuti dell'intestazione specificata corrisponderanno comunque a Attributo Target servizio remoto o campo Origine del prodotto API in una Configurazione di Operazioni prodotto API.

Per eseguire l'override di questo valore di intestazione utilizzando i metadati Envoy, puoi trasmettere apigee_api l'elemento di metadati da Envoy all'adattatore per specificare direttamente Destinazione del servizio remoto o Origine API del funzionamento del prodotto API. Per eseguire la configurazione, aggiungi al file di configurazione Envoy un codice simile al seguente (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
Le analisi relative alle richieste rifiutate vengono registrate immediatamente

Envoy Adapter ora registra immediatamente le richieste rifiutate nei dati di analisi anziché attendere che la richiesta venga restituita nel log degli accessi. Questo è altro efficiente e non richiede l'aggiunta di metadati alla richiesta.
Il supporto di UDCA è stato rimosso

Il flusso di dati nell'agente di raccolta dati universale (UDCA) di Apigee in Apigee hybrid e Apigee non è più necessario per l'analisi è stato sostituito dal caricamento diretto. Questa modifica rimuove semplicemente il supporto precedente per questa opzione.

Supporto di mTLS aggiunto per Edge per il cloud privato nei comandi dell'interfaccia a riga di comando di provisioning/bindings

Gli utenti di Apigee Edge per il cloud privato possono fornire certificati TLS lato client e certificato radice tramite ‑‑tls‑cert, rispettivamente ‑‑tls‑key e ‑‑tls‑ca quando esegui il provisioning o la scheda delle associazioni di prodotti utilizzando nell'interfaccia a riga di comando.

Supporto mTLS tra l'adattatore e il runtime Apigee

Puoi fornire certificati TLS lato client nella sezione tenant della config.yaml dell'adattatore per utilizzare mTLS tra l'adattatore e il runtime Apigee. Questo si applica a tutte le piattaforme Apigee supportate. Abilita anche mTLS per l'analisi per la piattaforma Apigee Edge per il cloud privato. Per ulteriori informazioni, vedi Configurazione di mTLS tra l'adattatore e il runtime Apigee.

Altri problemi e correzioni

  • È stato risolto un problema per cui più configurazioni delle operazioni con la stessa origine API venivano condivise gli stessi identificatori di bucket di quota e causato conflitti nel calcolo delle quote. (Numero 34)
  • È stato risolto un problema per cui operazioni senza verbi specificati causavano l'invio della richiesta negata (il comportamento previsto è consentire tutti i verbi se non ne viene specificato nessuno). (Numero 39)

v1.4.0

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

Piattaforme supportate

Pubblichiamo programmi binari per MacOS, Linux e Windows.

Pubblichiamo immagini Docker da Ubuntu e Ubuntu senza distro di Google con Boring Crypto.

In questa versione sono supportate le seguenti piattaforme:

  • Apigee versione ibrida 1.3.x, 1.4.x (data di rilascio in sospeso), Apigee per il cloud pubblico, Apigee per il Private Cloud e Apigee su Google Cloud
  • Istio versioni 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 usa target di servizio remoti.

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

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

Anziché richiedere l'autorizzazione dell'amministratore dell'organizzazione per il provisioning, ora puoi utilizzare i ruoli IAM Creatore API e Deployer. Devi concedere entrambi questi ruoli per eseguire correttamente il provisioning.
(Solo per Apigee su Google Cloud e Apigee hybrid)

Altri problemi e correzioni

  • È stato risolto un problema relativo al nuovo provisioning di Apigee senza l'opzione --rotate è uscito con un errore.
  • L'interfaccia a riga di comando di provisioning ora legge e riutilizza le credenziali dell'account di servizio di analisi da un determinato file config.yaml (Numero 133).

v1.3.0

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

Piattaforme supportate

Pubblichiamo programmi binari per MacOS, Linux e Windows.

Pubblichiamo immagini Docker da Ubuntu e Ubuntu senza distro di Google con Boring Crypto.

In questa versione sono supportate le seguenti piattaforme:

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

Funzionalità e miglioramenti

Funzionalità Descrizione
Supporto per il prodotto API OperationGroups. OperationGroups vincola le risorse e l'applicazione della quota associata in un proxy servizio remoto con metodi HTTP. Per maggiori dettagli, vedi OperationGroup:
(Solo per Apigee su Google Cloud e Apigee hybrid)
Rimuovi il supporto per il proxy di inoltro dinamico dalla generazione di campioni. 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. Per esempio: 
curl -i http://localhost:8080/httpbin/headers -H "HOST:httpbin.org"

Consulta Creare un prodotto API.

Account di servizio di assistenza e Workload Identity. Consentire il caricamento dei dati di analisi su Apigee durante che esegue l'adattatore all'esterno di un cluster ibrido Apigee, devi utilizzare Parametro analytics-sa con apigee-remote-service-cli provision . Inoltre, l'adattatore ora supporta Workload Identity su Google Kubernetes (GKE). Vedi Provisioning del comando.
(Solo per Apigee su Google Cloud e 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.
Attributo di configurazione KeepAliveMaxConnectionAge ora il valore predefinito è 1 minuto. Il valore predefinito precedente era 10 minuti. Questa modifica consente una scalabilità più fluida. Questo viene utilizzato anche per la durata del flusso di log di accesso. Vedi il file di configurazione.
Comandi dell'interfaccia a riga di comando rimossi. I seguenti comandi dell'interfaccia a riga di comando sono deprecati. Ti consigliamo di utilizzare API Apigee per aggiornare le destinazioni dei servizi remoti per i prodotti API:
  • apigee-remote-service-cli bindings add
  • apigee-remote-service-cli bindings remove
È stato aggiunto un nuovo comando dell'interfaccia a riga di comando. Il comando: 
apigee-remote-service-cli samples templates

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

v1.2.0

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

Piattaforme supportate

Pubblichiamo programmi binari per MacOS, Linux e Windows.

Pubblichiamo immagini Docker da Ubuntu e Ubuntu senza distro di Google con Boring Crypto.

In questa versione sono supportate le seguenti piattaforme:

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

Funzionalità e miglioramenti

Funzionalità Descrizione
Assistenza per Apigee su Google Cloud Ora puoi utilizzare Apigee Adapter per Envoy con Apigee su Google Cloud. Puoi eseguire l'adattatore nel proprio cluster oppure eseguendo il servizio remoto per Envoy come programma binario nativo o in un container. Esegui il provisioning dell'adattatore su Apigee utilizzando il comando di provisioning.
Caricamento diretto dei dati di analisi Ora puoi configurare Apigee Adapter per caricare i dati di analisi direttamente su Apigee. Se utilizzando Apigee hybrid, consente di eseguire il deployment dell'adattatore nel proprio cluster Kubernetes, all'esterno del cluster in cui è installato Apigee hybrid. Per attivare il caricamento diretto, utilizza il nuovo --analytics-sa con il comando provision. Vedi comando di provisioning.
Il controllo di integrità restituisce lo stato "Pronto" Dopo il caricamento dei dati di prodotto API da Apigee Il controllo di integrità di Kubernetes non restituirà lo stato "Ready" finché i dati di prodotto dell'API non saranno caricato da Apigee. Questa modifica è utile per la scalabilità e l'upgrade, in quanto il traffico non verrà verrà inviato all'adattatore appena creato finché non è pronto.

Altri problemi e correzioni

  • È stato risolto un problema per risolvere un potenziale deadlock di sincronizzazione della quota (Problema n. 17).
  • Le annotazioni Prometheus sono state spostate nella specifica del pod (Problema n. 69).
  • È stato risolto un problema per risolvere gli errori di verifica inviati non correttamente (Problema n. 62).

v1.1.0

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

Piattaforme supportate

Pubblichiamo programmi binari per MacOS, Linux e Windows.

Pubblichiamo immagini Docker da Ubuntu e Ubuntu senza distro di Google con Boring Crypto.

Nella versione 1.1.0 supportiamo le seguenti piattaforme:

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

Funzionalità e miglioramenti

Funzionalità Descrizione
Verifica le associazioni Un nuovo comando apigee-remote-service-cli bindings verify era aggiunto all'interfaccia a riga di comando. Questo comando verifica che il prodotto API associato specificato e i relativi alle app sviluppatore associate è associato anche un prodotto di servizio remoto. Consulta Verifica un'associazione.
Genera esempi È stato aggiunto un nuovo comando apigee-remote-service-cli samples create all'interfaccia a riga di comando. Questo comando crea file di configurazione di esempio per i deployment nativi di Envoy o Istio. La configurazione I file generati con questo comando sostituiscono i file di esempio installati con l'adattatore per Envoy nelle versioni precedenti. Consulta Comando di esempio.
Autenticazione OAuth2 L'adattatore ora utilizza l'autenticazione OAuth2 quando l'autenticazione a più fattori (MFA) è abilitato per Apigee. Usa il flag --mfa ogni volta che usi Flag --legacy.
Container senza distro Ora l'adattatore utilizza invece l'immagine distroless di Google (gcr.io/distroless/base) di scratch per la base di immagini Docker predefinita.

Altri problemi e correzioni

  • È stato risolto un problema dell'interfaccia a riga di comando per i comandi di associazione in OPDK. (n. 29)
  • La quota potrebbe bloccarsi quando la connessione viene persa (apigee/apigee-remote-service-envoy. (n. 31)
  • Le immagini Docker vengono ora create con un utente non root (999).
  • Gli esempi di Kubernetes applicano in modo forzato che l'utente non deve essere root.
  • --http1.1 non è più necessario per i comandi curl per gli endpoint proxy. Il flag è stato sono stati rimossi dagli esempi.

v1.0.0

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

Piattaforme supportate

Pubblichiamo programmi 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:

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

Aggiunte e modifiche

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

  • Crea build noiose

    È ora disponibile una nuova build che utilizza Librerie Go BoringSSL conformi a FIPS.

  • Modifiche ai flag a livello di log

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

    Flag precedente Nuova segnalazione
    log_level log-level
    json_log json-log
  • Nuovi flag dell'interfaccia a riga di comando

    Sono stati aggiunti nuovi flag ai comandi token dell'interfaccia a riga di comando:

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