aspectos de las aplicaciones y la configuración son necesarias a verificar para ejecutar cargas de trabajo en un entorno seguro. Desde el ensamblaje de las imágenes de los contenedores a la seguridad de ETCD y acceso externo a elementos del cluster son importantes a considerar.

1. Asegurando tu
cluster de Kubernetes
Cloud Native MX - Meetup CDMX

2. Asegurando tu
cluster de Kubernetes
(Incompleto….)
Cloud Native MX - Meetup CDMX

3. Disclaimer
• En el contexto de seguridad hay muchos factores y temas que atender.
• En esta charla hablaremos como de algunos de ellos, pero da pie a muchas mas
charlas, el tema da para mucho.
• Infra
• VM, bare-metal, cloud publico/privado
• Sistemas operativos, redes…
• Plataforma
• Container engine, Container orchestration

4. Container security
• Images
• Image Registries
• Container Runtimes
• Container Orchestration
• Host Operating Systems
• No usar Root como usuario!! (Dockerfile)

5. Image Security
• Package vulnerability
• Secrets exposure
• No incluir estos en la construcción de las imágenes
• Authenticity

6. Container Runtimes
• Container Scaping
• Falta de user namespaces
• https://docs.docker.com/engine/security/userns-remap/
• Configuración que exponga información del host

7. ¿Kubernetes?
• ¿Tiene visibilidad de los pods desplegados? ¿Cómo se comunican los clusters o
los pods?
• ¿Tiene alguna forma de detectar el mal comportamiento del tráfico entre
contenedores?
• ¿Cómo podemos saber si cada pod individual se comporta "normalmente"?
• ¿Cómo se le notifica o se le alerta cuando algunos pods o contenedores de
servicios internos comienzan a escanear puertos internamente o intentan
conectarse a la red externa al azar?
• ¿Está familiarizado con los posibles vectores de ataque en una implementación
basada en Kubernetes?

8. K8S Role Based Access Control (RBAC)
• RBAC proporcionan un control granular de los recursos.
• Estos pueden controlar el acceso a las cargas de trabajo de la aplicación,
así como a los recursos de Kubernetes.
• Las herramientas de administración como OpenShift pueden agregar
capacidades adicionales, pero dependen o usan los controles básicos de
Kubernetes debajo.
• Es fundamental configurar adecuadamente los controles de acceso para
evitar el acceso no autorizado a los componentes de Kubernetes, como el
API server, así como a las cargas de trabajo de las aplicaciones.

9. Networking en K8s
• FUNDAMENTOS DE REDES DE KUBERNETES
• Cada pod tiene su propia dirección IP enrutable. Kubernetes (en realidad, su plugin de red) se
encarga de enrutar todas las solicitudes internamente entre los hosts al pod apropiado. El
acceso externo a los pods de Kubernetes se puede proporcionar a través de un Service,
balanceador de carga o Ingress Controller, que Kubernetes enruta al pod apropiado.
• Kubernetes usa iptables para controlar las conexiones de red entre pods (y entre nodos),
manejando muchas de las reglas de red y reenvío de puertos. De esta manera, los clientes no
necesitan hacer un seguimiento de las direcciones IP para conectarse a Kubernetes. Además,
la asignación de puertos se simplifica enormemente (y se elimina principalmente) ya que cada
pod tiene su propia dirección IP y su contenedor puede escuchar en su puerto nativo.
• Con todas estas redes superpuestas (overlay) manejadas dinámicamente por Kubernetes, es
extremadamente difícil monitorear el tráfico de la red, y mucho menos asegurarlo. Aquí hay un
ejemplo de cómo funciona la red Kubernetes.

11. Vulnerabilidades y vectores de ataque
• Contenedores comprometidos. Una configuración incorrecta o vulnerabilidad
de la aplicación le permite al atacante ingresar a un contenedor para comenzar a
buscar debilidades en la red, los controles de proceso o el sistema de archivos.
• CONEXIONES NO AUTORIZADAS ENTRE PODS. Los contenedores
comprometidos pueden intentar conectarse con otros pods en ejecución en el
mismo host u otros para probar o lanzar un ataque. Si bien la red de Capa 3
controla las direcciones IP de pod de una lista blanca, puede ofrecer cierta
protección, los ataques a direcciones IP confiables solo pueden detectarse con
el filtrado de red de Capa 7.
• EXTRACCIÓN DE DATOS DE UN POD. Shell inverso en un pod que se conecta
a un servidor de control y un túnel de red para ocultar datos confidenciales.

12. Vulnerabilidades y vectores de ataque
• CONTENEDOR COMPROMETIDO EJECUTANDO UN PROCESO MALICIOSO.
Los contenedores generalmente tienen un conjunto limitado y bien definido de
procesos en ejecución, pero un contenedor comprometido puede iniciar malware
como cripto minería o procesos sospechosos como el escaneo de puertos de red.
• SISTEMA DE ARCHIVO DE CONTENEDORES COMPROMETIDO. Un atacante
puede instalar bibliotecas / paquetes vulnerables para explotar el contenedor. Los
archivos confidenciales también se pueden cambiar. Una vez vulnerado, se puede
intentar una escalada de privilegios a root u otra brecha.
• NODO WORKER COMPROMETIDO. El host en sí mismo puede verse
comprometido, al igual que cualquier contenedor que se ejecute en él. Por
ejemplo, la vulnerabilidad del kernel de Linux Dirty Cow permitió a un usuario
escalar al privilegio de root. https://en.wikipedia.org/wiki/Dirty_COW

