Uso de Azure API Management con microservicios implementados en Azure Kubernetes Service

SE APLICA A: todos los niveles de API Management

Los microservicios son idóneos para crear interfaces de programación de aplicaciones. Puede usar Azure Kubernetes Service (AKS) para implementar y operar rápidamente una arquitectura basada en microservicios en la nube. Después, puede usar Azure API Management para publicar los microservicios como API para el consumo interno y externo. En este artículo se describen las opciones para usar API Management para publicar arquitecturas basadas en microservicios de AKS como API. Supone un conocimiento básico de las redes de Kubernetes, API Management y Azure.

Información previa

Al publicar microservicios como API para su consumo, puede resultar difícil administrar la comunicación entre los microservicios y los clientes que los consumen. Entre los problemas transversales se incluyen la autenticación, la autorización, la limitación, el almacenamiento en caché, la transformación y la supervisión. Estos problemas se aplican independientemente de si los microservicios se exponen a clientes internos o externos.

El patrón de puerta de enlace de API aborda estos problemas. Una puerta de enlace de API actúa como puerta de entrada de los microservicios, desacopla los clientes de los microservicios, agrega una capa de seguridad adicional y reduce la complejidad de los microservicios al eliminar la carga que supone el control de las cuestiones transversales.

API Management es una solución llave en mano para resolver las necesidades de la puerta de enlace de API. Puede crear rápidamente una puerta de enlace coherente y moderna para los microservicios y publicarlos como interfaces de programación de aplicaciones. Como solución de administración de API de ciclo de vida completo, también proporciona funcionalidades adicionales, incluido un portal para desarrolladores de autoservicio para la detección de API, la administración del ciclo de vida de la API y el análisis de API.

Cuando se usan conjuntamente, AKS y API Management ofrecen una plataforma para implementar, publicar, proteger, supervisar y administrar las interfaces de programación de aplicaciones basadas en microservicios. En este artículo se describen algunas opciones para implementar AKS junto con API Management.

Kubernetes Services e interfaces de programación de aplicaciones

En un clúster de Kubernetes, los contenedores se implementan en Pods, que son efímeros y tienen un ciclo de vida. Cuando se produce un error en un nodo de trabajo, se pierden los pods que se ejecutan en el nodo. Por lo tanto, la dirección IP de un pod puede cambiar en cualquier momento. No puede confiar en él para comunicarse con el pod.

Para solucionar este problema, Kubernetes presentó el concepto de Services. Un servicio de Kubernetes es una capa de abstracción que define un grupo lógico de Pods y permite la exposición del tráfico externo, el equilibrio de carga y el descubrimiento de servicios para esos Pods.

Cuando esté listo para publicar los microservicios como API mediante API Management, debe pensar en cómo asignar los servicios en Kubernetes a las API de API Management. No hay reglas establecidas para esta asignación. Depende de cómo haya diseñado y particionado sus capacidades o dominios empresariales en microservicios al principio. Por ejemplo, si los Pods detrás de un Servicio son responsables de todas las operaciones sobre un recurso dado (por ejemplo, Cliente), podría asignar el Servicio a una API. Si las operaciones de un recurso se dividen en varios microservicios (por ejemplo, GetOrder y PlaceOrder), puede agregar varios servicios en una sola API en API Management. (Consulte el diagrama siguiente).

También se pueden desarrollar las asignaciones. Dado que API Management crea una fachada delante de los microservicios, permite refactorizar y ajustar el tamaño correcto de los microservicios a lo largo del tiempo.

Implementación de API Management delante de AKS

Hay algunas opciones para implementar API Management delante de un clúster de AKS.

Un clúster de AKS siempre se implementa en una red virtual, pero una instancia de API Management no se implementa necesariamente en una red virtual. Cuando API Management no reside en la red virtual del clúster, el clúster de AKS debe publicar puntos de conexión públicos para que API Management se conecte. En ese caso, debe proteger la conexión entre API Management y AKS. Es decir, debe asegurarse de que solo se puede acceder al clúster a través de API Management. En las secciones siguientes se describen las opciones para implementar API Management delante de AKS.

Opción 1: Exposición pública de los servicios

Puede exponer públicamente servicios en un clúster de AKS mediante los tipos de servicio NodePort, LoadBalancer o ExternalName. Cuando lo hace, los servicios son accesibles directamente desde la red pública de Internet. Después de implementar API Management delante del clúster, debe asegurarse de que todo el tráfico entrante pasa por API Management aplicando la autenticación en los microservicios. Por ejemplo, API Management puede incluir un token de acceso en cada solicitud realizada al clúster. Cada microservicio debe validar el token antes de procesar la solicitud.

Esta opción puede proporcionar la manera más sencilla de implementar API Management delante de AKS, especialmente si ya tiene lógica de autenticación implementada en los microservicios.

Ventajas:

• Configuración sencilla en el lado de API Management porque NO es necesario insertar API Management en la red virtual del clúster
• No se produce ningún cambio en el lado de AKS si los servicios ya se exponen públicamente y la lógica de autenticación ya existe en microservicios

Inconvenientes:

