Introducción a la puerta de enlace autohospedada

SE APLICA A: Desarrollador | Premium

La puerta de enlace autohospedada es una versión opcional y en contenedor de la puerta de enlace administrada predeterminada incluida en cada servicio API Management. Resulta útil para escenarios como colocar puertas de enlace en los mismos entornos donde se hospedan las API. Use la puerta de enlace autohospedada para mejorar el flujo de tráfico de API y abordar los requisitos de seguridad y cumplimiento de la API.

En este artículo, se explica cómo la característica de puerta de enlace autohospedada de Azure API Management habilita la instancia híbrida y multinube de API Management, presenta su arquitectura de alto nivel y resalta sus funcionalidades.

Para obtener información general sobre las características de las distintas ofertas de puerta de enlace, consulte Puerta de enlace de API en API Management.

Administración de API Management híbrida y multinube

La característica de puerta de enlace autohospedada amplía la compatibilidad de API Management con entornos híbridos y multinube y permite a las organizaciones administrar de forma eficaz y segura las API hospedadas localmente y en diferentes nubes desde un único servicio de API Management en Azure.

Con la puerta de enlace autohospedada, los clientes tienen la flexibilidad de implementar una versión en contenedor del componente de puerta de enlace de API Management en los mismos entornos donde hospedan sus API. Todas las puertas de enlace autohospedadas se administran desde el servicio de API Management con el que están federadas, lo que proporciona a los clientes visibilidad y una experiencia de administración unificada en todas las API internas y externas.

Cada servicio de API Management consta de los siguientes componentes clave:

• Plano de administración, expuesto como una API, que se usa para configurar el servicio mediante Azure Portal, PowerShell y otros mecanismos compatibles.
• La puerta de enlace (o el plano de datos) es responsable de redirigir mediante proxy las solicitudes de API y también de la aplicación de directivas y la recopilación de datos de telemetría
• Portal para desarrolladores que les permite descubrir, conocer y usar las API

De forma predeterminada, todos estos componentes se implementan en Azure, haciendo que todo el tráfico de la API (que se muestra como flechas negras sólidas en la siguiente imagen) fluya a través de Azure, independientemente de dónde se hospeden los back-ends que implementan las API. La simplicidad operativa de este modelo se traduce en un aumento de latencia, problemas de cumplimiento normativo y, en algunos casos, cargos adicionales de transferencia de datos.

La implementación de puertas de enlace autohospedadas en los mismos entornos en que se hospedan las implementaciones de API de back-end permite que el tráfico de la API fluya directamente a las API de back-end. Esto reduce la latencia, optimiza los costes de transferencia de datos y facilita el cumplimiento normativo, a la vez que conserva las ventajas de tener un único punto de administración, observabilidad y detección de todas las API dentro de la organización, independientemente de dónde se hospeden sus implementaciones.

Packaging

La puerta de enlace autohospedada está disponible como una imagen de contenedor de Docker basada en Linux desde el Registro de artefacto de Microsoft. Se puede implementar en Docker, Kubernetes o en cualquier otra solución de orquestación de contenedores que se ejecute en un clúster de servidores local, una infraestructura en la nube o, con fines de evaluación y desarrollo, en un equipo personal. También puede implementar la puerta de enlace autohospedada como una extensión de clúster en un clúster de Kubernetes habilitado para Azure Arc.

Imágenes del contenedor

Se proporciona una variedad de imágenes de contenedor para puertas de enlace autohospedadas a fin de satisfacer sus necesidades:

Convención de etiquetas	Recomendación	Ejemplo	Etiqueta gradual	Opción recomendada para producción
{major}.{minor}.{patch}	Use esta etiqueta para ejecutar siempre la misma versión de la puerta de enlace.	2.0.0	❌	✔️
v{major}	Use esta etiqueta para ejecutar siempre una versión principal de la puerta de enlace con cada nueva característica y revisión.	v2	✔️	❌
v{major}-preview	Use esta etiqueta si siempre quiere ejecutar la imagen de contenedor de versión preliminar más reciente.	v2-preview	✔️	❌
latest	Use esta etiqueta si quiere evaluar la puerta de enlace autohospedada.	latest	✔️	❌
beta1	Use esta etiqueta si quiere evaluar las versiones preliminares de la puerta de enlace autohospedada.	beta	✔️	❌

Puede encontrar una lista completa de las etiquetas disponibles aquí.

¹ Las versiones preliminares no se admiten oficialmente y solo tienen fines experimentales. Consulte las directivas de compatibilidad con la puerta de enlace autohospedada.

Uso de etiquetas en las opciones de implementación oficiales

Nuestras opciones de implementación de Azure Portal utilizan la etiqueta v2, que permite a los clientes usar la versión más reciente de la imagen de contenedor de la versión 2 de la puerta de enlace autohospedada con todas las revisiones y las actualizaciones de características.

Nota

Aunque se proporciona el comando y los fragmentos de código YAML como referencia, no dude en usar una etiqueta más específica si lo desea.

Al realizar la instalación con el gráfico de Helm, el etiquetado de imágenes se optimiza automáticamente. La versión de la aplicación del gráfico de Helm ancla la puerta de enlace a una versión determinada y no se basa en latest.

