Introducción a la puerta de enlace autohospedada

SE APLICA A: Desarrollador | Premium

La puerta de enlace autohospedada es una versión opcional en contenedor de la puerta de enlace administrada predeterminada que se incluye en cada instancia de 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 administración de API híbrida y multinube. También presenta la arquitectura de alto nivel de la característica y describe sus funcionalidades.

Para obtener información general sobre las diferencias entre puertas de enlace administradas y autohospedados, 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 le permite administrar de forma eficaz y segura las API hospedadas en el entorno local y entre nubes desde una única instancia de API Management en Azure.

Con la puerta de enlace autohospedada, tiene la flexibilidad de implementar una versión en contenedor del componente de puerta de enlace de API Management en los mismos entornos en los que hospeda las API. Todas las gateways autogestionadas se administran desde la instancia de API Management con la que se federan, proporcionándote visibilidad y una experiencia de administración unificada en todas las API internas y externas.

Cada instancia de API Management se compone de los siguientes componentes clave:

• Un plano de administración, expuesto como UNA API, que se usa para configurar el servicio a través de Azure Portal, PowerShell y otras tecnologías admitidas
• Una puerta de enlace (o plano de datos), responsable de la intermediación de solicitudes de API, la aplicación de políticas y la recopilación de telemetría.
• Un portal para desarrolladores que usan los desarrolladores para descubrir, aprender e incorporar para usar las API

De forma predeterminada, todos estos componentes se implementan en Azure, lo que hace que todo el tráfico de API (que se muestra como flechas negras sólidas en la imagen siguiente) fluya a través de Azure, independientemente de dónde se hospeden los back-end 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 autohospedados en los mismos entornos en los que las implementaciones de api de back-end se hospedan permite que el tráfico de API fluya directamente a las API de back-end, lo que reduce la latencia, optimiza los costos de transferencia de datos y permite el cumplimiento, al tiempo que conserva las ventajas de tener un único punto de administración, observabilidad y detección para todas las API de la organización, independientemente de dónde se hospeden sus implementaciones.

Empaquetado

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, 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 de contenedor

Hay disponibles varias imágenes de contenedor para puertas de enlace autohospedadas:

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 desea 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	✔️	❌
beta 1	Use esta etiqueta si quiere evaluar las versiones preliminares de la puerta de enlace autohospedada.	beta	✔️	❌

Puede encontrar una lista completa de 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

Las opciones de implementación de Azure Portal usan la v2 etiqueta que permite usar la versión más reciente de la imagen de contenedor de puerta de enlace v2 autohospedada con todas las actualizaciones y revisiones de características.

Nota:

El comando y los fragmentos de código YAML se proporcionan como referencia. Puede usar una etiqueta más específica si quiere.

Al instalar una puerta de enlace con un gráfico de Helm, se optimiza el etiquetado de imágenes. 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.

Para obtener más información, consulte 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. El uso de este tipo de etiquetas permite a los usuarios del contenedor recibir actualizaciones de la imagen de contenedor sin tener que actualizar sus implementaciones.

Al usar este tipo de etiqueta, puede ejecutar versiones diferentes en paralelo sin notarlo, por ejemplo, al realizar acciones de escalado después de actualizar la v2 etiqueta.

Ejemplo: la etiqueta v2 se publica con la imagen de contenedor 2.0.0. Cuando 2.1.0 se libera, la v2 etiqueta se vinculará a la 2.1.0 imagen.

Importante

Considere la posibilidad de usar una etiqueta de versión específica en producción para evitar actualizaciones involuntarias 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 una sola instancia de API Management y se configura a través de su plano de administración. La puerta de enlace autohospedada usa la conectividad a Azure para:

• Informar su estado mediante el envío de mensajes de latidos cada minuto.
• Regularmente (cada 10 segundos) comprobando y aplicando actualizaciones de configuración siempre que estén disponibles.
• Envío de métricas a Azure Monitor, si está configurada para hacerlo.
• Enviar eventos a Application Insights, si está configurado para hacerlo.

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:

Punto final	¿Obligatorio?	Notas
Nombre de host del punto de conexión de configuración	<api-management-service-name>.configuration.azure-api.net 1	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 host 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	El punto de conexión necesario es 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	Los puntos de conexión necesarios mínimos son rt.services.visualstudio.com:443, dc.services.visualstudio.com:443y {region}.livediagnostics.monitor.azure.com:443. Para más información, consulte la documentación de Azure Monitor.
Puntos de conexión para la integración con Event Hubs	Opcional5	Para más información, consulte la documentación de Azure Event Hubs.
Puntos de conexión para la integración de caché externa	Opcional5	Este requisito depende de la memoria caché externa que se usa.

¹Para obtener información sobre 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 utiliza la autenticación de Microsoft Entra o políticas relacionadas.
⁵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 se debe tener acceso a las direcciones IP correspondientes.
• Los nombres de cuenta de almacenamiento asociados aparecen 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 Azure Application Gateway.

Opciones de autenticación

La configuración del contenedor de puerta de enlace proporciona las siguientes opciones 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.

Opción	Consideraciones
Autenticación de Microsoft Entra	Configure una o varias aplicaciones de Microsoft Entra para acceder a la puerta de enlace. Administrar el acceso por separado por aplicación. Configure tiempos de expiración más largos para secretos de acuerdo con las directivas de su organización. Use procedimientos estándar de Microsoft Entra para asignar o revocar permisos de usuario o grupo a las aplicaciones y para rotar secretos.
Token de acceso de puerta de enlace. (También se denomina clave de autenticación).	El token expira al menos cada 30 días y debe renovarse en los contenedores. Respaldado por una clave de puerta de enlace que se puede girar de forma independiente (por ejemplo, para revocar el acceso). La regeneración de la clave de puerta de enlace invalida todos los tokens de acceso que se crean con ella.

Sugerencia

Consulte Azure API Management como origen de Event Grid para obtener información sobre los eventos de Event Grid generados por una puerta de enlace autohospedada cuando un token de acceso de puerta de enlace está a punto de expirar o ha expirado. Use estos eventos para asegurarse de que las puertas de enlace implementadas siempre pueden autenticarse con su instancia de API Management asociada.

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 siguen operativas usando una copia en memoria de la configuración.
• Las puertas de enlace autohospedadas, si están detenidas, no se podrán iniciar.

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

• Las puertas de enlace autohospedadas siguen operativas usando una copia en memoria de la configuración.
• Las puertas de enlace autohospedadas detenidas pueden reiniciarse utilizando una copia de seguridad de la configuración.

Cuando se restaura la conectividad, cada puerta de enlace autohospedada afectada por la interrupción se vuelve a conectar automáticamente con su instancia de API Management asociada y descarga todas las actualizaciones de configuración que se produjeron mientras la puerta de enlace estaba sin conexión.

Seguridad

Limitaciones

La funcionalidad siguiente que está disponible en puertas de enlace administradas no está disponible en puertas de enlace autohospedados:

• 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)

Protocolos admitidos

Las puertas de enlace autohospedadas admiten TLS v1.2 de forma predeterminada.

Si usa dominios personalizados, puede habilitar TLS v1.0 o v1.1 en el plano de control.

Conjuntos de cifrado disponibles

Las puertas de enlace autohospedadas usan las siguientes suites 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

Con v2.1.1 y versiones posteriores, puede administrar los cifrados que se usan a través de la configuración:

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

Contenido relacionado

• Introducción a la puerta de enlace de API
• Directiva de soporte técnico para la puerta de enlace autohospedada
• API Management en un mundo híbrido y multinube
• Instrucciones para ejecutar una 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 un 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
• Funcionalidades de observabilidad en API Management
• Integración de Dapr con puerta de enlace autohospedada