¿Qué son las políticas de API Gateway?

Con el desarrollo de la arquitectura nativa en la nube y de microservicios, el papel de las puertas de enlace de API como portales de tráfico es cada vez más crucial. Las puertas de enlace de API son principalmente responsables de recibir el tráfico solicitado y reenviarlo a los servicios ascendentes adecuados. La política de la puerta de enlace de API determina la lógica y las reglas para gestionar el tráfico, lo que directamente determina el comportamiento del tráfico empresarial.

¿Qué son las políticas de la puerta de enlace de API?

La puerta de enlace de API generalmente se encuentra frente a todos los servicios ascendentes. Cuando un usuario envía una solicitud a un servicio, la solicitud primero llegará a la puerta de enlace de API, y la puerta de enlace de API generalmente verificará varias cosas:

1. Verificar si la solicitud es legal. ¿Proviene de una lista de usuarios prohibidos de acceder?
2. Verificar si la solicitud está autenticada y si el contenido accedido está autorizado.
3. Verificar si la solicitud activa reglas de restricción específicas, como límites de tasa.
4. Verificar a qué servicio ascendente se debe reenviar.

Después de esta serie de pasos, la solicitud es rechazada o llega correctamente al servicio ascendente especificado. Llamamos a estas reglas de procesamiento las políticas de la puerta de enlace de API. Estas reglas son agregadas continuamente a la puerta de enlace por el administrador de la puerta de enlace mientras esta está en funcionamiento. La puerta de enlace acepta estas reglas y realiza comportamientos de procesamiento de tráfico correspondientes.

Tomando como ejemplo la puerta de enlace de API Apache APISIX, hay dos tipos de información de configuración de APISIX: el archivo de configuración para el inicio de la puerta de enlace, como config.yaml, este archivo determina algunas configuraciones necesarias para que la puerta de enlace se inicie normalmente. Además, los administradores pueden crear dinámicamente varias reglas y configuraciones a través de la API de administración en tiempo de ejecución, como Route, Consumer, Plugin, etc. Las políticas de la puerta de enlace de API son varias reglas y configuraciones creadas dinámicamente por el administrador a través de la API de administración.

Este artículo elaborará sobre los escenarios de las cuatro puertas de enlace de API, autenticación y autorización, seguridad, procesamiento de tráfico y observabilidad, y cómo funcionan las políticas de la puerta de enlace de API en cada escenario.

Política de autenticación y autorización

La autenticación puede confirmar la identidad del llamador de la API, y la autorización restringe al llamador a acceder solo a los recursos dentro de su autoridad.

Por ejemplo, si un pasajero viaja a una estación, usará su identificación para "autenticarse" y confirmar su identidad antes de ingresar a la estación. Después de ingresar a la estación, mostrará su boleto al personal para confirmación y será "autorizado" para ingresar a un tren específico. El propósito principal de las políticas de autenticación y autorización es garantizar que todas las solicitudes reenviadas a los servicios ascendentes sean legales y que las solicitudes solo accedan a recursos dentro del alcance de la autoridad. Algunas políticas estándar son las siguientes:

Autenticación básica

La política de Autenticación de Acceso Básico es la técnica de control de acceso más sencilla. Generalmente, el proxy HTTP del usuario lleva un encabezado de solicitud para la autenticación cuando envía una solicitud, que suele ser: Authorization: Basic <credenciales>, y las credenciales incluyen el ID de usuario y la contraseña necesarios para la autenticación del usuario, separados por :. Este método no requiere configuraciones complejas como páginas de inicio de sesión y cookies. Se autentica en función de información de credenciales simple en el encabezado de la solicitud, generalmente un nombre de usuario y una contraseña, lo que es simple de configurar y usar.

Un ejemplo de una solicitud cURL con autenticación básica es el siguiente, con nombre de usuario y contraseña:

curl -i -u 'nombre de usuario:contraseña' http://127.0.0.1:8080/hello

Cabe señalar que la información en credenciales no se cifrará durante la transmisión. Solo está codificada en base64, por lo que generalmente debe usarse con HTTPS para garantizar la seguridad de la contraseña.

