¿Los microservicios deberían ser usuarios?

Navega tus respuestas
13

Estamos tratando de determinar la mejor manera de autorizar a los usuarios en una arquitectura de microservicio, mientras aseguramos que los microservicios tengan permisos limitados. Nuestra arquitectura utiliza un servicio de autorización central para manejar la emisión de tokens JWT.

Tenemos los siguientes requisitos:

  1. Los usuarios deben estar limitados para realizar ciertos roles. p.ej. un usuario solo debe poder crear / modificar / leer el contenido que posee.

  2. Los microservicios deben limitarse solo a los permisos que requieren. p.ej. a un microservicio que solo necesita leer datos de otro servicio se le debe prohibir explícitamente que escriba datos en ese servicio.

Como ejemplo, supongamos que tenemos un sistema donde los usuarios pueden cargar imágenes a un servicio de almacenamiento de imágenes. Tenemos un servicio de etiquetado que etiqueta automáticamente las imágenes con una ubicación. Los usuarios solo pueden CRUD sus propias imágenes. El servicio de etiquetado puede leer cualquier imagen del servicio de almacenamiento de imágenes, sin embargo, no debería poder modificar / eliminar.

¿Cuál es una buena manera de lograr lo anterior utilizando tokens JWT? Algunas soluciones que hemos discutido son:

  1. El servicio de almacenamiento de imágenes expone 2 API, una que está disponible externamente (otorgando acceso CRUD al usuario), y una que está disponible internamente (otorgando acceso interno de solo lectura). Parece inflexible: ¿qué sucede si otro servicio interno necesita acceso de lectura / escritura a todas las imágenes (por ejemplo, una que elimina automáticamente las imágenes explícitas)?

  2. Configuramos dos permisos en el JWT del usuario, uno es CRUD_OwnImages, el otro es READ_ForAnalysis. El servicio de etiquetado puede ver si el usuario tiene permisos READ_ForAnalysis y, de ser así, realizar la solicitud correspondiente. Tenemos otro microservicio que verifica si el usuario tiene CRUD_OwnImages para las operaciones de CRUD en las propias imágenes del usuario. Esto coloca la responsabilidad en cada microservicio para garantizar que el usuario esté restringido a las acciones que requiere. El almacén de imágenes no tiene forma de restringir cada microservicio con este enfoque, por lo que es potencialmente desagradable y propenso a errores.

  3. Le damos al microservicio de etiquetado su propio usuario, con READ_ForAnalysis como permiso. Luego, cuando el servicio de etiquetado solicita imágenes del almacén de imágenes, se le da acceso a ellas, pero se le prohíbe modificarlas. El usuario del usuario solo tiene el permiso CRUD_OwnImages, por lo que puede recuperar y obtener acceso solo a sus imágenes desde la interfaz. Si otro servicio necesita CRUD para todos los datos, podemos proporcionarle CRUD_AllData o similar. Nos gusta este enfoque, ya que cada servicio ahora es responsable de sus propios datos (en lugar de que esa lógica se duplique en múltiples servicios), pero ¿qué sucede si el servicio requiere permisos de usuario y de microservicio? ¿Podemos enviar dos tokens JWT (tanto del usuario como del microservicio) de forma segura? ¿Hay alguna manera de combinar los permisos de forma segura y enviarlos a través? p.ej. ¿El servicio de etiquetado puede leer todas las imágenes pero también puede escribir las imágenes del usuario con la ubicación?

El problema se agrava si la información del usuario se necesita más adelante (2 o 3 microservicios de distancia). ¿Asumimos simplemente que corresponde a los microservicios individuales restringirse a las acciones que necesitan, y no hacerlo explícito?

    
pregunta awr 28.10.2017 - 11:35

1 respuesta

6

En general, la mayor cantidad posible de operaciones debe estar vinculada a un usuario humano real. Obliga a las personas a autenticarse correctamente, busca una estrategia de autorización única y consistente, y es una parte importante de proporcionar un seguimiento de auditoría coherente.

Y, en general, tiene tres tipos de escenarios con microservicios:

1. El usuario entra, carga una foto y necesita ser etiquetado. Genial. El servicio de fotografías solo puede pasar el JWT al servicio de etiquetado (o viceversa, dependiendo de la dirección de su dependencia) y si el usuario carece de derechos para realizar la suboperación, debe realizar la acción adecuada (tal vez cargue la fotografía sin una etiqueta). , tal vez devolver el error, tal vez algo más).

2. El usuario entra, carga una foto y necesita ser etiquetado ... pero no ahora. Genial. Manejas la foto ahora como siempre. Más tarde, cuando se produce el etiquetado (manejo de eventos / mensajes, procesamiento de comandos de estilo CQRS, procesamiento periódico de tareas, lo que sea), el servicio de etiquetado suplantará al usuario (lo más probable es que use un secreto compartido para solicitar un JWT personalizado de auth) y luego la suboperación en nombre del solicitante original (con todos sus permisos y limitaciones). Este método tiene el problema habitual con las operaciones asíncronas en las que es difícil devolverle errores al usuario si las cosas no van bien, pero si está utilizando este patrón para operaciones de servicio cruzado, ya lo habrá resuelto. / p>

3. Algunos subsistemas necesitan hacer cosas fuera del contexto de un usuario. Tal vez tengas algún trabajo nocturno para archivar imágenes antiguas. Tal vez sus etiquetas necesiten ser consolidadas ... En este caso, es probable que desee que cada uno de estos actores tenga su propio pseudo-usuario con permisos limitados y una ID única para el registro de auditoría.

Qué usar variará dependiendo de su escenario, sus necesidades y su tolerancia al riesgo. Y, por supuesto, estos son solo un conjunto incompleto de generalizaciones de trazo amplio.

Pero en general, los microservicios en sí mismos no deberían ser usuarios si es posible.

    
respondido por el Telastyn 28.10.2017 - 19:13

Lea otras preguntas en las etiquetas

¿Es posible lograr el modelo de propiedad de Rust con un contenedor genérico de C ++? Scala como lenguaje para la programación genérica