Kong on Atlas

Introducción a Kong Gateway

Sun, 26 Jul 2026 00:00:00 +0200

Kong Gateway es un API Gateway basado en NGINX y desarrollado en Lua. Actúa como punto de entrada entre los consumidores de una API y los servicios backend, desempeñando el papel de un reverse proxy con capacidades avanzadas para gestionar, proteger y observar el tráfico.

Su función va mucho más allá de reenviar peticiones. Entre las capacidades que proporciona de forma nativa se encuentran:

Autenticación y autorización mediante mecanismos como API Keys, JWT, Basic Auth u OIDC.
Control del tráfico mediante políticas de rate limiting, cuotas y listas de acceso.
Transformación de peticiones y respuestas sin modificar las aplicaciones.
Registro de eventos, métricas y trazas para mejorar la observabilidad.
Exposición centralizada de múltiples servicios a través de un único punto de entrada.

Gracias a este enfoque, las APIs pueden centrarse exclusivamente en la lógica de negocio, mientras que Kong Gateway asume las funcionalidades comunes relacionadas con la seguridad, el control del tráfico, la observabilidad y la gestión de las comunicaciones.

Instalación de Kong con Docker (modo híbrido)

Sun, 26 Jul 2026 00:00:00 +0200

Introducción

En este artículo desplegaremos Kong Gateway 3.10 open source en modo Hybrid utilizando Docker Compose. Esta arquitectura, basada en la separación entre Control Plane (CP) y Data Plane (DP), es una de las opciones recomendadas por Kong para entornos de API Gateway debido a su flexibilidad, escalabilidad y alta disponibilidad.

En un despliegue Hybrid, únicamente el Control Plane mantiene una conexión directa con la base de datos y es responsable de gestionar toda la configuración del gateway mediante la Admin API y Kong Manager. Por su parte, los Data Planes funcionan en modo DB-less y reciben automáticamente la configuración desde el Control Plane a través de un canal seguro protegido mediante mTLS. Esto permite que los Data Planes continúen procesando tráfico incluso si el Control Plane o la base de datos dejan de estar disponibles temporalmente.

Instalación de Kong Ingress Controller (KIC)

Sun, 26 Jul 2026 00:00:00 +0200

En este artículo vamos a pasar de la teoría al despliegue real. El objetivo es instalar Kong Ingress Controller (KIC) en un clúster de Kubernetes, comprobar que Kong Gateway está funcionando correctamente y preparar la exposición externa del proxy para poder publicar aplicaciones desde el propio clúster.

Para mantener el laboratorio simple, usaré una única máquina virtual creada con Vagrant sobre la que ejecutaré un clúster k3s. Esta elección no cambia el funcionamiento de Kong, pero nos permite centrarnos en lo importante: qué instala KIC, por qué el servicio de proxy aparece inicialmente en estado Pending y cómo resolverlo con MetalLB.

Basic Auth en kong

Sun, 26 Jul 2026 00:00:00 +0200

Basic Authentication suele parecer un mecanismo trivial porque solo utiliza un usuario y una contraseña. Sin embargo, para utilizarlo correctamente conviene separar tres ideas: el estándar HTTP, la validación que realiza Kong Gateway y la identidad que Kong asocia a unas credenciales válidas.

En este artículo veremos esas tres capas y construiremos un laboratorio reproducible con Kong Ingress Controller. El objetivo no es limitarse a copiar ficheros y aplicarlos sin cabeza. Primero entenderemos qué representa cada recurso, después lo aplicaremos y finalmente comprobaremos qué ocurre dentro de Kong.

Key Auth en Kong

Sun, 26 Jul 2026 00:00:00 +0200

Una API key suele parecer poco más que una cadena aleatoria que el cliente añade a cada petición. Sin embargo, para utilizarla correctamente conviene separar tres ideas: la credencial que presenta el cliente, la validación que realiza Kong Gateway y la identidad del consumidor (Consumer) asociado a esa credencial.

HMAC Auth en Kong

Sun, 26 Jul 2026 00:00:00 +0200

HMAC Authentication permite demostrar que una petición ha sido construida por un cliente que conoce un secreto compartido sin enviar ese secreto dentro de la petición. Además de autenticar al cliente, la firma permite detectar si los elementos firmados se han modificado durante el transporte.