Después de implementar esta política en la puerta de enlace, las solicitudes sin credenciales no se reenviarán a menos que se lleve la información de autenticación correcta en la solicitud. Esta política implementa la verificación de acceso a la API con el mínimo costo.

Autenticación por clave

La política de autenticación por clave restringe las llamadas a la API agregando claves a la API y usando claves para controlar el acceso a los recursos. Solo las solicitudes con la clave correcta, que puede llevarse en el encabezado de la solicitud o en la consulta, pueden acceder a los recursos. Por lo general, esta clave también puede usarse para distinguir a diferentes llamadores de API. De esta manera, se pueden implementar diferentes políticas o controles de recursos para diferentes llamadores. Al igual que la autenticación básica, la clave no está cifrada. Asegúrese de que la solicitud use HTTPS para garantizar la seguridad.

Tomemos como ejemplo el plugin key-auth de APISIX. El plugin necesita crear un Consumer con un valor de clave único a través de la API de administración:

curl http://127.0.0.1:9180/apisix/admin/consumers \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "jack-key"
        }
    }
}'

Esta solicitud crea un Consumer llamado jack con el valor de clave jack-key.

Al habilitar el plugin en la ruta, debe configurar la ubicación y el nombre del campo de la clave en la solicitud. La configuración predeterminada de la ubicación es header, y el nombre del campo es apikey, por lo que el código correcto para solicitar esta ruta es:

curl -i http://127.0.0.1:8080/hello -H 'apikey: jack-key'

Una vez que APISIX recibe esta solicitud, APISIX extraerá la clave y la comparará con el Consumer jack de todas las claves configuradas. Por lo tanto, la puerta de enlace sabrá que la solicitud fue enviada por jack. Si no se encuentra ninguna clave coincidente, se puede juzgar como una solicitud ilegal.

JSON Web Token

JSON Web Token (JWT) es un estándar abierto que define una forma de transmitir información de manera segura entre partes en forma de objetos JSON. La política de JWT puede combinar autenticación y autorización. Después de que el usuario autoriza, se transmitirá un token JWT al usuario, y el llamador llevará este token en todas las solicitudes posteriores para garantizar que la solicitud esté autorizada.

En la puerta de enlace de API, se puede agregar autenticación JWT a la puerta de enlace a través de la política de JWT. Por lo tanto, podemos separar la lógica de autenticación del código de negocio, y los desarrolladores pueden centrarse más en implementar la lógica de negocio. Tomemos como ejemplo el plugin jwt-auth de APISIX. El plugin debe habilitarse y configurarse en Consumer con su clave única, claves públicas y privadas para el cifrado, algoritmo de cifrado, tiempo de expiración del token, etc. Al mismo tiempo, debe habilitar este plugin en la ruta y configurar la puerta de enlace para leer la ubicación y los campos del token, como header, query, cookie, etc. Este plugin agregará una API a la puerta de enlace de API para emitir tokens. Antes de enviar la solicitud, se debe solicitar la API que emite el token. El token debe llevarse en la ubicación especificada según la información de configuración al enviar la solicitud. Después de que la solicitud llegue a la puerta de enlace, la puerta de enlace leerá el token de la ubicación especificada de la solicitud según la información de configuración y verificará la validez del token. La solicitud puede reenviarse al servicio ascendente una vez verificada.

En comparación con las dos estrategias anteriores, la política de JWT incluye una opción para el tiempo de expiración. El token emitido puede expirar con el tiempo, pero la validez de Basic Auth y Key Auth es permanente a menos que el servidor cambie la contraseña o la clave. Además, la política de JWT puede compartirse entre múltiples servicios, lo que es beneficioso para escenarios de inicio de sesión único (SSO).

OpenID Connect

OpenID Connect es un método de autenticación y autorización basado en el protocolo OAuth2.0, que proporciona una solución de aplicación relativamente completa. La política de OpenID Connect en la puerta de enlace de API permitirá que el servicio ascendente obtenga la información del usuario del proveedor de identidad (IdP), protegiendo así la seguridad de la API. Los IdP comunes son Keycloak, Ory Hydra, Okta, Auth0, etc. Tomando Apache APISIX como ejemplo, el flujo de trabajo de la política de OpenID Connect en la puerta de enlace es el siguiente:

