sa-kong

Kong es una capa de API escalable y de código abierto (también conocida como API Gateway o API Middleware). Kong se ejecuta frente a cualquier API RESTful y se puede ampliar mediante complementos, que proporcionan funcionalidad y servicios adicionales más allá de la plataforma principal.

Kong fue originalmente creado en Mashape para asegurar, gestionar y ampliar más de 15,000 API y microservicios para su mercado de API, que genera miles de millones de solicitudes al mes para más de 200,000 desarrolladores. Hoy en día, Kong se utiliza en implementaciones críticas en organizaciones grandes y pequeñas.

Escalable: Kong se puede escalar fácilmente de manera horizontal agregando más máquinas, lo que significa que su plataforma puede manejar prácticamente cualquier carga mientras mantiene baja la latencia.

Modular: Kong se puede extender añadiendo nuevos complementos, que se configuran fácilmente a través de una API de administración RESTful.

Funciona en cualquier infraestructura: Kong se puede ejecutar en cualquier lugar. Puede desplegar Kong en la nube o en entornos locales, incluyendo configuraciones de un solo centro de datos o múltiples centros de datos y para API públicas, privadas o solo por invitación.

Probablemente ha escuchado que Kong está construido sobre Nginx, aprovechando su estabilidad y eficiencia. Pero, ¿cómo es esto posible exactamente?

Para ser más precisos, Kong es una aplicación Lua que se ejecuta en Nginx y se hace posible gracias al módulo lua-nginx. En lugar de compilar Nginx con este módulo, Kong se distribuye junto con OpenResty, que ya incluye el módulo lua-nginx. OpenResty no es un fork de Nginx, sino un conjunto de módulos que extienden sus capacidades.

Esto establece las bases para una arquitectura plugable, donde los scripts Lua (denominados "complementos") pueden habilitarse y ejecutarse en tiempo de ejecución. Por esta razón, nos gusta pensar en Kong como un modelo de arquitectura de microservicios: en su núcleo, implementa una abstracción de base de datos, enrutamiento y gestión de complementos. Los complementos pueden vivir en bases de código separadas y ser inyectados en cualquier parte del ciclo de vida de la solicitud, todo en unas pocas líneas de código.

Nota: la versión comunitaria de Kong no incluye interfaz de usuario. Podrías considerar alguna interfaz web de código abierto, como https://github.com/PGBI/kong-dashboard o https://github.com/pantsel/konga/.

Según nuestra experiencia, https://github.com/PGBI/kong-dashboard utiliza procesos de desarrollo y lanzamiento más robustos, aunque konga se ve más creativa.

# Instalar Kong Dashboard
npm install -g kong-dashboard

# Iniciar Kong Dashboard
kong-dashboard start --kong-url http://kong:8001

# Iniciar Kong Dashboard en un puerto personalizado
kong-dashboard start \
  --kong-url http://kong:8001 \
  --port [puerto]

  roles:
    - {
        role: "sa-kong"
      }

Avanzado:

  roles:
    - {
        role: "sa-kong",
        kong_version: 2.0.1,
        kong_activated_plugins: "bundled,oidc",
        kong_luarocks_plugins:
          - kong-oidc
        kong_admin_http: "0.0.0.0:8001",
        kong_admin_https: "127.0.0.1:8444",
        kong_proxy_http: "0.0.0.0:8000",
        kong_proxy_https: "0.0.0.0:8443",
        kong_pg_host: "127.0.0.1",
        kong_pg_port: 5432,
        kong_pg_user: kong,
        kong_pg_password: kong,
        kong_pg_database: kong
      }

Notas desordenadas para futuros usos.

Complementos de terceros que podrían interesarte

kong-oidc

https://github.com/nokia/kong-oidc

kong-oidc es un complemento para Kong que implementa la funcionalidad del Proveedor de Confianza de OpenID Connect (RP).

Autentica a los usuarios frente a un Proveedor de OpenID Connect utilizando la Descubrimiento de OpenID Connect y el Perfil Básico de Cliente (es decir, el flujo de Código de Autorización).

Mantiene sesiones para usuarios autenticados aprovechando lua-resty-openidc, ofreciendo así una opción configurable entre almacenar el estado de la sesión en una cookie del navegador del lado del cliente o usar uno de los mecanismos de almacenamiento del lado del servidor como shared-memory|memcache|redis.

