Notas de la versión del adaptador de Apigee para 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 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.

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:

  1. Actualizar el adaptador de Apigee para Envoy a la versión 2.0.1.
  2. Actualizar Apigee Hybrid a la versión 1.5.1.

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 ext_authz sin tener que usar encabezados. Mediante este y otros cambios relacionados, ahora proporcionamos mejores códigos de respuesta HTTP para las solicitudes rechazadas, y ya no necesitamos instalar un filtro RBAC en Envoy. Consulte

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 (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 agregar encabezados a las solicitudes de un caso especial, simplemente configura la propiedad append_metadata_headers:true en el archivo config.yaml del adaptador.
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 /token y /certs se movieron 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 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 provision --force-proxy-install.

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:

  • 401 Unauthorized
  • 403 Forbidden
  • 429 Too Many Requests
  • 500 Internal Server Error

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

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 x-apigee-* ya no se agregan de forma predeterminada. Si deseas agregarlos, configura append_metadata_headers:true en el archivo config.yaml. Esta configuración es completamente opcional y solo debe usarse cuando sea conveniente reenviar encabezados al servicio de destino ascendente.

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 api_header sigue siendo la misma que la propiedad principal target_header (el valor predeterminado sigue siendo el nombre de host de destino), y el contenido del encabezado especificado coincide con el atributo del producto de API Destino del servicio remoto o el campo Búsqueda campo de una Configuración de operaciones de productos de API.

Para anular este valor de encabezado mediante el uso de metadatos de Envoy, puedes pasar el elemento de metadatos apigee_api desde Envoy al adaptador a fin de especificar directamente el destino del servicio remoto de la fuente API de la operación del producto de la API. Para configurar, agrega 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 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 ‑‑tls‑cert, ‑‑tls‑key y ‑‑tls‑ca, respectivamente, cuando aprovisionan o enumeran vinculaciones de productos con la CLI.

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 tenant del archivo config.yaml del adaptador para usar mTLS entre el adaptador y el entorno de ejecución de Apigee. Este cambio se aplica a todas las plataformas de Apigee compatibles. También habilita mTLS para estadísticas de la plataforma Apigee Edge for la nube privada. Para obtener más información, consulta la sección sobre cómo configurar mTLS entre el adaptador y el entorno de ejecución de Apigee.

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:

  • Ya no se crea un producto de API de remote-service durante el aprovisionamiento.
  • El comando bindings verify de la CLI ya no es relevante y dejó de estar disponible.
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.
(Se aplica solo a Apigee en Google Cloud y Apigee Hybrid)

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:
  • apigee-remote-service-cli bindings add
  • apigee-remote-service-cli bindings remove
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 --template en el comando samples create. Consulta la referencia de la CLI.
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 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:

    Flag Descripción
    --legacy Configura esta marca si usas Apigee Cloud.
    --opdk Configura esta marca si usas Apigee para la nube privada.