1. El cliente envía una solicitud a la puerta de enlace.
2. Después de recibir la solicitud, la puerta de enlace envía una solicitud de autenticación al IdP.
3. El usuario será redirigido a la página proporcionada por el IdP para completar la autenticación de inicio de sesión.
4. El IdP redirige a la puerta de enlace con el código de autenticación.
5. La puerta de enlace solicita un token de acceso al IdP a través del código para obtener la información del usuario.
6. La puerta de enlace puede llevar la información del usuario al reenviar la solicitud ascendente.

Este proceso permite que la autenticación y la autorización se separen del negocio, haciendo que la arquitectura sea más granular.

Para obtener más métodos de autenticación y autorización de APISIX, consulte Autenticación de la puerta de enlace de API.

Política de seguridad

La política de seguridad de la puerta de enlace de API actúa como un guardián para garantizar el acceso seguro a la API, permitiendo que las solicitudes legales sean reenviadas por la puerta de enlace y bloqueando las solicitudes ilegales en la puerta de enlace. Según el Proyecto de Seguridad de API de OWASP, existen muchas posibles amenazas y ataques a los llamadores de API. Usar la política de seguridad de la puerta de enlace de API puede realizar verificaciones de seguridad en todas las solicitudes de API, lo que juega un papel esencial en la protección de la API contra estas amenazas de seguridad.

Las siguientes son varias políticas importantes de seguridad de la puerta de enlace de API:

Restricciones de acceso por IP

La política de restricción de IP restringe el acceso a la API por parte de clientes específicos al establecer ciertas IPs o CIDR en una lista de permitidos o denegados para prohibir el acceso malicioso a datos sensibles. Configurar correctamente esta política mejorará significativamente la seguridad de la API y permitirá una mayor gobernanza de seguridad de la API.

Bloqueo de URI

La política de bloqueo de URI intercepta solicitudes de API potencialmente peligrosas al establecer algunas reglas de URI. Por ejemplo, algunos ataques de seguridad detectan vulnerabilidades potenciales al husmear la ruta del URI y luego atacan. Apache APISIX proporciona el plugin uri-blocker para bloquear solicitudes de API peligrosas. También se pueden establecer expresiones regulares a través del plugin uri-blocker. La puerta de enlace de API bloqueará la solicitud si coincide con la regla. Por ejemplo, si configuramos root.exe, admin, este plugin puede bloquear solicitudes */root.exe y */admin para proteger aún más la seguridad de la API.

CORS

CORS (Intercambio de recursos de origen cruzado) es la política de seguridad del navegador para solicitudes de dominio cruzado. Generalmente, antes de enviar una solicitud xhr en el navegador, el navegador verificará si la dirección de la solicitud y la dirección actual están en el mismo origen. Las solicitudes dentro del mismo origen se enviarán directamente. De lo contrario, el navegador primero enviará una solicitud de pre-vuelo de tipo OPTION. Habrá configuraciones relacionadas con CORS en el encabezado de respuesta, como los métodos y las credenciales permitidas para llevar en las solicitudes de dominio cruzado. El navegador decidirá si enviar una solicitud formal basándose en esta información. Para más detalles, consulte CORS.

Generalmente, la respuesta que contiene configuraciones de CORS es establecida por el servicio backend. Pero si hay muchos servicios, será más seguro y conveniente procesarlos uniformemente a nivel de puerta de enlace. La política de CORS puede establecer diferentes políticas de resolución de dominio cruzado en diferentes APIs, y los servicios ascendentes ya no necesitan manejar estas lógicas.

CSRF

CSRF es un ataque de falsificación de solicitud entre sitios, que hace que los usuarios finales realicen acciones involuntarias en el sitio web que han autenticado. Este ataque generalmente está acompañado de ingeniería social (enviar un enlace malicioso a la víctima por correo electrónico). Cuando el usuario hace clic en el enlace, el atacante usa la identidad autenticada de la víctima para realizar operaciones de ataque en el sitio web. Desde la perspectiva del sitio web, cualquier comportamiento es esperado porque el usuario ya ha iniciado sesión.

