Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Cloud Native MX Meetup - Asegurando tu Cluster de Kubernetes

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.

  • Loggen Sie sich ein, um Kommentare anzuzeigen.

Cloud Native MX Meetup - Asegurando tu Cluster de Kubernetes

  1. 1. Asegurando tu cluster de Kubernetes Cloud Native MX - Meetup CDMX
  2. 2. Asegurando tu cluster de Kubernetes (Incompleto….) Cloud Native MX - Meetup CDMX
  3. 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. 4. Container security • Images • Image Registries • Container Runtimes • Container Orchestration • Host Operating Systems • No usar Root como usuario!! (Dockerfile)
  5. 5. Image Security • Package vulnerability • Secrets exposure • No incluir estos en la construcción de las imágenes • Authenticity
  6. 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. 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. 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. 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.
  10. 10. 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.
  11. 11. 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
  12. 12. 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
  13. 13. 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.
  14. 14. 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
  15. 15. 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/)
  16. 16. 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/
  17. 17. • 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.
  18. 18. Politica de red global para denegar el acceso a la red
  19. 19. Bloqueamos el trafico en el namespace ‘engineering’
  20. 20. Permitir el acceso a HTTP endpoints
  21. 21. 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/
  22. 22. Istio • Autenticación • Transporte (mutual TLS con Citadel) • Origen (JWT, uso de proveedores externos y personalizados) • Politicas de autenticación
  23. 23. 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/)
  24. 24. ¡Me faltaron los Secrets!

×