Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DevFest Lima Corriendo cargas e trabajo seguras en GKE con Istio

296 views

Published on

Istio es una nueva plataforma Open Source para conectar, administrar y asegurar microservicios, creado por IBM, Google y Lyft. En esta sesión se proporcionan detalles técnicos generales del proyecto Istio y una parte práctica de varias características de Istio, tales como trafico de ingreso, cumplimiento de políticas, telemetría y seguridad. Además se abordarán practicas que nos permitirán crear contenedores mucho más seguros.

Published in: Technology
  • Be the first to comment

DevFest Lima Corriendo cargas e trabajo seguras en GKE con Istio

  1. 1. Corriendo cargas de trabajo en la nube (GCP) de forma segura con Istio y GKE
  2. 2. Container Security First
  3. 3. Container security • Asegurar los pipelines de contenedores base y aplicaciones. • Asegurar los entornos de despliegue de contenedores y la infraestructura. • Integración con herramientas de seguridad empresarial y cumplimiento o mejora de las políticas de seguridad existentes
  4. 4. Container security guidelines • Whitepaper con muchos guidelines de industria para asegurar aplicaciones en contenedores. • https://www.nist.gov/publications/application-container-security-guide
  5. 5. Container images • Versiones obsoletas e inseguras de software o bibliotecas; aplicaciones con bugs; o incluso malware oculto. • Las herramientas que pueden escanear en busca de estas vulnerabilidades son esenciales, pero las pautas del NIST advierten que estas deben ser conscientes del contenedor, incluida la capacidad de escanear todas las capas de una aplicación en contenedor multicapa. • Las imágenes mal configuradas. Por ejemplo, una imagen puede lanzar un demonio o servicio extraño que permita el acceso no deseado desde la red, o podría estar configurado para ejecutarse con más privilegios de usuario de los necesarios. Los secretos (secrets) almacenados dentro de las imágenes, como las claves de autenticación o los certificados, son otro peligro a tener en cuenta.
  6. 6. Container Registries •NIST recomienda extraer (pull) imágenes solo de fuentes confiables, como Registries de contenedores privados. •Pero un Registry mal configurado también puede ser un problema de seguridad. •El acceso al registro debe requerir conexiones cifradas y autenticadas, preferiblemente utilizando credenciales que estén federadas con los controles de seguridad de red existentes. •Cualquier esfuerzo por proteger las imágenes de los contenedores se puede hacer sin sentido si el registro se puede comprometer fácilmente. •El registro debe someterse a un mantenimiento frecuente para garantizar que no contenga imágenes obsoletas con vulnerabilidades persistentes.
  7. 7. Security Orchestration • Las herramientas de orquestación de contenedores, de las cuales Kubernetes se ha convertido en el ejemplo principal, son otro objetivo potencial de ataque. • Poner mucha atención a la protección de la interfaz administrativa, especialmente en escenarios donde un único orquestador administra múltiples aplicaciones. • Esto puede incluir medidas como la autenticación sólida de dos factores y el cifrado de datos en reposo (at-rest data encryption). • Si no tiene un acceso estrictamente restringido, un usuario negligente o malintencionado podría potencialmente hacer todo tipo de travesuras, desde eliminar aplicaciones hasta lanzar aplicaciones maliciosas.
  8. 8. Tráfico de red • El NIST también recomienda configurar orquestadores para separar el tráfico de la red en redes virtuales discretas, según la sensibilidad del tráfico que se transmite. La idea es que las cargas de trabajo de baja sensibilidad, como las aplicaciones web públicas, deben aislarse de las cargas de trabajo de alta sensibilidad, como el software de procesamiento de pagos. • Además, las cargas de trabajo deben distribuirse de manera que cada host ejecute contenedores solo de un nivel de seguridad determinado. Estas medidas hacen que sea mucho más difícil para un actor malintencionado obtener acceso a datos confidenciales cuando se compromete una aplicación de baja sensibilidad, como un blog.
  9. 9. Recomendaciones NIST: Orquestación • En general, NIST recomienda implementar y organizar clusters de manera segura por defecto. Los ejemplos incluyen el cifrado de extremo a extremo de todo el tráfico de red entre los nodos del clúster y las conexiones de red mutuamente autenticadas entre los miembros del clúster. • El orquestador debe poder introducir nodos en el clúster de forma segura, mantener una identidad persistente para cada nodo a lo largo de su ciclo de vida y aislar y eliminar los nodos comprometidos sin afectar la seguridad general del clúster. Estas medidas son especialmente importantes en entornos de gran escala que abarcan varias organizaciones de red y se escalan a cientos de hosts y miles de contenedores.
  10. 10. Contención al contenedor • Además de las imágenes de contenedores y las aplicaciones dentro de ellos, los contenedores pueden potencialmente convertirse en problemas de seguridad. • Una de las preocupaciones más serias surge cuando los container engines que inician y administran los contenedores (Containerd, CRI-O y rkt) contienen vulnerabilidades. • El NIST advierte que, si no se reparan, tales fallas pueden conducir a situaciones de "escape de contenedores" en las que un atacante podría obtener acceso a otros contenedores o al propio sistema operativo host, por lo que los administradores deberían hacer que la instalación de parches de seguridad en tiempo de ejecución sea una alta prioridad.
  11. 11. Container engine configuration • Los administradores deben prestar especial atención a las muchas opciones configurables disponibles en los container engines. • Un contenedor mal configurado podría tener acceso a demasiados dispositivos, por ejemplo, lo que podría afectar a todos los contenedores que se ejecutan en el host. • Otras opciones de tiempo de ejecución podrían permitir que un contenedor haga llamadas inseguras al sistema, monte directorios confidenciales en modo de lectura y escritura, e incluso comprometa el sistema operativo host.
  12. 12. Container Network security • La infraestructura en contenedores también hace que el análisis del tráfico de red en busca de amenazas de seguridad sea más desafiante. • Los contenedores implementados en múltiples hosts generalmente se comunican a través de una red virtual encriptada y se les asignan direcciones IP dinámicas que cambian continuamente a medida que el orquestador escala la carga de las aplicaciones y balancea la carga. • La detección de anomalías en el tráfico de red en un entorno de este tipo requiere herramientas de filtrado de red especializadas y conscientes de la aplicación.
  13. 13. Bloqueando el SO • En el nivel más bajo de la pila en contenedores, el sistema operativo host representa el objetivo más crítico para los ataques. • Si está comprometido, puede exponer todos los contenedores que se ejecutan en él. Por esta razón, NIST recomienda ejecutar un sistema operativo reducido y específico para contenedores que limite la cantidad de componentes instalados al mínimo de software necesario para crear y administrar contenedores. • Menos componentes significa menos vulnerabilidades potenciales que pueden ser explotadas.
  14. 14. Actualizar el sistema • Un sistema operativo minimizado no será inmune a las vulnerabilidades de seguridad. • Como lo harían con cualquier software, es fundamental que los administradores se mantengan al día con los parches de seguridad del sistema operativo y los apliquen rápidamente a todas las instancias de host en el clúster. • Esto incluye no solo el kernel del sistema operativo, sino también el runtime de ejecución de los contenedores y cualquier otro servicio o componente del sistema recomendado por el proveedor del sistema operativo.
  15. 15. Inmutabilidad del sistema • La configuración adecuada del sistema operativo también es esencial. • Además de montar sistemas de archivos confidenciales como de solo lectura, NIST recomienda ejecutar el SO host como una infraestructura inmutable, sin datos almacenados de forma única y persistente en el host. • El host no debe proporcionar dependencias a nivel de la aplicación, excepto las que se han empaquetado y desplegado como contenedores. Estas medidas hacen del sistema operativo un entorno más confiable, con muchas menos vías de ataque.
  16. 16. Automatización es clave • Proteger un entorno en contenedores es una tarea compleja y una que debe tomarse en serio. Sin embargo, no tiene por qué ser una abrumadora. • Un tema persistente a lo largo de las directrices del NIST es la necesidad de automatizar los procesos de seguridad, particularmente a medida que el entorno se amplía a cientos de hosts y miles de contenedores. • Los orquestadores de contenedores proporcionan parte de esta automatización, pero los administradores de contenedores también deben tratar de automatizar funciones como el análisis de vulnerabilidades y las actualizaciones de software.
  17. 17. Transformación de los procesos • Otra lección aprendida es que el software por sí solo no puede garantizar la seguridad. • La contenerización también requiere que las organizaciones examinen sus procesos y equipos y posiblemente se ajusten al nuevo modelo operativo. • La naturaleza efímera de los contenedores puede requerir procedimientos diferentes a los utilizados con los servidores tradicionales. • Por ejemplo, los equipos de respuesta a incidentes necesitarán conocer los roles, los propietarios y los niveles de sensibilidad de los contenedores implementados antes de que puedan conocer los pasos adecuados a tomar en caso de un ataque continuo.
  18. 18. No ceder, aprender.. • Las amenazas y mitigaciones de seguridad están en constante evolución y ningún recurso puede proporcionar todas las respuestas. • Sin embargo, los lineamientos del NIST ofrece una base sólida y un marco para la política de seguridad para entornos de contenedores. • Vale la pena leerlo para cualquier persona involucrada en la creación, implementación, administración y mantenimiento de contenedores y aplicaciones en contenedores, y es una lectura obligatoria para los profesionales de la seguridad, ya que la industria pasa a la siguiente fase de TI. • https://www.nist.gov/publications/application-container-security-guide
  19. 19. Service Mesh
  20. 20. Definición • Service Mesh (malla de servicios) es una capa de infraestructura configurable para una aplicación de microservicios. • Hace que la comunicación entre instancias de servicio sea flexible, confiable y rápida. La malla proporciona service discovery, balanceo de carga, encriptación, autenticación y autorización, circuit breaker y otras capacidades. • Se implementa al proporcionar una instancia proxy, llamada sidecar, para cada instancia de servicio. Los Sidecars manejan comunicaciones entre servicios, monitoreo, inquietudes relacionadas con la seguridad, cualquier cosa que pueda abstraerse de los servicios individuales. De esta manera, los desarrolladores pueden manejar el desarrollo, soporte y mantenimiento del código de la aplicación en los servicios; Las operaciones pueden mantener la malla de servicio y ejecutar la aplicación.
  21. 21. https://istio.io/
  22. 22. Conceptos
  23. 23. Container Orchestration framework • A medida que se agregan cada vez más contenedores a la infraestructura de una aplicación, se vuelve esencial una herramienta separada para monitorear y administrar el conjunto de contenedores, un marco de orquestación de contenedores. • Kubernetes parece haber acaparado este mercado, incluso con sus principales competidores, Docker Swarm y Mesosphere DC / OS, ofreciendo integración con Kubernetes como alternativa.
  24. 24. Servicios vs. instancias de servicio. • Lo que los desarrolladores crean no es un servicio, sino una definición de servicio o una plantilla para instancias de servicio. • La aplicación crea instancias de servicio a partir de estos, y las instancias hacen el trabajo real. • Sin embargo, el término servicio se usa a menudo tanto para las definiciones de instancia como para las propias instancias.
  25. 25. Proxy sidecar • Un proxy sidecar es una instancia de proxy dedicada a una instancia de servicio específica. • Se comunica con otros proxies sidecar y es administrado por el framework de orquestación.
  26. 26. Service Discovery • Cuando una instancia necesita interactuar con un servicio diferente, necesita encontrar - descubrir - una instancia sana y disponible del otro servicio. • El orquestador de contenedores mantiene una lista de instancias que están listas para recibir solicitudes.
  27. 27. Balanceo de carga • En un Service Mesh, el balanceo de carga funciona desde abajo hacia arriba. • La lista de instancias disponibles mantenidas por el service mesh se clasifica en una pila para colocar las instancias menos ocupadas, es decir, la parte de equilibrio de carga, en la parte superior. • Istio por su lado soporta 3 algoritmos para balanceo: • Round robin • Random • Weighted least request.
  28. 28. Cifrado • El service mesh puede cifrar y descifrar solicitudes y respuestas, eliminando esa carga de cada uno de los servicios. • También puede mejorar el rendimiento al priorizar la reutilización de las conexiones persistentes existentes, reduciendo la necesidad de la creación computacionalmente costosa de nuevas conexiones.
  29. 29. Autenticación y autorizacion • Se puede autorizar y autenticar las solicitudes realizadas desde fuera y dentro de la aplicación, enviando solo solicitudes validadas a instancias de servicio.
  30. 30. Circuit breaker • El service mesh puede aislar las instancias insalubres y luego, gradualmente, las devuelve al grupo de instancias sanas, si es necesario.
  31. 31. Istio y seguridad • Evitar ataques de man-in-the-middle, aplicando cifrado de tráfico. • Proporciona un control de acceso al servicio flexible, necesitan políticas de acceso mutuo y TLS mutuas. • Auditar quién hizo qué y a qué hora.
  32. 32. Objetivos de seguridad de Istio • Security by default: no se necesitan cambios para el código de la aplicación y la infraestructura • Defense in depth: se integra con los sistemas de seguridad existentes para proporcionar múltiples capas de defensa • Zero-trust network: soluciones de seguridad en redes no confiables
  33. 33. Componentes • Citadel: para la gestión de claves y certificados. • Sidecar and perimeter proxies: para implementar comunicación segura entre clientes y servidores. Por ahora implementado con Envoy. • Pilot: para distribuir políticas de autenticación y asegurar la información de nombres a los proxies • Mixer: para gestionar autorizaciones y auditorías.
  34. 34. Arquitectura a alto nivel
  35. 35. Authentication • Transport authentication también conocida como service-to-service authentication: verifica el cliente que realiza la conexión. Istio ofrece TLS mutuo como una solución de stack completo para la autenticación de transporte. Puede activar fácilmente esta función sin requerir cambios en el código de la aplicación. • Origin authentication también conocida como end-user authentication: verifica el cliente original que realiza la solicitud como usuario final o dispositivo. Istio permite la autenticación a nivel de solicitud con la validación de token (JWT) se puede integrar con Auth0, Firebase Auth, Google Auth y personalizadas.
  36. 36. Mutual TLS authentication • Canaliza la comunicación de servicio a servicio a través de los proxys con Envoy del lado del cliente y del servidor. Para que un cliente llame a un servidor, los pasos a seguir son: 1. Istio redirecciona el tráfico saliente desde un cliente hasta el sidecar Envoy local del cliente. 2. El lado del cliente Envoy inicia un handshake mutuo de TLS con el lado del servidor Envoy. Durante el protocolo de enlace, el Envoy del lado del cliente también realiza una verificación de nombres segura para verificar que la cuenta de servicio presentada en el certificado del servidor esté autorizada para ejecutar el servicio de destino. 3. 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. 4. Después de la autorización, Envoy del lado del servidor reenvía el tráfico al servicio del servidor a través de conexiones TCP locales.
  37. 37. Policies and Telemetry • Istio proporciona un modelo flexible para aplicar políticas de autorización y recopilar telemetría para los servicios. • Incluyen cosas tales como control de acceso, sistemas de captura de telemetría, sistemas de cumplimiento de cuotas, sistemas de facturación, etc. • Los servicios tradicionalmente se integran directamente con estos sistemas de back-end, creando un acoplamiento duro y opciones de uso y semántica específicas. • Istio proporciona una abstracción uniforme que hace posible que Istio se interconecte con un conjunto abierto de componentes de infraestructura. • Esto se hace de tal manera que proporcione controles ricos y profundos al operador, sin imponer ninguna carga a los desarrolladores de servicios. • Istio está diseñado para cambiar los límites entre capas con el fin de reducir la complejidad sistémica, eliminar la lógica de políticas del código de servicio y dar control a los operadores. • Mixer es el componente de Istio responsable de proporcionar controles de políticas y recopilación de telemetría:
  38. 38. Herramientas
  39. 39. https://cloud.google.com/blog/products/gcp/network-policy-support-for-kubernetes-with-calico
  40. 40. Istio & GKE https://cloud.google.com/kubernetes-engine/docs/tutorials/installing-istio

×