• Crea un riesgo de seguridad potencial debido a la visibilidad pública de los puntos de conexión.
• No crea un único punto de entrada para el tráfico de clúster entrante.
• Complica los microservicios con lógica de autenticación duplicada

Opción 2: Instalar un controlador de entrada

Aunque la opción 1 podría ser más fácil, tiene inconvenientes importantes, como se indicó anteriormente. Si una instancia de API Management no reside en la red virtual del clúster, la autenticación TLS mutua (mTLS) es una forma sólida de garantizar que el tráfico sea seguro y de confianza en ambas direcciones entre una instancia de API Management y un clúster de AKS.

La autenticación TLS mutua es compatible de forma nativa con API Management. Puede habilitarlo en Kubernetes instalando un controlador de entrada. (Consulte el diagrama siguiente). Como resultado, la autenticación se realiza en el controlador de entrada, lo que simplifica los microservicios. Además, en los niveles de servicio que admiten direcciones IP dedicadas, puede agregar las direcciones IP de API Management a la lista de permitidos de entrada para asegurarse de que solo API Management tiene acceso al clúster.

Ventajas:

• Permite una configuración sencilla en el lado de API Management porque NO es necesario insertar API Management en la red virtual del clúster y mTLS es compatible de forma nativa.
• Centraliza la protección para el tráfico de clúster entrante en la capa del controlador de entrada.
• Reduce el riesgo de seguridad al minimizar los puntos de conexión de clúster visibles públicamente

Inconvenientes:

• Aumenta la complejidad de la configuración del clúster porque necesita instalar, configurar y mantener el controlador de entrada y administrar los certificados usados para mTLS.
• Agrega riesgo de seguridad debido a la visibilidad pública de los puntos de conexión del controlador de entrada, a menos que use api Management Standard v2 o nivel Premium.

Al publicar API a través de API Management, es fácil y habitual proteger el acceso a esas API mediante claves de suscripción. Los desarrolladores que necesiten usar las API publicadas deben incluir una clave de suscripción válida en las solicitudes HTTP al realizar llamadas a esas API. De lo contrario, la puerta de enlace de API Management rechaza las llamadas inmediatamente. No se reenvían a los servicios back-end.

Para obtener una clave de suscripción para acceder a las API, los desarrolladores necesitan una suscripción. Una suscripción es básicamente un contenedor con nombre para un par de claves de suscripción. Los desarrolladores que necesiten usar las API publicadas pueden obtener suscripciones. No necesitan aprobación de publicadores de API. Los publicadores de API también pueden crear suscripciones directamente para los consumidores de API.

Opción 3: Implementación de API Management dentro de la red virtual del clúster

En algunos casos, los clientes que tienen restricciones normativas o requisitos de seguridad estrictos pueden encontrar Opciones 1 y 2 inviables debido a los puntos de conexión expuestos públicamente. En otros, el clúster de AKS y las aplicaciones que consumen los microservicios pueden residir dentro de la misma red virtual, por lo que no hay ninguna razón para exponer el clúster públicamente porque todo el tráfico de API permanece dentro de la red virtual. En estos escenarios, puede implementar API Management en la red virtual del clúster. Los niveles desarrollador de API Management, Premium y Premium v2 (versión preliminar) admiten la inserción en la red virtual del clúster.

Hay dos modos de implementar API Management en una red virtual: externa e interna. Actualmente, el modo externo solo está disponible en los niveles clásicos de API Management.

Si los consumidores de API no residen en la red virtual del clúster, debe usar el modo externo. (Consulte el diagrama siguiente). En este modo, la puerta de enlace de API Management se inserta en la red virtual del clúster, pero es accesible desde la red pública de Internet a través de un equilibrador de carga externo. Esta arquitectura ayuda a ocultar el clúster completamente, a la vez que permite a los clientes externos consumir los microservicios. Además, puede usar funcionalidades de red de Azure como grupos de seguridad de red (NSG) para restringir el tráfico de red.

Si todos los consumidores de API residen en la red virtual del clúster, puede usar el modo interno. (Consulte el diagrama siguiente). En este modo, la puerta de enlace de API Management se inserta en la red virtual del clúster y solo se puede acceder desde esta red virtual a través de un equilibrador de carga interno. No hay forma de acceder a la puerta de enlace de API Management ni al clúster de AKS desde la red pública de Internet.

El clúster de AKS no está visible públicamente en ningún caso. A diferencia de la opción 2, es posible que el controlador de entrada no sea necesario. Según el escenario y la configuración, es posible que se requiera autenticación entre API Management y los microservicios. Por ejemplo, si usa una malla de servicio, siempre necesita la autenticación TLS mutua.

Ventajas:

• Proporciona la opción más segura porque el clúster de AKS no tiene ningún punto de conexión público.
• Simplifica la configuración del clúster porque no hay ningún punto de conexión público
• Proporciona la capacidad de ocultar API Management y AKS dentro de la red virtual mediante el modo interno.
• Proporciona la capacidad de controlar el tráfico de red mediante funcionalidades de red de Azure, como NSG.

Inconvenientes:

• Aumenta la complejidad de implementar y configurar API Management para que funcione dentro de la red virtual.

Contenido relacionado

• Conceptos de red para aplicaciones en AKS
• Uso de API Management con redes virtuales