Notas de la versión de Apigee Adapter for Envoy

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 las versiones de todo el software de Apigee Adapter for Envoy del 2021 y años anteriores.

Consulta las notas de la versión actual de Adapter for Envoy (2022 y versiones posteriores).

v2.0.4

El 3 de diciembre del 2021, lanzamos la versión 2.0.4 de Apigee Adapter for Envoy.

Funciones y mejoras

  • Se ha actualizado la lista de versiones compatibles de Envoy e Istio para el comando samples de la CLI. Ahora se admiten estas versiones para las muestras:
    • Versiones de Envoy de la 1.18 a la 1.20
    • Versiones de Istio de la 1.10 a la 1.12

Problemas resueltos

  • Se ha añadido una comprobación de nil para la carga de la clave privada del bloque PEM para evitar errores. (Problema n.º 360)
  • Los errores de autorización de servicios remotos ahora se registran en el nivel Debug. Se hace una excepción a esta categorización en el caso de los errores de obtención de tokens de las claves de API. En ese caso, los errores se registran en el nivel Error para que sean visibles aunque el nivel de registro de depuración de apigee-remote-service-envoy esté inhabilitado. Consulta también Configurar los niveles de registro de servicios remotos. (Número 104)

v2.0.3

El 21 de septiembre del 2021, lanzamos la versión 2.0.3 de Apigee Adapter for Envoy.

Problemas resueltos

  • Se ha corregido un problema de registro de analíticas con respuestas directas. El problema solo se producía en determinadas circunstancias. Por ejemplo:
    • En las solicitudes que no requieren una comprobación de autenticación o autorización, no se ha generado ningún authContext y los metadatos dinámicos eran nulos, por lo que se ha ignorado la entrada del registro de acceso.
    • La respuesta denegada usaba un código RPC en lugar de un código HTTP, lo que provocaba que los registros se mostraran como correctos en la interfaz de usuario de Apigee.

v2.0.2

El 7 de junio del 2021, lanzamos la versión 2.0.2 de Apigee Adapter for Envoy.

Problemas resueltos

  • Se ha corregido una condición de carrera que podía provocar errores 403 y pánicos cuando los ámbitos de las reclamaciones de JWT eran nulos.

v2.0.1

El martes, 29 de abril del 2021, lanzamos la versión 2.0.1 de Apigee Adapter for Envoy.

Problemas resueltos

Función Descripción
Error

Se ha corregido un problema que provocaba que la versión 2.0.0 no funcionara correctamente cuando se usaba con Apigee Hybrid 1.5.0 o Apigee. Si vas a actualizar 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:

  1. Actualiza Apigee Adapter for Envoy a la versión 2.0.1.
  2. Actualiza Apigee Hybrid a la versión 1.5.1.

Si usas Apigee, solo tienes que actualizar el adaptador a la versión 2.0.1.

v2.0.0

El martes 6 de abril del 2021, lanzamos la versión 2.0.0 de Apigee Adapter for Envoy.

Funciones y mejoras

Función Descripción
Compatibilidad con entornos de varios clientes

Ahora puede habilitar el adaptador para que dé servicio a varios entornos de una organización de Apigee. Esta función le permite usar un adaptador de Apigee para Envoy asociado a una organización de Apigee para dar servicio a 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 entornos multiinquilino.
Compatibilidad con la API Envoy v3
Compatibilidad con metadatos de Envoy

Envoy 1.16 y versiones posteriores permiten enviar metadatos ext_authz sin tener que usar encabezados. Al usar este cambio y otros relacionados, ahora proporcionamos mejores códigos de respuesta HTTP para las solicitudes denegadas y ya no es necesario instalar un filtro RBAC en Envoy. Consulta

Esta función solo se admite en Envoy 1.16 y versiones posteriores, e Istio 1.9 y versiones posteriores.

Con este cambio, la siguiente configuración ya no se añade al archivo de configuración de 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

Si quieres añadir encabezados a las solicitudes en un caso especial, solo tienes que definir la propiedad append_metadata_headers:true en el archivo config.yaml del adaptador.
Dividir el proxy remote-token del proxy remote-service

El proxy de servicio remoto se ha refactorizado en dos proxies independientes. La versión 2.0.x, provisioning instalará dos proxies de API: remote-service y remote-token. Los endpoints /token y /certs se han movido del proxy remote-service a remote-token.

Este cambio crea una separación útil de las funciones. Ahora, el proxy remote-service solo se usa para las comunicaciones internas del adaptador, mientras que el proxy remote-token proporciona un flujo de trabajo de OAuth de ejemplo que puedes personalizar. Nunca sobrescribiremos tu proxy remote-token personalizado, aunque se use el comando provision --force-proxy-install.