Por lo general, el servicio backend del sitio web necesita agregar middleware adicional para manejar esta parte de la lógica, y los métodos de prevención también tienen estándares específicos. Usar la política de CSRF puede prevenir este ataque y realizar el procesamiento de seguridad CSRF en la capa de la puerta de enlace para simplificar la complejidad lógica de los servicios ascendentes.

Política de procesamiento de tráfico

La política de procesamiento de tráfico principalmente asegura que la carga ascendente de la puerta de enlace de API para el reenvío de tráfico esté dentro del rango saludable. Al mismo tiempo, la solicitud se reescribe bajo demanda antes de ser reenviada o devuelta al llamador. Este tipo de política se trata principalmente de funcionalidades como limitación de tasa, cortocircuitos, almacenamiento en caché y reescritura.

Limitación de tasa

En el caso de recursos limitados, hay un límite en las capacidades de servicio que la API puede proporcionar. Si la llamada excede este límite, el servicio ascendente puede colapsar y causar algunas reacciones en cadena. La limitación de tasa puede evitar tales casos y puede prevenir efectivamente que las API sean atacadas por DDOS (Ataque de denegación de servicio).

Podemos configurar una ventana de tiempo y el número máximo de solicitudes permitidas en la política de limitación de tasa. La puerta de enlace de API rechazará las solicitudes que excedan el número máximo permitido y devolverá un mensaje de error de límite de tasa. La solicitud no se permitirá hasta que el número de solicitudes sea menor que el límite o se abra la siguiente ventana de tiempo.

La variable para contar las solicitudes se puede establecer en la solicitud o como un encabezado de solicitud particular, por ejemplo, para establecer la política de velocidad correspondiente según diferentes IPs para lograr una mayor flexibilidad.

Cortocircuito

La política de cortocircuito de API puede proporcionar la capacidad de cortocircuito para los servicios ascendentes. Al usar esta política, debe establecer los códigos de estado de los servicios ascendentes saludables y no saludables para que la puerta de enlace juzgue el estado de los servicios ascendentes. Además, también es necesario establecer el umbral de solicitudes para activar un cortocircuito o restaurar la salud. Cuando el servicio ascendente devuelve continuamente códigos de estado no saludables a la puerta de enlace, la puerta de enlace cortocircuitará el servicio ascendente por algún tiempo. Durante este período, la puerta de enlace ya no reenviará solicitudes al servicio ascendente, sino que devolverá directamente un error. Esto puede evitar que los servicios ascendentes reciban solicitudes continuamente debido a errores y proteger los servicios de negocio. Después de este período, la puerta de enlace intentará reenviar la solicitud al servicio ascendente nuevamente. Si todavía devuelve un código de estado no saludable, la puerta de enlace continuará cortocircuitando por un tiempo más largo (duplicado). Hasta que el servicio ascendente devuelva un cierto número de códigos de estado saludables, la puerta de enlace creerá que el servicio ascendente ha vuelto a la salud y continuará reenviando tráfico al nodo ascendente.

En esta política, también es necesario establecer el código de estado y la información que debe devolverse cuando no es saludable. Cuando el servicio ascendente no es saludable, la solicitud se devuelve directamente a nivel de puerta de enlace para proteger la estabilidad de los servicios de negocio.

División de tráfico

La política de división de tráfico puede controlar dinámicamente el reenvío de tráfico a diferentes servicios ascendentes en proporción. Es ventajoso en lanzamientos canarios y despliegues azul-verde.

El lanzamiento canario permite que solo algunas solicitudes usen el nuevo servicio, mientras que la otra parte permanece en el servicio antiguo. Si el nuevo servicio permanece estable, puede aumentar la proporción y transferir gradualmente todas las solicitudes al nuevo servicio hasta que la proporción se cambie completamente para completar la actualización.