En este artículo veremos cómo se construye una firma HMAC, cómo la valida Kong Gateway y cómo se relacionan el consumidor y su credencial. Después construiremos un laboratorio reproducible con Kong Ingress Controller y protegeremos la ruta /hmac-auth.

JWT Auth en Kong

Sun, 26 Jul 2026 00:00:00 +0200

Un JSON Web Token permite transportar afirmaciones sobre una identidad dentro de un token firmado. Kong puede verificar esa firma y sus fechas antes de que la petición llegue al backend.

En este artículo separaremos la estructura del token, la credencial criptográfica almacenada en Kong y el consumidor que representa al cliente. Después construiremos un laboratorio reproducible con Kong Ingress Controller, JWT firmado con HS256 y una ruta /jwt.

Este laboratorio continúa exactamente desde el escenario creado en Instalación de KIC. Reutiliza el Gateway kong, el servicio echo y la dirección 192.168.121.200 asignada por MetalLB a kong-gateway-proxy.

Introspección de tokens OAuth 2.0 en Kong

Sun, 26 Jul 2026 00:00:00 +0200

La edición Enterprise de Kong incluye un plugin oficial de OAuth 2.0 Introspection, pero requiere licencia. En este laboratorio resolveremos esa limitación instalando un plugin abierto de la comunidad o código libre sobre Kong Gateway 3.10.

Además del plugin, desplegaremos Keycloak dentro de Kubernetes. Keycloak emitirá access tokens mediante client_credentials y expondrá el endpoint de introspección definido por RFC 7662. Todas las respuestas del artículo proceden de este escenario real.

OpenID Connect en Kong

Sun, 26 Jul 2026 00:00:00 +0200

El plugin oficial OpenID Connect de Kong requiere una licencia Enterprise. En este laboratorio utilizaremos el adaptador abierto de la comunidad o código libre cuongntr/kong-openid-connect-plugin sobre la librería lua-resty-openidc para completar un flujo Authorization Code sin licencia.

Desplegaremos un Keycloak independiente dentro de Kubernetes, iniciaremos sesión con un usuario real y comprobaremos tanto el callback como la reutilización de la cookie. Todas las respuestas del artículo proceden de la VM del laboratorio.

SAML en Kong mediante Keycloak

Sun, 26 Jul 2026 00:00:00 +0200

El plugin oficial saml de Kong requiere una licencia Enterprise. Después de revisar las alternativas abiertas de la comunidad o de código libre no he encontrado un plugin SAML directo, mantenido y compatible con Kong 3.x que resulte razonable recomendar.

En este laboratorio utilizaremos una arquitectura distinta y completamente abierta: Keycloak actuará como Service Provider SAML y como broker de identidad, mientras Kong utilizará el plugin abierto de la comunidad o código libre kong-openid-connect instalado en el artículo anterior. La autenticación del usuario sí ocurre mediante una petición y una respuesta SAML reales. Keycloak valida el XML firmado y entrega a Kong un Authorization Code de OpenID Connect.

Session en Kong

Sun, 26 Jul 2026 00:00:00 +0200

El plugin Session permite que un cliente autenticado reutilice su identidad mediante una cookie. No autentica por sí solo: necesita trabajar junto a otro mecanismo que valide la primera petición.

En este laboratorio combinaremos Session con Key Auth. La primera petición presentará una API key, Kong creará una sesión y las siguientes peticiones utilizarán únicamente la cookie. También configuraremos explícitamente la rama anónima para impedir que una petición sin ninguna credencial llegue al backend.

LDAP Auth en Kong

Sun, 26 Jul 2026 00:00:00 +0200

LDAP Authentication permite que Kong valide directamente un usuario y una contraseña contra un directorio corporativo. El backend no recibe esas credenciales ni necesita implementar el protocolo LDAP.

En este artículo veremos cómo se construye la cabecera de autenticación, cómo localiza Kong al usuario dentro del directorio y cómo proteger una ruta /ldap-auth mediante Kong Ingress Controller.

Este laboratorio continúa desde el escenario creado en Instalación de KIC. Reutiliza el Gateway kong, el servicio echo y la dirección 192.168.121.200 asignada por MetalLB a kong-gateway-proxy.