Cómo proteger y escalar Istio mTLS

Si te estás pasando a la malla de servicios de Istio, hay muchas cosas que tendrás que tener en cuenta: la seguridad es la primera. Esa conversación suele comenzar con la forma de gestionar correctamente los certificados y controlar la autenticación mTLS de Istio para la implementación de la malla de servicios.

En este blog, exploraremos los entresijos de la malla de servicios Istio, por qué es fundamental configurar correctamente Istio mTLS y la gestión de certificados, y cómo Keyfactor Command se conecta a Istio para garantizar que todos los certificados emitidos en su malla de servicios sean de confianza, conformes y estén actualizados.

¿Quiere saltarse el blog y pasar directamente a la demostración? Haz clic en el botón "Ver ahora".

Si sigues conmigo, entremos en materia.

Las arquitecturas de microservicios actuales son increíblemente complejas. A diferencia de las aplicaciones monolíticas, en las que tienes una única aplicación que gestionar, los microservicios introducen todo tipo de complejidades.

Estas aplicaciones se dividen en partes, conocidas como "servicios", que interactúan entre sí. Las comunicaciones entre servicios es lo que hace posible los microservicios, pero a medida que se amplían y se amplían, el reto pasa a ser "¿cómo entendemos y aseguramos todas estas interacciones a escala?".

Istio es una popular malla de servicios que, a alto nivel, permite abstraer la complejidad de gestionar y proteger las conexiones entre servicios. Utiliza un plano de datos para gestionar el tráfico entre servicios y un plano de control para gestionar y proteger el plano de datos. Incluye todo, desde el equilibrio de carga y el comportamiento del tráfico hasta la autenticación entre servicios. Y ahí es donde entra en juego Istio mutual TLS (mTLS).

A medida que las organizaciones comienzan a profundizar en los microservicios, los cortafuegos tradicionales, los equilibradores de carga y los servicios de registro simplemente no pueden seguir el ritmo, y una malla de servicios como Istio comienza a tener más sentido.

Sin embargo, existen muchos retos a la hora de garantizar la correcta implantación de la seguridad. Uno de los más importantes es cómo configurar correctamente el cifrado y la autenticación en TLS .

Istio ofrece TLS mutuo "como una solución de pila completa para la autenticación de transporte, que se puede activar sin necesidad de cambios de código." Desde el punto de vista de la seguridad, esto es positivo. Proporciona una autenticación fuerte de carga de trabajo a carga de trabajo, encripta las comunicaciones y previene los ataques man-in-the-middle.

Por defecto, Istio utiliza una autoridad de certificación (CA) integrada para generar un certificado raíz autofirmado, que se utiliza para firmar certificados de carga de trabajo para mTLS. Ahí es donde empiezan los problemas. La mayoría de las veces, el uso de una CA integrada conlleva deficiencias de seguridad y visibilidad.

Más allá de la PKI tradicional, hay una serie de CA integradas disponibles en herramientas DevOps y servicios en la nube. Para empezar, Kubernetes, Istio y HashiCorp Vault ofrecen una CA integrada.

A los equipos de DevOps les encanta cómo estas herramientas les permiten crear una CA y empezar a emitir certificados rápidamente. Sin embargo, en muchos casos, esto se hace sin tener en cuenta las implicaciones para la seguridad. Una vez que el equipo de PKI se da cuenta, los proyectos a menudo se paralizan mientras averiguan cómo conseguir la política y la supervisión que necesitan.

¿Por qué? Porque los equipos de PKI saben que poner en marcha una CA no consiste sólo en "hacerla funcionar".

Por ejemplo, hace poco trabajé con una empresa financiera de la lista Fortune 100. Tenían una PKI de nivel empresarial muy sólida a la que habían dedicado mucho tiempo. Tenían una PKI de nivel empresarial muy sólida a la que habían dedicado mucho tiempo. Y PKI no es sólo tecnología, no es sólo infraestructura, sino también cosas como una ceremonia de firma raíz y un flujo de trabajo de políticas CP/CPS en torno a quién obtiene los certificados y en qué circunstancias pueden utilizarlos.

La simple creación de una CA autofirmada y la producción de grandes volúmenes de certificados, sin la aplicación de políticas ni la visibilidad que necesitaban, no era una opción. Necesitaban asegurarse de que todos los certificados se emitían desde una raíz de confianza segura (PKI operada por seguridad), cumplían las políticas y se gestionaban durante todo su ciclo de vida.

Entonces, ¿cómo habilitar Istio mTLS cumpliendo los requisitos de PKI de la empresa?

Hemos diseñado Keyfactor Command para que se adapte a los flujos de trabajo nativos de Istio, actuando como plano de control entre su PKI operada por la empresa y su implementación de Istio. En lugar de utilizar la CA integrada, Istio se comunica directamente con Keyfactor para emitir:

• Certificados mTLS
  Utilizando el complemento Keyfactor del agente Istio, puede asegurarse de que, a medida que los nodos se ponen en marcha, pueden obtener certificados de confianza enrutados internamente desde su PKI privada, CA públicas como DigiCert o Entrust, o incluso PKI alojada como servicio, como Keyfactor PKI as-a-Service.

• Certificados Ingress/Egress
  También podemos aprovisionar certificados para Ingress en Istio Gateway, o algo como un NGINX Ingress Controller. Puede aprovisionar certificados desde su PKI, ya sean CA públicas o privadas, y aprovechar esos certificados en las implementaciones de Istio y Kubernetes.

En lo que respecta a la emisión de certificados, la integración es sencilla. El proxy Envoy solicita una identidad de carga de trabajo al agente Istio, que en su lugar la envía al proveedor Keyfactor . Una vez que Keyfactor Command valida la solicitud y recupera el certificado, lo devuelve automáticamente al Agente Istio (véase más abajo).

Mediante la integración Keyfactor-Istio, los equipos de DevOps pueden aprovechar Istio sin interrupciones, mientras que los equipos de PKI y seguridad obtienen lo que necesitan, incluido:

• Visibilidad: Obtenga un inventario completo de los certificados emitidos a través de CA públicas y privadas, y realice un seguimiento centralizado de datos críticos como ubicaciones, claves y algoritmos, y caducidad.
• Inteligencia: Añada potentes atributos a los certificados más allá del formato estándar X.509 para buscarlos y gestionarlos con mayor eficacia (por ejemplo, propietario de la aplicación, centro de costes, clúster, etc.).
• Política: Aplique políticas y flujos de trabajo coherentes de emisión de certificados para cumplir los requisitos de auditoría interna y externa.

Aunque el complemento Keyfactor-Istio es potente para los equipos de PKI y seguridad, cada despliegue de microservicios es diferente, y nunca debería haber una única forma de integración. Más recientemente, hemos visto un mayor deseo de integrarse directamente en Kubernetes.

Keyfactor se integra actualmente con Kubernetes a través del servidor Keyfactor ACME y cert-manager. Para obtener más información sobre esta integración, vea la demostración a petición en Google Kubernetes Engine (GKE) a continuación.