El lanzamiento azul-verde es otro modo de lanzamiento, que lanza una nueva versión durante el período pico sin interrumpir el servicio. Tanto la versión antigua como la nueva del servicio coexisten. Normalmente, el entorno de producción (azul) se copia en un contenedor idéntico pero separado (verde). Se lanzan nuevas actualizaciones al entorno verde, y luego se lanzan tanto el verde como el azul a producción. El entorno verde puede probarse y repararse mientras el usuario sigue accediendo al sistema azul. Las solicitudes pueden redirigirse al entorno verde usando alguna política de balanceo de carga. El entorno azul puede mantenerse en espera como una opción de recuperación de desastres o para la próxima actualización.

APISIX admite ambos lanzamientos a través del plugin traffic-split, haciendo que el despliegue de negocios sea más conveniente y confiable.

Reescritura de respuesta

En la arquitectura moderna de microservicios, hay muchos protocolos diferentes entre servicios y no hay formatos uniformes de datos de respuesta. Si esta lógica de transcodificación se implementa por separado en los respectivos servicios, habrá código lógico redundante, lo que es difícil de gestionar. Algunas políticas de reescritura de respuesta pueden manejar la conversión de protocolos, la reescritura del cuerpo de la solicitud y otras lógicas.

APISIX proporciona un plugin de Reescritura de Respuesta para modificar la información del cuerpo o encabezado devuelta por los servicios ascendentes y admite agregar o eliminar encabezados de respuesta, establecer reglas para modificar el cuerpo de la respuesta, etc. Es útil en escenarios como establecer encabezados de respuesta CORS para solicitudes de dominio cruzado o establecer la ubicación para redirección.

Por otro lado, APISIX proporciona proxy-rewrite para la reescritura de solicitudes. El plugin también puede manejar el contenido solicitado que se envía al servicio ascendente. Puede reescribir el URI solicitado, el método, el encabezado de la solicitud, etc., lo que proporciona conveniencia para el procesamiento de negocios en muchos escenarios.

Inyección de fallos

La inyección de fallos es un método de prueba de software que asegura el comportamiento correcto de un sistema introduciendo errores intencionalmente. Por lo general, las pruebas se realizan antes del despliegue para asegurar que no haya fallos potenciales en el entorno de producción. En algunos escenarios de pruebas de caos, es necesario inyectar algunos errores en el servicio para verificar su confiabilidad.

La inyección de fallos de software se puede categorizar en inyección en tiempo de compilación e inyección en tiempo de ejecución. La inyección en tiempo de compilación se refiere a cambiar algún código o lógica al escribir software. La inyección en tiempo de ejecución prueba el comportamiento del software estableciendo errores en el entorno de ejecución del software. La política de inyección de fallos puede simular fallos en las solicitudes de red de la aplicación a través de la inyección en tiempo de ejecución. Al seleccionar una proporción en la política, las solicitudes en esta proporción ejecutarán la lógica de fallo, como devolver con un tiempo de retraso o devolver directamente el código de error y el mensaje de error establecidos al llamador. De esta manera, se puede aumentar la adaptabilidad del software, permitiendo a los desarrolladores ver algunas posibles situaciones de error con anticipación y hacer modificaciones adaptativas a los problemas antes del lanzamiento.

Conversión de protocolos

La política de conversión de protocolos puede convertir entre algunos protocolos estándar, como las solicitudes HTTP comunes y gRPC. Apache APISIX proporciona el plugin grpc-transcode que puede transcodificar y reenviar la solicitud HTTP a servicios de tipo gRPC. La respuesta se devuelve al cliente en formato HTTP. De esta manera, el cliente puede centrarse solo en HTTP sin prestar atención al tipo de gRPC ascendente.

Política de observabilidad

La observabilidad se refiere a la capacidad de medir el estado operativo del sistema a través de los datos de salida del sistema. En algunos sistemas simples, debido a que el número de componentes del sistema es relativamente pequeño, el error se puede encontrar analizando el estado de cada componente cuando ocurre un error. Sin embargo, en un sistema distribuido a gran escala, el número de varios componentes de microservicios es enorme, y es poco realista verificar los componentes uno por uno. En este momento, el sistema necesita ser observable. La observabilidad proporciona visibilidad de un sistema extenso, y cuando ocurre un problema, puede dar a los ingenieros el control que necesitan para identificar el problema.

