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.

1. Corriendo cargas de trabajo
en la nube (GCP) de forma
segura con Istio y GKE

3. Container Security First

4. 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

6. Container
security guidelines
• Whitepaper con muchos guidelines de industria para asegurar
aplicaciones en contenedores.
• https://www.nist.gov/publications/application-container-security-guide

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. 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

21. Service Mesh

22. 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.

23. https://istio.io/

24. Conceptos

25. 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.

26. 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.

27. 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.

28. 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.

29. 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.

30. 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.

31. 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.

32. Circuit breaker
• El service mesh puede aislar las instancias insalubres y
luego, gradualmente, las devuelve al grupo de instancias
sanas, si es necesario.

33. 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.

35. 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

36. 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.

37. Arquitectura a alto nivel

38. 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.

39. 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.

40. 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:

41. Herramientas

47. https://cloud.google.com/blog/products/gcp/network-policy-support-for-kubernetes-with-calico

48. Istio & GKE
https://cloud.google.com/kubernetes-engine/docs/tutorials/installing-istio