Obtenga más información sobre cómo instalar una puerta de enlace autohospedada de API Management en Kubernetes con Helm.

Riesgo del uso de etiquetas graduales

Las etiquetas graduales son etiquetas que potencialmente se actualizan cuando se lanza una nueva versión de la imagen de contenedor. Esto permite a los usuarios del contenedor recibir actualizaciones de la imagen de contenedor sin tener que actualizar sus implementaciones.

De esta forma, potencialmente puede ejecutar versiones diferentes en paralelo sin darse cuenta, por ejemplo, al realizar acciones de escalado una vez actualizada la etiqueta v2.

Ejemplo: la etiqueta v2 se lanzó con la imagen de contenedor 2.0.0, pero cuando se lance 2.1.0, la etiqueta v2 se vinculará a la imagen 2.1.0.

Importante

Considere la posibilidad de usar una etiqueta de versión específica en producción para evitar una actualización involuntaria a una versión más reciente.

Conectividad a Azure

Las puertas de enlace autohospedadas requieren conectividad TCP/IP saliente a Azure en el puerto 443. Cada puerta de enlace autohospedada debe estar asociada a un único servicio de API Management y configurada a través de su plano de administración. La puerta de enlace autohospedada usa la conectividad a Azure para:

• Informar de su estado mediante el envío de latidos cada minuto
• Comprobar regularmente (cada 10 segundos) y aplicar actualizaciones de configuración siempre que estén disponibles
• Enviar métricas a Azure Monitor, si se configura para ello
• Enviar eventos a Application Insights, si se establece para ello

Dependencias de FQDN

Para funcionar correctamente, cada puerta de enlace autohospedada necesita conectividad en el puerto 443 con los siguientes puntos de conexión asociados a su instancia de API Management basada en la nube:

Descripción	Obligatorio para v1	Obligatorio para v2	Notas
Nombre de host del punto de conexión de configuración	<apim-service-name>.management.azure-api.net	<apim-service-name>.configuration.azure-api.net1	También se admiten nombres de host personalizados y se pueden usar en lugar del nombre de host predeterminado.
Dirección IP pública de la instancia API Management	✔️	✔️	La dirección IP de la ubicación principal es suficiente.
Direcciones IP públicas de la etiqueta de servicio de Azure Storage	✔️	Opcional2	Las direcciones IP deben corresponder a la ubicación principal de la instancia de API Management.
Nombre de la cuenta de Azure Blob Storage	✔️	Opcional2	Cuenta asociada a la instancia (<blob-storage-account-name>.blob.core.windows.net)
Nombre de host de la cuenta de Azure Table Storage	✔️	Opcional2	Cuenta asociada a la instancia (<table-storage-account-name>.table.core.windows.net)
Puntos de conexión para Azure Resource Manager	✔️	Opcional3	Los puntos de conexión requeridos son management.azure.com.
Puntos de conexión para la integración de Microsoft Entra	✔️	Opcional4	Los puntos de conexión necesarios son <region>.login.microsoft.com y login.microsoftonline.com.
Puntos de conexión para la integración con Azure Application Insights	Opcional5	Opcional5	Los puntos de conexión mínimos necesarios son: rt.services.visualstudio.com:443 dc.services.visualstudio.com:443 {region}.livediagnostics.monitor.azure.com:443 Más información en la documentación de Azure Monitor
Puntos de conexión para la integración con Event Hubs	Opcional5	Opcional5	Más información en la documentación de Azure Event Hubs
Puntos de conexión para la integración de caché externa	Opcional5	Opcional5	Este requisito depende de la memoria caché externa que se está usando

¹Para una instancia de API Management en una red virtual interna, consulte Conectividad en una red virtual interna.
²Solo es necesario en v2 cuando se usan el inspector de API o las cuotas en las directivas.
³Solo es necesario cuando se usa la autenticación de Microsoft Entra para comprobar los permisos de RBAC.
⁴Solo es necesario cuando se usa la autenticación de Microsoft Entra o las directivas relacionadas con Microsoft Entra.
⁵ Solo es necesario cuando se usa la característica y requiere información de dirección IP pública, puerto y nombre de host.

Importante

• Los nombres de host DNS deben poder resolverse en direcciones IP y las direcciones IP correspondientes deben ser accesibles.
• Los nombres de cuenta de almacenamiento asociados se muestran en la página Estado de conectividad de red del servicio en Azure Portal.
• Las direcciones IP públicas subyacentes a las cuentas de almacenamiento asociadas son dinámicas y pueden cambiar sin previo aviso.

Conectividad en una red virtual interna

• Conectividad privada: si la puerta de enlace autohospedada se implementa en una red virtual, habilite la conectividad privada al punto de conexión de configuración v2 desde la ubicación de la puerta de enlace autohospedada, por ejemplo, mediante un DNS privado en una red emparejada.

• Conectividad a Internet: si la puerta de enlace autohospedada debe conectarse al punto de conexión de configuración v2 a través de Internet, configure un nombre de host personalizado para el punto de conexión de configuración y exponga el punto de conexión mediante Application Gateway.
  