Compatibilidad con la recogida de datos

El adaptador ahora admite la transferencia de metadatos de Envoy a la función de captura de datos de Apigee, que envía los datos capturados en las variables que especifique a las analíticas de Apigee para usarlos en informes personalizados. Esta función ofrece una capacidad similar a la de la política de captura de datos de Apigee. Para obtener más información sobre esta función, consulte el artículo Recoger datos para informes personalizados.

No se requiere RBAC

Como se ha indicado anteriormente en la sección Compatibilidad con metadatos de Envoy, ahora rechazamos inmediatamente las solicitudes no autorizadas sin necesidad de un filtro RBAC independiente. Como no se usa el control de acceso basado en roles, los clientes recibirán estos códigos de estado HTTP según corresponda del adaptador:

  • 401: No autorizado
  • 403: Prohibido
  • 429 Too Many Requests
  • 500 Internal Server Error (Error interno del servidor)

Si quieres permitir que continúen las solicitudes no autorizadas, puedes hacerlo configurando auth:allow_unauthorized:true en el archivo config.yaml del adaptador.

Las cabeceras x-apigee-* ya no se añaden de forma predeterminada

Como se ha indicado anteriormente en la sección Compatibilidad con metadatos de Envoy, las cabeceras x-apigee-* ya no se añaden de forma predeterminada. Si quieres añadirlos, define append_metadata_headers:true en el archivo config.yaml. Esta configuración es completamente opcional y solo debe usarse cuando sea necesario reenviar encabezados al servicio de destino upstream.

Asignar una solicitud a una operación de producto de API de Apigee de forma personalizada

La semántica de la propiedad de configuración api_header sigue siendo la misma que la de la propiedad target_header anterior (el valor predeterminado sigue siendo el nombre de host de destino) y el contenido del encabezado especificado seguirá coincidiendo con el atributo Destino del servicio remoto del producto de la API o con el campo Origen de una configuración de operaciones del producto de la API.

Para anular este valor de encabezado mediante los metadatos de Envoy, puede transferir el elemento de metadatos apigee_api de Envoy al adaptador para especificar directamente el destino del servicio remoto del producto de API o la fuente de la API de la operación del producto de API. Para configurarlo, añade un código similar al siguiente al archivo de configuración de Envoy (que puedes generar con la CLI del adaptador): 

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 analíticas de las solicitudes rechazadas se registran inmediatamente

Envoy Adapter ahora registrará las solicitudes rechazadas inmediatamente en Analytics según sea necesario, en lugar de esperar a que la solicitud vuelva al registro de acceso. Es más eficiente y no requiere que se adjunten metadatos a la solicitud.
Se ha retirado la compatibilidad con UDCA

Ya no es necesario transmitir datos al agente general de recogida de datos (UDCA) de Apigee en Apigee hybrid y Apigee para obtener analíticas, ya que se ha sustituido por la subida directa. Este cambio solo elimina la compatibilidad antigua con esta opción.

Se ha añadido compatibilidad con mTLS para Edge para nubes privadas en los comandos de la CLI provision/bindings

Los usuarios de Apigee Edge para Private Cloud pueden proporcionar certificados TLS del lado del cliente y certificados raíz a través de ‑‑tls‑cert, ‑‑tls‑key y ‑‑tls‑ca, respectivamente, al aprovisionar o enumerar las vinculaciones de productos mediante la CLI.

Compatibilidad con mTLS entre el adaptador y el entorno de ejecución de Apigee

Puede proporcionar certificados TLS del lado del cliente en la sección tenant del archivo config.yaml del adaptador para usar mTLS entre el adaptador y el tiempo de ejecución de Apigee. Este cambio se aplica a todas las plataformas de Apigee compatibles. También habilita mTLS para las analíticas de la plataforma Apigee Edge para nubes privadas. Para obtener más información, consulta el artículo Configurar mTLS entre el adaptador y el tiempo de ejecución de Apigee.

