Estás viendo la documentación de Apigee Edge.
Ve a la
Documentación de Apigee X. información
v2.1.1
El 7 de junio de 2023, lanzamos la versión 2.1.1 de Apigee Adapter para Envoy.
Problemas resueltos
- Se solucionó un problema por el que las cuotas se duplicaban de forma incorrecta entre operaciones en lugar de compartirse a nivel del Producto.
v2.1.0
El 5 de junio de 2023, lanzamos la versión 2.1.0 de Apigee Adapter para Envoy.
Problemas resueltos
- Se agregó la reclamación
application_id
a la respuesta/verifyApiKey
.
v2.0.7
El 9 de marzo de 2023, lanzamos la versión 2.0.7 de Apigee Adapter para Envoy.
Funciones y mejoras
- Los JWT ahora pueden agregar una reclamación llamada
customattributes
que pasará el valor al destino en un encabezado llamadox-apigee-customattributes
(siappend_metadata_headers
está configurado para sertrue
).
Problemas resueltos
- Se solucionó un problema por el que una clave de API no válida podía crear entradas de registro falsas y estadísticas registros.
- Se quitó una comprobación de versión obsoleta de un proxy que causaba problemas en las versiones más recientes de Apigee
v2.0.6
El 18 de octubre de 2022, lanzamos la versión 2.0.6 del adaptador de Apigee para Envoy.
Problemas resueltos
- Versión de seguridad para abordar una vulnerabilidad de denegación del servicio (DoS) en una biblioteca de dependencias. Consulta CVE-2022-28948.
v2.0.5
El 3 de marzo de 2022, lanzamos la versión 2.0.5 de Apigee Adapter para Envoy.
Problemas resueltos
- Es una versión de seguridad para abordar un riesgo de denegación del servicio (DoS) en la biblioteca de Prometheus. Consulta CVE-2022-21698.
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.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 |
Solo disponible para Apigee X y Apigee híbrido. 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. |
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 |
Coincidencia personalizada de una solicitud con un destino de servicio remoto |
La semántica de la propiedad de configuración
Para anular este valor de encabezado con los metadatos de Envoy, puedes pasar el 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 X 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 |
Problemas resueltos
- 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 Edge para la nube pública, Apigee Edge para la 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, lanzamos la versión 1.3.0 de Apigee Adapter 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 Edge para la nube pública, Apigee Edge para la 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.
(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
es diferente del host de destino del servicio remoto configurado en el producto de API. Para
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 utilices
API de Edge
en su lugar, actualizar los destinos de servicio remoto para los productos de API:
|
Nuevo comando agregado de la CLI. | El comando:
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, 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, 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 | El adaptador ahora usa la autenticación OAuth2 cuando la autenticación de varios factores (MFA) está
habilitado para Apigee Edge. 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, 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:Flag Descripción --legacy
Establece esta marca si usas Apigee Edge Cloud. --opdk
Establece esta marca si usas Apigee Edge para una nube privada.