Opciones de autenticación

Para autenticar la conexión entre la puerta de enlace autohospedada y el punto de conexión de configuración de la instancia de API Management basada en la nube, tiene las siguientes opciones en la configuración del contenedor de puerta de enlace.

Opción	Consideraciones
Autenticación de Microsoft Entra	Configuración de una o varias aplicaciones de Microsoft Entra para el acceso a la puerta de enlace Administrar el acceso por separado por cada aplicación Configurar tiempos de expiración más largos para los secretos en función de las directivas de la organización Uso de procedimientos estándar de Microsoft Entra para asignar o revocar permisos de usuario o grupo a la aplicación y para rotar secretos
Token de acceso de puerta de enlace (también denominado clave de autenticación)	El token expira cada 30 días como máximo y se debe renovar en los contenedores Respaldado por una clave de puerta de enlace que se puede rotar de forma independiente (por ejemplo, para revocar el acceso) La regeneración de la clave de puerta de enlace invalida todos los tókenes de acceso creados con ella

Errores de conectividad

Cuando se pierde la conectividad con Azure, la puerta de enlace autohospedada no puede recibir actualizaciones de configuración, notificar su estado o cargar los datos de telemetría.

La puerta de enlace autohospedada está diseñada para "suspender la estática" y puede sobrevivir a la pérdida temporal de conectividad con Azure. Se puede implementar con o sin la copia de seguridad de configuración local. Con la copia de seguridad de configuración, las puertas de enlace autohospedadas guardan periódicamente una copia de seguridad de la última configuración descargada en un volumen persistente asociado a su contenedor o pod.

Cuando se desactiva la copia de seguridad de la configuración y se interrumpe la conectividad a Azure:

• Las puertas de enlace autohospedadas en ejecución seguirán funcionando con una copia en memoria de la configuración
• Las puertas de enlace autohospedadas detenidas no podrán iniciarse

Cuando se activa la copia de seguridad de la configuración y se interrumpe la conectividad a Azure:

• Las puertas de enlace autohospedadas en ejecución seguirán funcionando con una copia en memoria de la configuración
• Las puertas de enlace autohospedadas detenidas podrán comenzar a usar una copia de seguridad de la configuración

Cuando se restaura la conectividad, cada puerta de enlace autohospedada afectada por la interrupción se volverá a conectar automáticamente con su servicio de API Management asociado y descargará todas las actualizaciones de configuración que se produjeron mientras la puerta de enlace estaba "desconectada".

Seguridad

Limitaciones

Las siguientes funcionalidades de las puertas de enlace administradas no están disponibles en las puertas de enlace autohospedadas:

• Reanudación de la sesión TLS
• Renegociación del certificado de cliente. Para usar la autenticación del certificado de cliente, los consumidores de la API de trabajo deben presentar sus certificados como parte del protocolo de enlace TLS inicial. Para garantizar este comportamiento, habilite el valor Negociar certificado de cliente cuando configure un nombre de host personalizado de puerta de enlace autohospedada (nombre de dominio).

Seguridad de la capa de transporte (TLS)

Importante

Esta información general solo es aplicable a la puerta de enlace autohospedada v1 y v2.

Protocolos admitidos

La puerta de enlace autohospedada proporciona compatibilidad con TLS v1.2 de forma predeterminada.

Los clientes que usan dominios personalizados pueden habilitar TLS v1.0 o v1.1 en el plano de control.

Conjuntos de cifrado disponibles

Importante

Esta información general solo es aplicable a la puerta de enlace autohospedada v2.

La puerta de enlace autohospedada usa los siguientes conjuntos de cifrado para las conexiones de cliente y servidor:

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA

Administración de conjuntos de cifrado

A partir de la versión 2.1.1 y posteriores, puede administrar los cifrados que se usan mediante la configuración:

• net.server.tls.ciphers.allowed-suites le permite definir una lista separada por comas de cifrados que se usarán para la conexión TLS entre el cliente de API y la puerta de enlace autohospedada.
• net.client.tls.ciphers.allowed-suites le permite definir una lista separada por comas de cifrados que se usarán para la conexión TLS entre la puerta de enlace autohospedada y el backend.

Pasos siguientes

• Obtenga más información sobre las distintas puertas de enlace en nuestra introducción a la puerta de enlace de API.
• Más información sobre la directiva de soporte técnico para la puerta de enlace autohospedada
• Más información sobre API Management en un mundo híbrido y multinube
• Obtenga más información sobre las instrucciones para ejecutar la puerta de enlace autohospedada en Kubernetes en producción.
• Implementación de una puerta de enlace autohospedada en Docker
• Implementación de una puerta de enlace autohospedada en Kubernetes
• Implementación de una puerta de enlace autohospedada en el clúster de Kubernetes habilitado para Azure Arc
• Implementación de una puerta de enlace autohospedada en Azure Container Apps
• Opciones de configuración de puerta de enlace autohospedada
• Obtenga información sobre las funcionalidades de observabilidad en API Management.
• Más información sobre la integración de Dapr con la puerta de enlace autohospedada