13. Pasos de seguridad recomendados
previos al despliegue
• Usar espacios de nombres
• Restringir las capacidades de Linux
• Habilitar SELinux (https://en.wikipedia.org/wiki/Security-Enhanced_Linux)
• Utilice Seccomp (https://en.wikipedia.org/wiki/Seccomp)
• Configurar Cgroups
• Utilice un sistema operativo host mínimo
• Actualizar parches del sistema

14. Acciones en Kubernetes
• PROTEJER EL API SERVER. Configure RBAC para el API Server y/o crear manualmente
reglas de firewall para evitar el acceso no autorizado. No exponerlo en Internet sin SSL.
O no exponerlo del todo.
• RESTRINGIR LOS PERMISOS DE KUBELET. Configure RBAC para Kubelets y rotación
de certificados para asegurar Kubelet.
• AUTENTICACIÓN PARA TODOS LOS PUERTOS EXTERNOS. Revise todos los puertos
accesibles externamente y elimine los puertos innecesarios. Requerir autenticación para
esos puertos externos necesarios. Para servicios no autenticados, restrinja el acceso
mediante una lista blanca.
• LIMITE O QUITE EL ACCESO A LA CONSOLA (Dashboard). No permita el acceso a la
consola / proxy a menos que esté configurado correctamente para el inicio de sesión del
usuario con contraseñas seguras o autenticación de dos factores.

15. Aislamiento de red, segmentación
y detección de amenazas
• Verificar conexiones de red de pos y la política de seguridad
• Detección de ataques contra contenedores, ya sea que se originen
externa o internamente.
• La captura de paquetes para los pods de Kubernetes, para permitir el
análisis forense, el registro y la depuración de aplicaciones

16. Herramientas a usar
• POLÍTICA DE RED. La política de red de Kubernetes proporciona segmentación automatizada L3 / L4 (dirección
IP / puerto). Se requiere un plugin de red que admita la aplicación de políticas de red como Calico.
• ISTIO. Es un service mesh para administrar la comunicación de servicio a servicio, que incluye enrutamiento,
autenticación, autorización y encriptación. Istio proporciona un marco sólido para administrar el enrutamiento de
servicios, pero no está diseñado para ser una herramienta de seguridad para detectar ataques, amenazas y
eventos de contenedores sospechosos.
• GRAFAES. Proporciona una herramienta para definir una forma uniforme de auditar y gobernar la cadena de
suministro de software moderna. Las políticas se pueden rastrear y aplicar con la integración a herramientas de
terceros. Grafeas puede ser útil para gobernar la canalización de CI / CD, pero no está dirigido a la gestión de
políticas de seguridad en tiempo de ejecución. https://grafeas.io/
• CLAIR. Clair es una herramienta simple para escanear vulnerabilidades de imágenes, pero carece de integración de
registro y soporte de flujo de trabajo. Aunque, se acaba de liberar hoy (12/Nov/2019) Quay, que permite integración
con Clair.
• BENCHMARK CIS para Kubernetes. Las verificaciones de cumplimiento y auditoría del Benchmark CIS para
Kubernetes Security están disponibles para su uso. (https://www.cisecurity.org/benchmark/kubernetes/)

17. Calico
• Es una solución Open Source para networking y
seguridad de red para contenedores, máquinas
virtuales y cargas de trabajo nativas basadas en host.
Se ejecuta en Kubernetes, OpenShift, Docker EE,
OpenStack y servicios bare metal.
• https://docs.projectcalico.org/

18. • La política de red de Calico facilita el bloqueo de comunicación, por lo
que el único tráfico que fluye es el tráfico que nosotros permitimos.
Podíamos decir que Calico es un firewall personal que se reconfigura
dinámicamente en tiempo real a medida que ejecutamos nuevos servicios
o hacemos scale-up o scale-down.
• El motor de políticas de Calico puede aplicar el mismo modelo de
políticas en la capa de red del host y (si usa Istio & Envoy) en la capa de
service mesh, protegiendo la infraestructura de cargas de trabajo
comprometidas y protegiendo sus cargas de trabajo de infraestructura
comprometida.

19. Politica de red global para
denegar el acceso a la red

20. Bloqueamos el trafico en
el namespace ‘engineering’

21. Permitir el acceso
a HTTP endpoints

22. Calico para Seguridad
• Zero trust security
• Usar Service Account para acceso
• Bloqueo/desbloqueo de trafico saliente
• Restrigit el acceso externo con iOS, segmentos…
• Prevención de ataques DoS
• https://docs.projectcalico.org/v3.10/security/

23. Istio
• Autenticación
• Transporte (mutual TLS con Citadel)
• Origen (JWT, uso de proveedores externos y personalizados)
• Politicas de autenticación

24. Prácticas de seguridad
• Configurar las especificaciones de los Pods para descargar siempre la
imagen (AlwaysPullImages)
• Denegar que los pods puedan ejecutar comandos (kubectl exec/attach)
• DenyEscalatingExec
• Configurar el SecurityContext
• (https://kubernetes.io/docs/tasks/configure-pod-container/security-
context/)

26. ¡Me faltaron los Secrets!