La recopilación de datos se puede implementar dentro de los componentes de la aplicación. La puerta de enlace de API es la entrada de todo el tráfico, por lo tanto, implementar las características de observabilidad del sistema en la puerta de enlace de API puede reflejar el uso de la API del sistema. Una política de observabilidad de la puerta de enlace de API puede ayudar a todos los equipos:

• Un equipo de ingenieros puede monitorear y resolver problemas de API.
• El equipo de productos puede comprender el uso de la API para descubrir el valor comercial detrás de ella.
• Los equipos de ventas y crecimiento pueden monitorear el uso de la API, observar oportunidades comerciales y asegurarse de que las API entreguen los datos correctos.

Las políticas de observabilidad generalmente se dividen en tres categorías según el tipo de datos de salida: Trazado, Métricas y Registros.

Trazado

En un sistema distribuido a gran escala, la relación entre servicios es intrincada. El trazado (seguimiento de enlaces) puede rastrear el enlace de llamada completo, el análisis de dependencias entre aplicaciones y las estadísticas de solicitudes en aplicaciones distribuidas. Cuando ocurre un problema en el sistema, puede ayudar a los ingenieros a determinar el alcance y la ubicación de la investigación.

La política de trazado puede integrar otros sistemas de seguimiento de enlaces distribuidos en la puerta de enlace de API para recopilar y registrar información. Por ejemplo, integrar servicios como Zipkin y SkyWalking en la puerta de enlace de API para recopilar datos y comunicación entre servicios. Por lo tanto, esta política permite a los ingenieros saber qué registro ver para una sesión específica o llamadas de API relacionadas y verificar el alcance de la solución de problemas.

Métricas

Las métricas se refieren a los datos de observación de un software recopilados durante un intervalo de tiempo de la operación del servicio. Estos datos están estructurados por defecto, lo que facilita la consulta y la visualización. Se puede aprender el estado operativo del sistema a través del análisis de estos datos.

La política de métricas puede integrar servicios como Prometheus o Datadog en la puerta de enlace de API para proporcionar capacidades de monitoreo y alarma para el sistema. Esta política recopila datos durante la operación de la puerta de enlace a través de varias interfaces de la puerta de enlace de API y reporta datos a Prometheus o Datadog. Al visualizar estos datos, los desarrolladores pueden ver el estado de funcionamiento de la puerta de enlace, la información estadística de las solicitudes de API y otros gráficos estadísticos.

Registros

El registro es un registro de texto de eventos del sistema en un momento específico. El registro es el primer lugar para verificar cuando ocurre un problema en el sistema. Los ingenieros confían en el contenido del registro para encontrar lo que le sucedió al sistema y la solución correspondiente. El contenido del registro generalmente se divide en el registro de solicitudes de API y el registro de funcionamiento de la puerta de enlace. El registro de solicitudes de API registra todas las solicitudes de API durante la operación de la puerta de enlace de API. Los ingenieros pueden aprender la información de acceso a la API a través de estos registros y descubrir y solucionar solicitudes anómalas a tiempo. El registro de funcionamiento de la puerta de enlace contiene registros de todos los eventos que ocurrieron durante el funcionamiento de la puerta de enlace. Cuando la puerta de enlace de API es anómala, puede usarse como una base esencial para la solución de problemas.

La política de registro puede almacenar los registros en la puerta de enlace de API en el disco del servidor o enviarlos a otros servidores de registro, como servidores de registro HTTP, servidores de registro TCP, servidores de registro UDP, etc., u otros sistemas de registro como Kafka, RocketMQ, Clickhouse.

Resumen

Este artículo presenta cuatro políticas comúnmente utilizadas en las puertas de enlace de API: autenticación y autorización, seguridad, procesamiento de tráfico y observabilidad. La puerta de enlace de API recibe el tráfico solicitado antes de todos los servicios ascendentes, controla dónde y cómo se reenvían las solicitudes, y rechaza o restringe directamente las solicitudes inseguras y no autorizadas. Las políticas de la puerta de enlace de API pueden configurar todos estos comportamientos.

Para obtener más información relacionada con la puerta de enlace de API, visite blogs y API7.ai para obtener más soporte comercial.