Esta página se aplica a Apigee y Apigee Hybrid.
Consulta la documentación de Apigee Edge.
En esta página, se documentan las notas de la versión del software del adaptador de Apigee para Envoy 2021 y versiones anteriores.
Consulta Adaptador para Envoy a fin de obtener las notas de la versión actuales (2022 y posteriores).
v2.0.4
El 3 de diciembre de 2021, lanzamos la versión 2.0.4 de Apigee Adapter for Envoy.
Funciones y mejoras
- Se actualizó la lista de versiones compatibles de Envoy y de Istio para el comando
samples
de la CLI. Estas versiones ahora son compatibles con las muestras:- Versiones de Envoy de la versión 1.18 a la 1.20
- Versiones de Istio de la versión 1.10 a la 1.12
Problemas resueltos
- Se agregó una verificación nil para la carga de clave privada del bloque PEM a fin de evitar el pánico. (Problema #360)
- Los errores de autorización de servicio remoto ahora se registran en el nivel de Depuración. Se hace una excepción a esta categorización en el caso de los errores de recuperación de tokens para las claves de API. En ese caso, los errores se registran en el nivel de error para que sean visibles incluso si el nivel de registro de depuración de
apigee-remote-service-envoy
está inhabilitado. Consulta también Configura los niveles de registro del servicio remoto. (Problema #104)
v2.0.3
El 21 de septiembre de 2021, lanzamos la versión 2.0.3 del adaptador de Apigee para Envoy.
Problemas resueltos
- Se corrigió un problema de registro de estadísticas con respuestas directas. El problema solo se produjo en determinadas circunstancias. Por ejemplo:
- Para las solicitudes que no requieren verificación de authn/z, no se generó
authContext
y los metadatos dinámicos eran nulos, lo que causa que se ignore la entrada de registro de acceso. - La respuesta rechazada usó el código RPC en lugar del código HTTP, lo que hizo que los registros se mostrarán en la IU de Apigee como correctos.
- Para las solicitudes que no requieren verificación de authn/z, no se generó
v2.0.2
El 7 de junio de 2021, lanzamos la versión 2.0.2 de Apigee Adapter for Envoy.
Problemas resueltos
- Se corrigió una condición de carrera que podía causar errores 403 y problemas importantes cuando los permisos de las reclamaciones JWT eran nil.
v2.0.1
El martes 29 de abril de 2021, lanzamos la versión 2.0.1 del adaptador de Apigee para Envoy.
Problemas resueltos
Función | Descripción |
---|---|
Error |
Se corrigió un problema que causaba que la versión v2.0.0 fallara cuando se usaba con Apigee Hybrid v1.5.0 o Apigee. Si actualizas tu instalación de Apigee Hybrid a la versión 1.5.x, la ruta de actualización recomendada para el adaptador es la siguiente:
Si usas Apigee, actualiza el adaptador a la versión 2.0.1. |
v2.0.0
El martes 6 de abril de 2021, lanzamos la versión 2.0.0 del adaptador de Apigee para Envoy.
Funciones y mejoras
Función | Descripción |
---|---|
Compatibilidad con el entorno de multiusuario |
Ahora puedes habilitar el adaptador para atender varios entornos en una organización de Apigee. Esta función te permite usar un adaptador de Apigee para Envoy asociado a una organización de Apigee para trabajar con varios entornos. Antes de este cambio, un adaptador siempre estaba vinculado a un entorno de Apigee. Para obtener más información sobre esta función, consulta Compatibilidad con el entorno de multiusuario. |
Compatibilidad con la API de Envoy v3 | |
Compatibilidad con metadatos de Envoy |
Envoy 1.16+ permite enviar metadatos de Esta función solo es compatible con Envoy 1.16 y también Istio 1.9 y versiones posteriores.
Con este cambio, la siguiente configuración ya no se agrega al archivo de configuración de Envoy ( 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 quieres agregar encabezados a las solicitudes de un caso especial, simplemente configura la propiedad |
Divide el proxy remote-token del proxy remote-service |
El proxy remote-service se refactorizó en dos proxies separados. La versión 2.0.x del aprovisionamiento instalará dos proxies de API: remote-service y remote-token. Los extremos
Este cambio crea una separación útil de las funciones. Ahora, el proxy remote-service solo se usa para comunicaciones internas del adaptador, mientras que el proxy remote-token proporciona un flujo de trabajo de OAuth de muestra que puedes personalizar. Nunca reemplazaremos tu proxy personalizado remote-token, incluso si se usa el comando |
Compatibilidad con la captura de datos | El adaptador admite ahora pasar metadatos de Envoy a la función de captura de datos de Apigee, que envía datos capturados en variables que especificas en estadísticas de Apigee para su uso en informes personalizados. Esta función proporciona una capacidad similar a la política de captura de datos de Apigee. Para obtener más información sobre esta función, consulta Captura datos de informes personalizados. |
No se requiere RBAC | Como se indicó antes en Compatibilidad con metadatos de Envoy, ahora rechazamos de forma inmediata las solicitudes no autorizadas sin necesidad de usar un filtro RBAC independiente. Como RBAC no se usa, los clientes ahora recibirán estos códigos de estado HTTP del adaptador, según corresponda:
Si deseas permitir que las solicitudes no autorizadas continúen, puedes configurar |
Los encabezados x-apigee-* ya no se agregan de forma predeterminada |
Como se indicó antes en la sección Compatibilidad con metadatos de Envoy, los encabezados |
Asigna una coincidencia personalizada entre una solicitud y una operación de producto de la API de Apigee |
La semántica de la propiedad de la configuración
Para anular este valor de encabezado mediante el uso de metadatos de Envoy, puedes pasar el elemento de metadatos 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 |
Las estadísticas de las solicitudes rechazadas se registran de inmediato | El adaptador de Envoy ahora registrará las solicitudes rechazadas de inmediato en Analytics según sea necesario, en lugar de esperar a que la solicitud regrese en el registro de acceso. Esto es más eficiente y no requiere que se adjunten metadatos a la solicitud. |
Se quitó la compatibilidad con UDCA | Ya no se necesita transmitir a Apigee Universal Data Collection Agent (UDCA) de Apigee Hybrid y Apigee para generar estadísticas, ya que se reemplazó por carga directa. Este cambio solo quita la asistencia heredada para esta opción. |
Se agregó compatibilidad con mTLS para Edge for Private Cloud en los comandos de la CLI de aprovisionamiento o vinculaciones |
Los usuarios de Apigee Edge for Private Cloud pueden proporcionar certificados TLS del cliente y certificados raíz a través de |
Compatibilidad con mTLS entre el adaptador y el entorno de ejecución de Apigee |
Puedes proporcionar certificados TLS del lado del cliente en la sección |
Otros problemas y correcciones
- Se solucionó un problema en el que varias configuraciones de operación con la misma fuente de API compartían los mismos identificadores de depósito de cuota y provocaban conflictos en el cálculo de cuotas. (Problema #34)
- Se solucionó un problema en el que las operaciones sin verbos especificados provocaban la denegación de la solicitud (el comportamiento esperado es permitir todos los verbos, si no se especifica ninguno). (Problema #39)
v1.4.0
El miércoles 16 de diciembre de 2020, lanzamos la versión 1.4.0 de adaptador de Apigee para Envoy.
Plataformas compatibles
Publicamos objetos binarios para MacOS, Linux y Windows.
Publicamos imágenes de Docker de distroless de Google, Ubuntu y Ubuntu con Boring Crypto.
Esta versión es compatible con las siguientes plataformas
- Apigee Hybrid versión 1.3.x, 1.4.x (fecha de lanzamiento pendiente), Apigee para nube pública, Apigee para nube privada y Apigee en Google Cloud
- Versiones 1.5, 1.6, 1.7 y 1.8 de Istio
- Versiones de Envoy 1.14, 1.15, 1.16
Funciones y mejoras
Función | Descripción |
---|---|
El proxy remote-service ya no requiere asociación con un producto de API que use objetivos de servicio remotos. |
Debido a que esta asociación ya no es necesaria, ten en cuenta los siguientes cambios:
|
La función de administrador de la organización de Apigee ya no es necesaria para el aprovisionamiento. |
En lugar de requerir el permiso de administrador de la organización para el aprovisionamiento, puedes usar, en su lugar, las funciones de la API de IAM Creador e Implementador. Debes conceder ambas funciones para aprovisionar de forma correcta.
|
Otros problemas y correcciones
- Se solucionó un problema el que el reaprovisamiento de Apigee sin la opción
--rotate
se cerró con un error. - La CLI de aprovisionamiento ahora lee y reutiliza las credenciales de la cuenta de servicio de estadísticas de un archivo
config.yaml
determinado (Error #133).
v1.3.0
El lunes 23 de noviembre de 2020, lanzamos la versión 1.3.0 de adaptador de Apigee para Envoy.
Plataformas compatibles
Publicamos objetos binarios para MacOS, Linux y Windows.
Publicamos imágenes de Docker de distroless de Google, Ubuntu y Ubuntu con Boring Crypto.
Esta versión es compatible con las siguientes plataformas
- Apigee Hybrid versión 1.3.x, 1.4.x (fecha de lanzamiento pendiente), Apigee para nube pública, Apigee para nube privada y Apigee en Google Cloud
- Versiones 1.5, 1.6, 1.7 y 1.8 de Istio
- Versiones de Envoy 1.14, 1.15, 1.16
Funciones y mejoras
Función | Descripción |
---|---|
Compatibilidad con OperationGroups de productos de API. | OperationGroups vincula los recursos y la aplicación de cuotas asociada en un proxy o servicio remoto con métodos HTTP. Para obtener más información, consulta OperationGroup.
(Se aplica solo a Apigee en Google Cloud y Apigee Hybrid) |
Quitar la compatibilidad con el proxy dinámico de la generación de muestras. | Debido a este cambio, los clientes deben incluir el encabezado HOST si el nombre de host es diferente del host de destino del servicio remoto que está configurado en el producto de API. Por ejemplo:
curl -i http://localhost:8080/httpbin/headers -H "HOST:httpbin.org" Consulta Crea un producto de API. |
Cuentas de servicio de asistencia y Workload Identity. | Para permitir que los datos de estadísticas se suban a Apigee cuando se ejecuta el adaptador fuera de un clúster híbrido de Apigee, debes usar el parámetro analytics-sa con el comando apigee-remote-service-cli provision . Además, el adaptador ahora es compatible con Workload Identity en Google Kubernetes Engine (GKE). Consulta Comando de aprovisionamiento.
(Se aplica solo a Apigee en Google Cloud y Apigee Hybrid) |
Nuevo atributo de configuración jwt_provider_key . |
Esta clave se agrega al archivo de configuración.
Representa la clave payload_in_metadata del proveedor de JWT en la configuración de Envoy o el emisor de RequestAuthentication de JWT en la configuración de Istio. |
El atributo de configuración KeepAliveMaxConnectionAge ahora es de 1 minuto de forma predeterminada. |
El valor predeterminado anterior era de 10 minutos. Este cambio permite un escalamiento más sencillo. Este valor también se usa para la vida útil de la transmisión de registros de acceso. Consulta el archivo de configuración. |
Comandos quitados de la CLI. | Los siguientes comandos de la CLI están obsoletos. Te recomendamos que uses las API de Apigee para actualizar los objetivos de servicio remoto de los productos de API:
|
Nuevo comando agregado de la CLI. | El comando anterior realiza lo siguiente:
apigee-remote-service-cli samples templates Enumera las opciones disponibles que puedes usar con la marca |
Comando existente modificado de la CLI. | Se realizó un cambio en el comando apigee-remote-service-cli samples create . Las marcas específicas de las plantillas de Envoy o Istio se verifican de forma estricta y los errores se muestran en las marcas que se usaron de forma incorrecta. La opción de plantilla native dejó de estar disponible. Para obtener una lista de las plantillas disponibles, usa el comando apigee-remote-service-cli samples templates .
Consulta también la Referencia de la CLI.
|
La respuesta del extremo /token ahora sigue la especificación de OAuth2. |
El parámetro access_token se agregó a la respuesta y el parámetro token está obsoleto. |
v1.2.0
El miércoles 30 de septiembre de 2020, lanzamos la versión 1.2.0 del Apigee Adapter for Envoy.
Plataformas compatibles
Publicamos objetos binarios para MacOS, Linux y Windows.
Publicamos imágenes de Docker de distroless de Google, Ubuntu y Ubuntu con Boring Crypto.
Esta versión es compatible con las siguientes plataformas
- Apigee Hybrid versión 1.3.x
- Versiones 1.5, 1.6 y 1.7 de Istio
- Envoy versiones 1.14, 1.15
Funciones y mejoras
Función | Descripción |
---|---|
Asistencia para Apigee en Google Cloud | Ahora puedes usar Apigee Adapter for Envoy con Apigee en Google Cloud. Puedes ejecutar el adaptador en su propio clúster o mediante la ejecución del Servicio remoto para Envoy como un objeto binario nativo o en un contenedor. Aprovisiona el adaptador en Apigee con el comando de aprovisionamiento. |
Carga directa para datos de estadísticas | Ahora puedes configurar Apigee Adapter para subir los datos de estadísticas directamente a Apigee. Si usas Apigee Hybrid, esta nueva función permite implementar el adaptador en su propio clúster de Kubernetes, fuera del clúster en el que se instaló Apigee Hybrid. Para habilitar la carga directa, usa la nueva marca --analytics-sa con el comando provision .
Consulta el comando de aprovisionamiento.
|
La verificación de estado muestra "Listo" después de que los datos del producto de la API se cargan desde Apigee | La verificación de estado de Kubernetes no mostrará “Listo” hasta que los datos del producto de la API se carguen desde Apigee. Este cambio ayuda a escalar y actualizar, ya que no se enviará tráfico al adaptador cuya instancia se acaba de crear hasta que esté listo. |
Otros problemas y correcciones
- Se corrigió un problema para abordar un posible interbloqueo de sincronización de cuota (Pro #17).
- Se movieron las anotaciones de Prometheus a las especificaciones del pod (Problema 69).
- Se corrigió un problema para abordar errores de verificación emitidos de forma inadecuada (Problema #62).
v1.1.0
El miércoles 26 de agosto de 2020, lanzamos la versión 1.1.0 de Apigee Adapter for Envoy.
Plataformas compatibles
Publicamos objetos binarios para MacOS, Linux y Windows.
Publicamos imágenes de Docker de distroless de Google, Ubuntu y Ubuntu con Boring Crypto.
En la versión 1.1.0, admitimos las siguientes plataformas:
- Apigee hybrid versión 1.3
- Versiones 1.5, 1.6 y 1.7 de Istio
- Envoy versiones 1.14, 1.15
Funciones y mejoras
Función | Descripción |
---|---|
Verifica las vinculaciones | Se agregó un nuevo comando apigee-remote-service-cli bindings verify a la CLI. Este comando verifica que el producto de API vinculado que se especificó y sus apps para desarrolladores asociadas también tengan un producto de servicio remoto asociado a ellos. Consulta Verifica una vinculación. |
Generar muestras | Se agregó un nuevo comando apigee-remote-service-cli samples create a la CLI. Este comando crea archivos de configuración de muestra para implementaciones nativas de Envoy o Istio. Los archivos de configuración que generas con este comando reemplazan los archivos de muestra que se instalaron con Adapter for Envoy en versiones anteriores. Consulta Comando de muestra. |
Autenticación OAuth | Ahora, el adaptador usa la autenticación OAuth2 cuando la autenticación de varios factores (MFA) está habilitada para Apigee. Usa la marca --mfa cada vez que uses la marca --legacy . |
Contenedor distroless | El adaptador ahora usa la imagen sin distro (gcr.io/distroless/base ) de Google, en lugar de scratch , para la base de imágenes predeterminada de Docker. |
Otros problemas y correcciones
- Se corrigió un problema de CLI para los comandos de vinculación en OPDK. (#29)
- La cuota podía atascarse cuando se perdía la conexión (apigee/apigee-remote-service-envoy). (#31)
- Las imágenes de Docker ahora se compilan con un usuario no raíz (999).
- Las muestras de Kubernetes que aplica el usuario no deben ser raíz.
--http1.1
ya no es necesario para los comandos curl en los extremos del proxy. La marca se quitó de los ejemplos.
v1.0.0
El viernes 31 de julio de 2020, lanzamos la versión de disponibilidad general de Apigee Adapter for Envoy.
Plataformas compatibles
Publicamos objetos binarios para MacOS, Linux y Windows.
Publicamos imágenes de Docker desde cero, Ubuntu y Ubuntu con Boring Crypto.
En la versión 1.0.0, admitimos las siguientes plataformas:
- Apigee hybrid versión 1.3
- Versiones 1.5 y 1.6 de Istio
- Envoy versiones 1.14, 1.15
Adiciones y cambios
Entre la versión v1.0-beta4 y Google Analytics, se realizaron los siguientes cambios en el adaptador:
Compilaciones de Go Boring
Una compilación nueva que ahora está disponible usa bibliotecas Go BoringSSL que cumplen con FIPS.
- Cambios en las marca de nivel de registro
Se cambiaron las marcas de nivel de registro para el servicio apigee-remote-service-envoy para generar coherencia:
Marca anterior Nueva marca log_level
log-level
json_log
json-log
- Marcas de CLI nuevas
Se agregaron marcas nuevas a los comandos
token
de la CLI:Marcar Descripción --legacy
Configura esta marca si usas Apigee Cloud. --opdk
Configura esta marca si usas Apigee para la nube privada.