MeetUp de seguridad en arquitectura de micro-servicios. ArqConfMDQ Enero 2020

Qué emoción, hicimos el primer meetup con formato de meetup, jajaj. Lo cierto es que ArqConfMDQ logró por primera vez una reunión que salió del formato de presentación. Esta vez, con formato de charla informal, en un grupo reducido (fuimos 18) logramos llevar adelante un intercambio super enriquecedor de experiencias, ideas y lo mejor… PROBLEMAS.

Vinieron buenos amigos y nuevos amigos del ámbito local, nacional y de empresas de alcance internacional.

Agradecemos a la empresa aDomicilio por prestarnos el lugar e invitar unas ricas pizzas.

charlapizzas

Ahora bien, ¿cómo fue el meetup?, Si bien se plantearon temas comunes para la comunidad de desarrolladores que trabajan con micro-servicios, el estado del arte de estas arquitecturas y las tecnologías que lo soportan, hacen que las formas de responder a esos temas tengan distintos posibles enfoques, con distintas herramientas y con muchos “depende”.

Estuvo genial, arrancamos sentando una base del concepto de micro-servicios basados en la definición del US National Institute of Standards and Technology

microservicio standard institute

Y no podíamos dejar de mencionar la opinión de Martin Fowler

microservicio M Fowler

esto nos permitió sentar los ejes de la charla que denominamos Security concerns

  • Attack surface expanded
  • Increased request
  • Responsibility allocation
  • Multiple layer communication
  • Third party products
  • Log & monitoring

Fuimos pasando por cada uno de estos temas y se vieron distintas arquitecturas y tecnologías para resolverlos y los tradeoffs necesarios.

Un gran tema que abarcó esos concerns fue el uso de gateway. Claramente aporta a la seguridad desde el momento que se asume como único punto de acceso, de esta manera podríamos establecer una red privada donde solo se puede acceder a los microservicios desde el gateway. Pero cómo afecta  esto a la comunicación entre microservicios servicios. Se establecieron como válidos dos esquemas,

  • autorización y autenticación en el gateway y luego seguridad por infra
  • que los microservicios también adopten funciones de seguridad, validen token y tengan lógica de autorización.

Entonces conversamos de autorización de acceso al endpoint o bien que la respuesta tenga contenidos restringidos según el rol. En general, el acuerdo común es que si un dato no puede ser accedido por determinado rol estaría bien que haya lógicas de autorización en el microservicio. Es decir, la responsabilidad de seguridad a nivel de dato queda dentro del scope del microservicio.

Una manera de integrar el control de seguridad es que el service mesh pase x el API Gateway en general acordamos que el service mesh debe apuntar al uso de sidecars o librerías y reservar al API Gateway para que reciba invocaciones externas.

En este punto entramos en un gran mundo, rest vs graphql. No llegamos a un acuerdo, coincidimos que está muy bueno pero que plantearon que se delega mucho en el cliente y en general había cierto esceptisismo, (personalmente creo que no había caso testigo que bajara una opinión tajante). Sí quedo claro que es una herramienta poderosa que propone una solución a temas de composición y que el enfoque es superador a perder las buenas prácticas de REST.

La charla quedó super abierta, cerramos con unas pizzas y cervezas y salieron muchos temas más a seguir tratando. Planteamos la posibilidad de para los próximos meetups con este formato hacer un cierre con conclusiones para compartir.

Saludos, hasta el próximo meetup.

 

 

 

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s