Microservicios
10
min de lectura
21 de noviembre de 2019

Autenticación de microservicios en acción con Service Mesh

Claudio Eduardo de Oliveira
Jefe Técnico de APIs @Luiza Labs
Trabajo con APIs, microservicios y aplicaciones centradas en la nube.
Más sobre el autor

Contexto

La arquitectura de microservicios es el patrón más famoso en la arquitecturaSoftware hoy en día, hay muchos artículos en internet que tratan de explicar los beneficios e inconvenientes presentes en este estilo de arquitectura.

Llevo un par de años trabajando con microservicios y, para mí, la parte más problemática está relacionada con aplicar la seguridad en este escenario. Hay muchos patrones y herramientas que tratan de resolverlo, la mayoría de ellos están relacionados con los lenguajes y el marco.

autenticación de microservicios

Así tenemos una especie de problemas porque necesitamos aplicar la seguridad en la "Software" capa y podría causar problemas como:

  • Aplicación incorrecta por parte de los desarrolladores
  • Diferentes implementaciones debido a que los frameworks "implican" sus propios patrones como Spring Security o Apache Shiro
  • Por lo general, los idiomas también implican sus propios patrones
  • La adición de certificados en la capa de aplicación añade cierta complejidad a la gestión de estos certificados
  • El marco debe soportar la configuración de certificados
  • Seguridad implementada con diferentes patrones en la Solución
  • Los desarrolladores no conocen las normas de seguridad en profundidad lo que provoca algunas fugas de seguridad.

La seguridad es un requisito no funcional y, en la mayoría de las empresas, hay un área específica que definirá las normas y gestionará la seguridad en todo el ecosistema. Esto significa definir los cortafuegos de la red, los privilegios de la red, etc.

Necesitamos encontrar una manera de crear un estándar de seguridad en nuestra solución de microservicios. ISTIO una implementación de Service Mesh puede ayudarnos a añadir seguridad en la plataforma (a.k.a kubernetes) de una manera fácil.

Entendamos eso!!!

Istio Service Mesh Implementación

La explicación sobre Istio está fuera del alcance de esta entrada del blog. Si necesitas algunas explicaciones sobre puedes encontrarlas en mi artículo anterior.

Tipos de autenticación en ISTIO

Istio ofrece dos tipos de autenticación. El primero se dirige a los usuarios finales y el segundo tiene como objetivo la autenticación de servicio a servicio con certificados, vamos a entender un poco más a fondo estos dos modelos.

Autenticación del usuario final

Esta función pretende autentificar al usuario final, es decir, a la persona que intenta acceder a nuestro sistema o a un simple dispositivo o aplicación que intenta acceder a nuestra solución.

Istio permite la autenticación a nivel de solicitud a través de la especificación JWT, la especificación de seguridad más utilizada para las aplicaciones nativas de la nube. Además, Istio permite una integración sencilla con la especificación OpenId-Connect, otro estándar relevante para la seguridad.

Con un par de configuraciones como JWT Issuer, JWKS URI, y algunas rutas para incluir y excluir somos capaces de proteger nuestros microservicios con el flujo de autenticación OAuth.

Autenticación de servicio a servicio

Este tipo de autenticación a veces se llama autenticación de transporte, verificará la conexión del cliente para comprobar la comunicación. Istio ofrece mtls como una solución completa para la autenticación de transporte.

Citadel es el componente que proporcionará los certificados digitales basados en los estándares SPIFFE para cada sidecar a.k.a envoy proxies presente en el Plano de Datos.

En las próximas secciones, explicaré cómo funciona en el tiempo de configuración y en la ejecución de la autenticación en tiempo de ejecución. Vamos a hacerlo!!!!

FLUJO DE CONFIGURACIÓN

Entendamos cómo el componente Citadel distribuye los certificados digitales para cada pod presente en el Plano de Datos.

Los siguientes pasos describen estas interacciones:

  • Citadel vigila el servidor de la API de Kubernetes, crea un certificado SPIFFE y un par de claves para cada una de las cuentas de servicio existentes y nuevas. Citadel almacena el certificado y los pares de claves como secretos de Kubernetes.
  • Cuando se crea un pod, Kubernetes monta el certificado y el par de claves en el pod según su cuenta de servicio a través del volumen secreto de Kubernetes.
  • Citadel vigila el tiempo de vida de cada certificado y rota automáticamente los certificados reescribiendo los secretos de Kubernetes.
  • El piloto genera información de nomenclatura segura, que define qué cuenta o cuentas de servicio pueden ejecutar un determinado servicio. A continuación, el piloto pasa la información de nomenclatura segura al sidecar Envoy.

Como podemos ver en los pasos anteriores, los certificados digitales están totalmente gestionados por el componente Citadel en la Infraestructura Istio.

Esto es muy importante porque hace que los certificados digitales sean fáciles de gestionar y un punto centralizado para actuar en el caso de que haya algún problema con los certificados.

FLUJO DE AUTENTICACIÓN EN EL PLANO DE DATOS

El flujo de autorización de servicio a servicio sigue los siguientes pasos:

  • Istio redirige el tráfico saliente de un cliente al Envoy local del cliente.
  • El Envoy del lado del cliente inicia un apretón de manos TLS mutuo con el Envoy del lado del servidor. Durante el apretón de manos, el Envoy del lado del cliente también realiza una comprobación de nombre seguro para verificar que la cuenta de servicio presentada en el certificado del servidor está autorizada para ejecutar el servicio de destino.
  • El Envoy del lado del cliente y el Envoy del lado del servidor establecen una conexión TLS mutua, e Istio reenvía el tráfico del Envoy del lado del cliente al Envoy del lado del servidor.
  • Tras la autorización, el Envoy del lado del servidor reenvía el tráfico al servicio del servidor a través de conexiones TCP locales.

Como podemos ver el flujo está fuertemente basado en las características del envoy (sidecar).

Conclusiones

En este post, he tratado de explicar un poco sobre la autenticación de microservicios con Istio.

Como podemos ver hace nuestra configuración de seguridad en un punto centralizado, es decir en un par de archivos, pero la autenticación ocurre de manera distribuida en enviados o plano de datos.

¡Gracias por leer!