Admite almacenamiento en caché a nivel de servidor de documentos de Descubrimiento resueltos y Tokens de Acceso validados.

En general, necesitarás un Servidor de Autorización que soporte OIDC con un cliente registrado para comenzar. Aquí puedes usar soluciones como Keycloak/Gluu o las proporcionadas por terceros (por ejemplo, el de Google https://developers.google.com/identity/protocols/OpenIDConnect; en este caso, usarías tu cuenta de Google para iniciar sesión).

Después de obtener el ID de cliente/secreto y la URL de Descubrimiento OIDC (ver https://auth0.com/docs/tutorials/openid-connect-discovery), puedes habilitar el complemento.

Un ejemplo de curl podría verse así:

curl -XPOST -d 'name=oidc' -d 'config.client_id=<client_id>' -d 'config.client_secret =<client_secret>' -d 'config.discovery=<OIDC_Discovery_url>' http://kong:8001/plugins

Después de eso, antes de acceder a cualquier API registrada en Kong, serás redirigido al Servidor de Autorización para iniciar sesión allí. Esto también proporcionará una solución SSO para todas las API en Kong.

Esto convierte a Kong en un Proveedor de Confianza de OIDC, de modo que cualquier API detrás de Kong puede beneficiarse de la protección de autenticación OIDC sin implementar los flujos OIDC.

En la práctica, utiliza el flujo de autorización de código (https://auth0.com/docs/api-auth/grant/authorization-code). Si un usuario no autenticado intenta acceder a una API en Kong, en la que este complemento esté habilitado, será redirigido a la página de inicio de sesión en el AS (la ubicación del AS se establece a través del campo de descubrimiento en la configuración). Después de iniciar sesión con éxito, el AS te brinda un código de acceso y te redirige de nuevo a Kong. Kong utiliza el código de acceso para obtener el token de acceso, el token de identificación y el token de actualización.

Los tokens se almacenan en una cookie de sesión cifrada. La clave de cifrado es una combinación de algunas variables (agente de usuario, dirección IP remota...) y el session_secret, que se puede definir al habilitar el complemento (ver https://github.com/nokia/kong-oidc/blob/master/kong/plugins/oidc/schema.lua). Este campo es opcional, pero muy recomendado y debe ser aleatorio.

Si el complemento de Kong ve que ya hay una cookie establecida, la desencriptará y validará los tokens. La actualización del token de acceso usando el token de actualización también es manejada por este complemento.

También agrega cierta información a la solicitud para el servidor ascendente. Establece el encabezado X-Userinfo con la salida del Endpoint de Userinfo (https://connect2id.com/products/server/docs/api/userinfo).

En general, el flujo y la lógica de OIDC están implementados por el paquete lua-resty-openidc.

Es sin estado, no se utiliza el almacén de datos de Kong. Por lo que, si utilizas esta cookie en otro navegador o desde otra máquina, no funcionará. Para invalidar los tokens puedes hacer un llamado a la URL raíz /logout (http:///logout). Esto activará una llamada al Endpoint de Fin de Sesión OIDC.

Los tokens originales no se envían al servidor ascendente, pero el encabezado X-Userinfo contiene declaraciones del token de identificación (pero sin las firmas del AS).

Nota adicional - si vas a usar el complemento en Kong con docker, necesitarás

FROM kong:1.4.0-alpine
LABEL description="Alpine + Kong 1.4.0 + complemento kong-oidc"
RUN apk update && apk add git unzip luarocks
RUN luarocks install kong-oidc

en la imagen, los complementos pueden ser activados usando la variable de entorno KONG_PLUGINS

KONG_PLUGINS=oidc

Ejemplo de implementación en kubernetes

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-kong
  annotations:
    plugins.konghq.com: oidc
spec:
  rules:
  - http:
      paths:
      - path: /graphql
        backend:
          serviceName: corphub-graphql-service
          servicePort: 8082
---
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: kong-oidc
  labels:
    global: "true"
config:
  client_id: kong
  client_secret: XXX
  discovery: http://keycloak:8180/auth/realms/master/.well-known/openid-configuration
plugin: oidc

Kong Middleman

https://github.com/pantsel/kong-middleman-plugin

Un complemento de Kong que habilita una solicitud HTTP POST adicional antes de proxear la original.

kong-external-oauth

https://github.com/mogui/kong-external-oauth

Un complemento de Kong, que te permite usar un proveedor externo de Oauth 2.0 para proteger tu API.

$ luarocks install external-oauth

Para que Kong sepa que debe buscar el nuevo complemento, tendrás que añadirlo a la propiedad custom_plugins en tu archivo de configuración.

custom_plugins:
    - external-oauth

Puedes añadir el complemento con la siguiente solicitud:

$ curl -X POST http://kong:8001/apis/{api}/plugins \
    --data "name=external-oauth" \
    --data "config.authorize_url=https://oauth.something.net/openid-connect/authorize" \
    --data "config.scope=openid+profile+email" \
    --data "config.token_url=https://oauth.something.net/openid-connect/token" \
    --data "config.client_id=SOME_CLEINT_ID" \
    --data "config.client_secret=SOME_SECRET_KEY" \
    --data "config.user_url=https://oauth.something.net/openid-connect/userinfo" \
    --data "config.user_keys=email,name,sub" \
    --data "config.hosted_domain=mycompany.com" \
    --data "config.email_key=email"

| Parámetro del formulario | predeterminado | descripción | | --- | --- | --- | | name | | nombre del complemento external-oauth | | config.authorize_url | | URL de autorización del proveedor OAUTH (a la que serás redirigido cuando no estés autenticado) | | config.scope | | ámbito OAUTH de la solicitud de autorización | | config.token_url | | URL del proveedor Oauth para solicitar el token de acceso | | config.client_id | | ID del Cliente OAUTH | | config.client_secret | | Secreto del Cliente OAUTH | | config.user_url | | URL del proveedor oauth utilizada para recuperar la información del usuario y también verificar la validez del token de acceso | | config.user_keys
Opcional | username,email | claves para extraer del json devuelto por el endpoint user_url, también se agregarán a los encabezados del servidor ascendente como X-OAUTH-XXX | | config.hosted_domain | | dominio al que deben pertenecer los usuarios para iniciar sesión. Ignorado si está vacío | | config.email_key | | clave que se verificará para el dominio hospedado, tomada del endpoint de userinfo | | config.user_info_periodic_check | 60 | tiempo en segundos entre verificaciones de tokens |

Además de las user_keys, se añadirá un encabezado X-OAUTH-TOKEN con el token de acceso del proveedor.

Backend de Postgres

pg_hba.conf después de las modificaciones se verá similar a:

local   all             postgres                                peer

# TIPO  BASE_DE_DATOS  USUARIO          DIRECCIÓN               MÉTODO

# "local" es solo para conexiones de socket de dominio Unix
local   all             all                                     md5
# local   all             all                                     peer
# Conexiones locales IPv4:
host    all             all             127.0.0.1/32            password
host    all             all             127.0.0.1/32            md5
# Conexiones locales IPv6:
host    all             all             ::1/128                 md5
# Permitir conexiones de replicación desde localhost, por un usuario con el
# privilegio de replicación.
#local   replication     postgres                                peer
#host    replication     postgres        127.0.0.1/32            md5
#host    replication     postgres        ::1/128                 md5

Referencias de terceros

Dashboards

Konga             https://github.com/pantsel/konga              (Kong > 1)
Kong-Dashboard    https://github.com/PGBI/kong-dashboard        (Kong > 0.9)

Herramientas de configuración declarativa

kongfig           https://github.com/mybuilder/kongfig          (Kong < 1)
Deck              https://github.com/hbagdi/deck                (Kong >= 1)

Uso con flujo de trabajo de ansible galaxy

Si instalaste el rol sa-kong usando el comando

ansible-galaxy install softasap.sa-kong

el rol estará disponible en la carpeta library/sa-kong.

Por favor, ajusta la ruta en consecuencia.

     - {
         role: "softasap.sa-kong"
       }

Derechos de autor y licencia

El código está licenciado bajo la licencia BSD de 3 cláusulas y la Licencia MIT. Elige la que mejor se adapte a tus necesidades.

Contáctanos:

Suscríbete para recibir actualizaciones sobre los roles en FB

Únete al canal de discusión en gitter en Gitter

Descubre otros roles en http://www.softasap.com/roles/registry_generated.html

visita nuestro blog en http://www.softasap.com/blog/archive.html