jsonwebtoken - ¿Cómo uso una API Gateway junto con microservicios y JWT?

kong jwt

Question

Por la tarde ustedes,

Solo busco a alguien para verificar mi trabajo. ¿Es la siguiente una forma efectiva de asegurar microservicios?

Premisa

Descomponiendo nuestra aplicación monolítica y la API monolítica Partner en microservicios orientados a funciones empresariales específicas. Lo más probable es que sean aplicaciones expressjs pequeñas que se ejecutan en un contenedor de docker, en beanstalk elástico, quién sabe. Vivirán en algún lugar :)

Estoy buscando ya sea posicionar a Kong como mi API Gateway o usar AWS API Gateway para encapsular los detalles de mis microservicios. Además, simplemente se siente bien.

El plugin JWT para Kong verificará la firma del JWT y luego pasará el customer_id en el encabezado al microservicio. También debo mencionar que tenemos desarrolladores de terceros que participarán en la diversión de integración también. Aquí hay un boceto básico de lo que veo que sucede:

Implementación

1. Generar "consumidores" para cada plataforma y desarrollador de terceros que tenemos. (Aplicación web, aplicación móvil y los actuales socios de integración que tenemos. Nota: no busco crear consumidores para cada usuario que inicie sesión. Aunque ciertamente es más seguro, esto agrega mucho trabajo. Además, si se da cuenta cómo sacar el secreto de mi API Gateway claramente tengo otros problemas)
2. Deja que Kong verifique la solicitud por mí. Algo así como un gorila en la puerta, no hay autorización, solo autenticación.
3. No necesito saber que el token es válido una vez que llega al microservicio, solo puedo usar algún middleware para decodificarlo y usar una lógica personalizada para decidir si este usuario realmente debería estar haciendo lo que está tratando de hacer.

Material adicional

• Hay un buen complemento de control de acceso para Kong. Nuestra aplicación y nuestra aplicación móvil se ejecutarían con privilegios de "Dios", pero definitivamente podría bloquear a los desarrolladores con rutas y métodos específicos.

• Revocar el acceso de terceros será fácil, revocar el acceso de los usuarios finales no será tan simple a menos que esté dispuesto a invalidar todos los JWT a la vez generando un nuevo secreto. Quizás puedo limitar el tiempo de token a 10 minutos más o menos y hacer que nuestras aplicaciones verifiquen si están caducadas, obtener un nuevo token y luego continuar con la solicitud original. De esta forma puedo "marcar" en la base de datos o algo así y no dejar que se genere el JWT.

• SSL utilizado en todas partes, JWT se almacena en una cookie solo SSL en el navegador web y no hay información confidencial almacenada en ninguno de los reclamos.

Gracias chicos.

Answer 1

Recientemente trabajé en una solución a esta pregunta y premisa, refactorizando un gran monolito en múltiples servicios en una arquitectura de AWS.

No hay ningún método correcto, incorrecto o definitivo para esta pregunta.
Sin embargo, implementamos una solución muy similar a la descrita en la pregunta anterior.
Espero que esta respuesta pueda brindar un buen sentido de orientación para alguien que está viendo esto por primera vez.

Así es como lo hicimos ...

¿Qué necesitamos de una puerta de enlace API?

1. Altamente disponible
2. Seguro
3. Performant
4. Autoritario
5. Escalable

Solución 1: puerta de enlace API de AWS

pros

1. Solución administrada de alta disponibilidad.
2. No necesita preocuparse por la escalabilidad.
3. Admite SSL y dominios personalizados.
4. Autoritativo a través de lambda y IAM.
5. Se juega bien con otros servicios de AWS.
6. Admite versiones de API desde el primer momento.
7. Fácil monitoreo con CloudWatch.

contras

1. El tráfico no se puede enrutar directamente a una red interna (segmento privado de VPC), lo que significa que se requerirá una puerta de enlace adicional.
2. Lento, nuestro punto de referencia mostró que cada solicitud a través de API Gateway agregaba latencia de 100-150 ms.

Solución 2: Kong

pros

1. Escalable, pero necesita ser implementado y administrado por nuestro lado.
2. Admite SSL y dominios personalizados.
3. Autoritativo a través de complementos, con soluciones para JWT y OAUTH2 ya empaquetadas.
4. API RESTful para una fácil integración con nuestro servidor de autenticación.
5. Extensible, en caso de que necesitemos alguna lógica personalizada.
6. Rápido, nuestro punto de referencia mostró que cada pedido a través de Kong agregaba 20-30 ms de latencia.

contras

1. Requiere administración por nuestra parte (actualizaciones, implementación, mantenimiento).
2. Para lograr HA, se requiere un punto final adicional, en la forma de un equilibrador de carga para enrutar el tráfico a los GW reales.
   
   

Implementación

Decidimos ir con Kong.
El principal problema con la solución alojada fue la imposibilidad de enrutar el tráfico a nuestra red privada, donde también alojamos una zona DNS privada.
Además, la naturaleza extensible de Kong nos permitió crear complementos personalizados con lógica que es relevante para nuestras soluciones.
Trabajamos con un ALB para realizar operaciones por turnos entre varias instancias de Kong en diferentes AZ para lograr redundancia y alta disponibilidad.
La configuración de API se guarda en un Postgres RDS que también es interno y multi AZ.

Fluir

1. El cliente se autentica contra nuestro servidor de autenticación. El servidor de autenticación es un micro servicio detrás de Kong GW con un flujo ascendente públicamente expuesto.
2. El servidor de autenticación crea un consumidor con un JWT para el cliente individual.
3. El servidor de autenticación responde con el JWT.
4. El cliente solicita acceso desde una API con el JWT, el tráfico se enruta a través de Kong.
5. Kong verifica el JWT y enruta la solicitud al micro servicio con información sobre el consumidor.
6. El micro servicio responde al cliente.

Otro

1. Revocar el acceso del usuario es tan fácil como eliminar el token.
2. No se almacena información confidencial en las reclamaciones de JWT.
3. Todos los servicios se conocen entre sí a través de una zona DNS privada .
   
   

Esquema: