Si está migrando a la malla de servicios Istio, hay muchos aspectos que deberá considerar, siendo la seguridad el principal. Esta conversación suele comenzar con la gestión adecuada de los certificados y el control de la autenticación mTLS de Istio para su implementación de malla de servicios.
En este blog, exploraremos los pormenores de la malla de servicios Istio, la importancia crítica de configurar correctamente la mTLS de Istio y la gestión de certificados, y cómo Keyfactor Command se integra en Istio para asegurar que cada certificado emitido en su malla de servicios sea de confianza, cumpla con las normativas y esté actualizado.
¿Desea omitir el blog e ir directamente a la demostración? Simplemente haga clic en el botón “Ver ahora” a continuación.
Si todavía me acompaña, profundicemos.
¿Qué es la malla de servicios Istio?
Las arquitecturas de microservicios actuales son increíblemente complejas. A diferencia de las aplicaciones monolíticas, donde se gestiona una única aplicación, los microservicios introducen todo tipo de complejidad.
Estas aplicaciones se dividen en partes, conocidas como “servicios”, que interactúan entre sí. Las comunicaciones de servicio a servicio son lo que hace posible los microservicios, pero a medida que se escala, el desafío es: “¿cómo comprendemos y aseguramos todas estas interacciones a gran escala?”
Istio es una malla de servicios popular que, a un alto nivel, permite abstraer la complejidad de la gestión y seguridad de las conexiones de servicio a servicio. Utiliza un plano de datos para gestionar el tráfico entre servicios y un plano de control para gestionar y asegurar dicho plano de datos. Incluye desde el equilibrio de carga y el comportamiento del tráfico hasta la autenticación entre servicios. Y ahí es donde entra en juego la TLS mutua (mTLS) de Istio.
Istio mTLS: Ventajas y desventajas
A medida que las organizaciones profundizan en los microservicios, los firewalls tradicionales, los equilibradores de carga y los servicios de registro simplemente no pueden seguir el ritmo, y una malla de servicios como Istio empieza a tener más sentido.
Sin embargo, existen muchos desafíos para asegurar una implementación correcta de la seguridad. Uno de los desafíos más significativos es cómo configurar correctamente la encriptación y autenticación TLS.
Istio ofrece TLS mutua “como una solución de pila completa para la autenticación de transporte, que se puede habilitar sin requerir cambios en el código”. Desde el punto de vista de la seguridad, esto es algo positivo. Proporciona una sólida autenticación de carga de trabajo a carga de trabajo, cifra las comunicaciones y previene ataques de intermediario.
Por defecto, Istio utiliza una autoridad de certificación (CA) integrada para generar un certificado raíz autofirmado, que se usa para firmar certificados de carga de trabajo para mTLS. Ahí es donde comienzan los problemas. Con bastante frecuencia, el uso de una CA integrada conlleva deficiencias de seguridad y visibilidad.
El problema de las CA integradas
Más allá de la PKI tradicional, existen varias 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 establecer una CA y comenzar a emitir certificados rápidamente. Sin embargo, en muchos casos, esto se hace sin considerar las implicaciones de seguridad que conlleva. Una vez que el equipo de PKI se entera, los proyectos a menudo se detienen mientras averiguan cómo obtener la política y la supervisión que necesitan.
¿Por qué? Porque los equipos de PKI saben que establecer una CA no se trata solo de “hacer que funcione”.
Por ejemplo, recientemente trabajé con una empresa financiera de Fortune 100. Tenían una PKI de nivel empresarial muy robusta en la que habían invertido mucho tiempo para configurarla correctamente. Y la PKI no es solo tecnología, no solo infraestructura, sino también aspectos como una ceremonia de firma raíz y un flujo de trabajo de políticas CP/CPS sobre quién obtiene los certificados y bajo qué circunstancias pueden usarlos.
Simplemente establecer una CA autofirmada y empezar a generar grandes volúmenes de certificados, sin la aplicación de políticas o la visibilidad que requieren, no era una opción. Necesitaban asegurar que todos los certificados se emitieran desde una raíz de confianza segura (PKI operada por seguridad), cumplieran con las políticas y se gestionaran durante todo su ciclo de vida.
Istio mTLS: Por qué es importante
Entonces, ¿cómo se habilita Istio mTLS cumpliendo con los requisitos de PKI empresarial?
Hemos diseñado Keyfactor Command para que se integre en los flujos de trabajo nativos de Istio, actuando como un plano de control entre su PKI operada por la empresa y su implementación de Istio. En lugar de usar la CA integrada, Istio se comunica directamente con Keyfactor para emitir:
- Certificados mTLS
Utilizando el complemento de Keyfactor para el Agente de Istio, puede asegurar que, a medida que los nodos se inicien, puedan obtener certificados de confianza enrutados internamente desde su PKI privada, CA públicas como DigiCert o Entrust, o incluso PKI alojadas como servicio, como la PKI as-a-Service de Keyfactor.
- Certificados de Ingress/Egress
También podemos aprovisionar certificados para Ingress en el Istio Gateway, o para algo como un NGINX Ingress Controller. Puede aprovisionar certificados desde su PKI, ya sean CA públicas o privadas, y aprovechar esos certificados dentro de las implementaciones de Istio y Kubernetes.
En cuanto a la emisión de certificados, la integración es sencilla. El Proxy Envoy solicita una identidad de carga de trabajo al Agente de Istio, que se enruta en su lugar al Proveedor de Keyfactor. Una vez que Keyfactor Command valida la solicitud y recupera el certificado, lo envía automáticamente de vuelta al Agente de Istio (ver abajo).
Mediante la integración de Keyfactor con Istio, los equipos de DevOps pueden aprovechar Istio sin interrupciones, mientras que los equipos de PKI y seguridad obtienen lo que necesitan, incluyendo:
- 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 fechas de caducidad.
- Inteligencia: Añada atributos potentes a los certificados, más allá del formato estándar X.509, para buscarlos y gestionarlos de forma más eficaz (es decir, propietario de la aplicación, centro de costes, clúster, etc.).
- Política: Aplique políticas y flujos de trabajo coherentes para la emisión de certificados, a fin de cumplir con los requisitos de auditoría internos y externos.
¿Qué sigue?
Si bien el plugin Keyfactor-Istio es potente para los equipos de PKI y seguridad, cada implementación de microservicios es diferente y nunca debería haber una única forma de integrar. Más recientemente, hemos observado un creciente interés en la integración directa con Kubernetes.
Keyfactor se integra actualmente con Kubernetes a través del servidor ACME de Keyfactor y cert-manager. Para obtener más información sobre esta integración, vea la demostración bajo demanda en Google Kubernetes Engine (GKE) a continuación.