Otros problemas y correcciones

  • Se ha solucionado un problema que provocaba que varias configuraciones de operaciones con la misma fuente de API compartieran los mismos identificadores de contenedor de cuota y causaran conflictos en el cálculo de la cuota. (Número 34)
  • Se ha corregido un problema que provocaba que se denegaran las operaciones sin verbos especificados (el comportamiento esperado es permitir todos los verbos si no se especifica ninguno). (Problema #39)

v1.4.0

El miércoles 16 de diciembre del 2020, lanzamos la versión 1.4.0 de Apigee Adapter for Envoy.

Plataformas compatibles

Publicamos archivos binarios para macOS, Linux y Windows.

Publicamos imágenes de Docker de distroless, Ubuntu y Ubuntu con Boring Crypto de Google.

En esta versión, admitimos las siguientes plataformas:

  • Versión 1.3.x y 1.4.x (fecha de lanzamiento pendiente) de Apigee Hybrid, 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 1.14, 1.15 y 1.16 de Envoy

Funciones y mejoras

Función Descripción
El proxy remote-service ya no requiere asociación con un producto de API que use destinos de servicio remoto.

Como esta asociación ya no es necesaria, ten en cuenta los siguientes cambios:

  • Ya no se crea un producto de API remote-service durante el aprovisionamiento.
  • El comando de CLI bindings verify ya no es relevante y se ha obsoleto.
Ya no se necesita el rol de administrador de la organización de Apigee para el aprovisionamiento.

En lugar de requerir el permiso de administrador de la organización para el aprovisionamiento, ahora puedes usar los roles de gestión de identidades y accesos Creator y Deployer. Debes conceder ambos roles para completar el aprovisionamiento.
(Solo se aplica a Apigee en Google Cloud y Apigee Hybrid)

Otros problemas y correcciones

  • Se ha corregido un problema que provocaba que, al volver a aprovisionar Apigee sin la opción --rotate, se produjera un error.
  • La CLI de aprovisionamiento ahora lee y reutiliza las credenciales de la cuenta de servicio de analíticas de un archivo config.yaml determinado (problema n.º 133).

v1.3.0

El lunes 23 de noviembre del 2020, lanzamos la versión 1.3.0 de Apigee Adapter for Envoy.

Plataformas compatibles

Publicamos archivos binarios para macOS, Linux y Windows.

Publicamos imágenes de Docker de distroless, Ubuntu y Ubuntu con Boring Crypto de Google.

En esta versión, admitimos las siguientes plataformas:

  • Versión 1.3.x y 1.4.x (fecha de lanzamiento pendiente) de Apigee Hybrid, 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 1.14, 1.15 y 1.16 de Envoy

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 un servicio remoto con métodos HTTP. Para obtener más información, consulta OperationGroup.
(Solo se aplica a Apigee en Google Cloud y Apigee Hybrid)
Se ha eliminado la compatibilidad con el proxy de reenvío 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 se ha definido en el producto de API. Por ejemplo: 
curl -i http://localhost:8080/httpbin/headers -H "HOST:httpbin.org"

Consulta Crear un producto de API.

Admite cuentas de servicio y Workload Identity. Para permitir que se suban datos analíticos a Apigee cuando se ejecute el adaptador fuera de un clúster híbrido de Apigee, debe 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 el comando Provision.
(Solo se aplica a Apigee en Google Cloud y Apigee Hybrid)
Nuevo atributo de configuración jwt_provider_key. Esta clave se añade al archivo de configuración. Representa la clave payload_in_metadata del proveedor de JWT en la configuración de Envoy o la entidad emisora de JWT de RequestAuthentication en la configuración de Istio.
El atributo de configuración KeepAliveMaxConnectionAge ahora tiene el valor predeterminado de 1 minuto. El valor predeterminado anterior era de 10 minutos. Este cambio permite un escalado más fluido. Este valor también se usa para el tiempo de vida de la secuencia del registro de acceso. Consulta el archivo de configuración.
Se han quitado comandos de la CLI. Los siguientes comandos de la CLI se han retirado. Te recomendamos que uses las APIs de Apigee para actualizar los destinos de servicios remotos de los productos de API:
  • apigee-remote-service-cli bindings add
  • apigee-remote-service-cli bindings remove
Se ha añadido un nuevo comando de la CLI. El comando: 
apigee-remote-service-cli samples templates

Muestra las opciones disponibles que puedes usar con la marca --template en el comando samples create. Consulta la referencia de la CLI.
Se ha cambiado un comando de la CLI. Se ha modificado el comando apigee-remote-service-cli samples create. Las marcas específicas de las plantillas de Envoy o Istio se comprueban estrictamente y se devuelven errores si se usan de forma incorrecta. La opción de plantilla native está obsoleta. 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 endpoint /token ahora sigue la especificación de OAuth2. Se ha añadido el parámetro access_token a la respuesta y se ha retirado el parámetro token.

v1.2.0

El miércoles 30 de septiembre del 2020, lanzamos la versión 1.2.0 de Apigee Adapter for Envoy.

Plataformas compatibles

Publicamos archivos binarios para macOS, Linux y Windows.

Publicamos imágenes de Docker de distroless, Ubuntu y Ubuntu con Boring Crypto de Google.

En esta versión, admitimos las siguientes plataformas:

  • Versión 1.3.x de Apigee Hybrid
  • Versiones 1.5, 1.6 y 1.7 de Istio
  • Versiones 1.14 y 1.15 de Envoy

Funciones y mejoras

Función Descripción
Asistencia de 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 ejecutando el servicio remoto de Envoy como un archivo binario nativo o en un contenedor. Aprovisiona el adaptador en Apigee con el comando provision.
Subida directa de datos analíticos Ahora puede configurar el adaptador de Apigee para que suba datos analíticos directamente a Apigee. Si utilizas Apigee hybrid, esta nueva función te permite desplegar el adaptador en su propio clúster de Kubernetes, fuera del clúster en el que está instalado Apigee hybrid. Para habilitar la subida directa, usa la nueva marca --analytics-sa con el comando provision. Consulta el comando provision.
La comprobación de estado devuelve "Ready" después de que se carguen los datos del producto de la API desde Apigee La comprobación de estado de Kubernetes no devolverá el valor "Ready" 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 recién creado hasta que esté listo.

Otros problemas y correcciones

  • Se ha corregido un problema para solucionar un posible bloqueo de sincronización de cuotas (problema n.º 17).
  • Las anotaciones de Prometheus se han movido a la especificación de pod (problema n.º 69).
  • Se ha corregido un problema que provocaba que se emitieran errores de verificación de forma incorrecta (problema n.º 62).

v1.1.0

El miércoles 26 de agosto del 2020, lanzamos la versión 1.1.0 de Apigee Adapter for Envoy.

Plataformas compatibles

Publicamos archivos binarios para macOS, Linux y Windows.

Publicamos imágenes de Docker de distroless, Ubuntu y Ubuntu con Boring Crypto de Google.

En la versión 1.1.0, admitimos las siguientes plataformas:

  • Versión 1.3 de Apigee Hybrid
  • Versiones 1.5, 1.6 y 1.7 de Istio
  • Versiones 1.14 y 1.15 de Envoy

Funciones y mejoras

Función Descripción
Verificar las vinculaciones Se ha añadido un nuevo comando apigee-remote-service-cli bindings verify a la CLI. Este comando verifica que el producto de API enlazado especificado y sus aplicaciones de desarrollador asociadas también tengan un producto de servicio remoto asociado. Consulta Verificar una vinculación.
Generar muestras Se ha añadido 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 generes con este comando sustituirán a los archivos de ejemplo que se instalaron con el adaptador para Envoy en versiones anteriores. Consulta los ejemplos de comandos.
Autenticación OAuth2 Ahora, el adaptador usa la autenticación OAuth2 cuando la autenticación multifactor (MFA) está habilitada en Apigee. Usa la marca --mfa siempre que uses la marca --legacy.
Contenedor sin distribución Ahora, el adaptador usa la imagen sin distribución (gcr.io/distroless/base) de Google en lugar de scratch como base de la imagen Docker predeterminada.

Otros problemas y correcciones

  • Se ha corregido un problema de la CLI en los comandos de vinculaciones de OPDK. (#29)
  • La cuota podría quedarse bloqueada si se pierde la conexión (apigee/apigee-remote-service-envoy. (#31)
  • Las imágenes de Docker ahora se compilan con un usuario no raíz (999).
  • Los ejemplos de Kubernetes obligan a que el usuario no sea root.
  • Ya no es necesario usar --http1.1 en los comandos curl dirigidos a endpoints proxy. Se ha quitado la marca de los ejemplos.

v1.0.0

El viernes 31 de julio del 2020, lanzamos la versión disponible para el público general de Apigee Adapter for Envoy.

Plataformas compatibles

Publicamos archivos 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:

  • Versión 1.3 de Apigee Hybrid
  • Versiones 1.5 y 1.6 de Istio
  • Versiones 1.14 y 1.15 de Envoy

Adiciones y cambios

Entre la versión 1.0-beta4 y la versión de disponibilidad general, se han añadido los siguientes cambios al adaptador:

  • Boring builds

    Ahora está disponible una nueva compilación que usa bibliotecas Go BoringSSL compatibles con FIPS.

  • Cambios en las marcas de nivel de registro

    Se han cambiado las marcas de nivel de registro del servicio apigee-remote-service-envoy para que sean coherentes:

    Bandera antigua Nueva marca
    log_level log-level
    json_log json-log
  • Nuevas marcas de la CLI

    Se han añadido nuevas marcas a los comandos de la CLI token:

    Bandera Descripción
    --legacy Define esta marca si usas Apigee Cloud.
    --opdk Define esta marca si usas Apigee para nubes privadas.