VLCSofting 2021 - HARD AS A POD 落. HARDENING DE DESPLIEGUES EN KUBERNETES CON MUCHO FLOW

HARD AS A POD
Una guía paso a paso de Ciberseguridad en empresas productivas
HARD AS A POD

HARD AS A POD
DESPLIEGUES EN K8S CON
MUCHO FLOW
Como construir PODS más fuertes, duros y resilientes

Arquitecto de software y Security Advocate en @ITI_TIC
Profesor en Máster Big Data Analytics en UPV
Profesor en curso de especialista universitario en el Esquema Nacional de
Seguridad en Univ. Mondragón
Formador (+20 cursos)
Speaker (+30 charlas)
@DogDeveloper
Francisco Javier Barrena Castillo

BREVÍSIMA INTRODUCCIÓN
A DOCKER Y KUBERNETES

Contenedores
• El cambio se ha convertido en una constante
• Las organizaciones han cambiado sus ciclos de desarrollo y han pasado de una release de
software al trimestre, a varias releases por semana.
• Con cada nueva versión las aplicaciones pueden variar, aunque ligeramente, y por tanto es
necesario aplicar controles de seguridad continuos y automatizados.
• Otro de los retos que se plantean es la necesidad de pensar y adoptar la seguridad por
parte de equipos que tradicionalmente no la han considerado una prioridad.
• La seguridad debe comenzar desde el desarrollo de software y, por tanto, cuando las agencias y
empresas públicas definan su modelo DevSecOps deben pensar en inyectar controles de
seguridad no intrusivos en cada una de las etapas de los pipelines.
• Como recomendación general, estos controles deberán permitir alertar, dando visibilidad de
los riesgos de seguridad a los equipos involucrados, pero también deberán permitir bloquear
un despliegue si no se cumplen las políticas de seguridad fijadas para un entorno concreto.
docker

docker
• Docker es una plataforma que permite empaquetar aplicaciones y
todas sus dependencias para poder desplegarlas fácilmente
• Estos paquetes reciben el nombre de contenedores

docker
• Docker permite describir un contenedor (en realidad es una
imagen) a través de un ﬁchero de descripción Dockerﬁle

Docker container
• Un contenedor es una instancia ejecutable de una imagen
• Es decir, a partir de una imagen puedo generar N contenedores
que ejecuten el contenido de esa imagen
• Los contenedores son:
• Aislados por defecto (no se ven los unos a los otros)
• Configurables:
• Almacenamiento
• Visibilidad
• Redes
• Volúmenes, etc.
• Lo que defino es una imagen, lo que ejecuto es un contenedor

Container registry
• Las imágenes se suelen almacenar en repositorios llamados
container registry
• Cuando algún desarrollador quiere hacer uso de una imagen en
concreto, se la descarga de uno de estos repositorios
• El repositorio oﬁcial de Docker se llama Docker Hub
• https:/
/hub.docker.com

BREVÍSIMA INTRODUCCIÓN
A KUBERNETES

qué es kubernetes
• Kubernetes es un orquestador open source de contenedores
Docker, desarrollado inicialmente por Google, pero donado a la
CNCF y mantenido por la comunidad
• Ejecuta y administra aplicaciones dockerizadas en un clúster de
CPUs o GPUs
• Permite múltiples acciones, como:
• Programación de despliegues
• Escalado automático
• Monitorización de contenedores, Etc…
• Es ””interoperable”” entre proveedores cloud (Amazon, Azure,
Google Cloud, Rackspace…)
• Y por eso se ha convertido en el estándar de facto para desarrollos
basados en cloud

Por qué es importante kubernetes
• Kubernetes es una herramienta muy potente para desplegar
aplicaciones en producción
• Tanto en entornos cloud, como en entornos on-premise
• Se ha convertido en el core de los principales IaaS / PaaS
• Se han construido un montón de aplicaciones que corren,
monitorizan o usan Kubernetes

Por qué es importante kubernetes

Características principales de k8
• Escalado / Autoescalado
• Descubrimiento de servicios y balanceo de carga
• Autorreparación
• Despliegues y rollbacks automáticos
• Planiﬁcación
• Gestión y conﬁguración de secrets
• Orquestación del almacenamiento

Características principales de k8
• Escalado / Autoescalado
• Descubrimiento de servicios y balanceo de carga
• Autorreparación
• Despliegues y rollbacks automáticos
• Planificación
• Gestión y configuración de secrets
• Orquestación del almacenamiento

pod
• Un Pod es la unidad mínima de despliegue de K8s en un nodo
• Contiene uno o más contenedores que deben ejecutarse juntos
• Puedo deﬁnir un Pod como quiera, incluso con contenedores que no
tendrían porqué ejecutarse juntos
• El modelo es abierto, me permite conﬁgurar lo que quiera
• Pero la idea de un Pod es que contenga contenedores relacionados, para
aprovechar el principio de localidad
• Además, es la unidad mínima de replicamiento, por lo que también tiene
sentido desde ese punto de vista
• Un Pod comparte almacenamiento y dirección IP
• Los Pods son efímeros. Cuando un Pod se cae o se cierra, toda la
información que contienen desaparece

volumes
• Los Pods son efímeros
• La información que almacenemos en ellos no es persistente
• Pensad en que los Pods son la RAM de Kubernetes
• Un volumen es un almacenamiento persistente que se puede
asociar a un Pod
• Pensad en que los volúmenes son los discos duros de Kubernetes
• En realidad, el concepto de volumen está totalmente fusilado del
propio Docker
• Los volúmenes se definen en el mismo fichero YAML del Pod

volumes
• En la sección volumes se definen los volúmenes disponibles
• En la sección volumeMounts indicamos los puntos de montaje
• Existen varios tipos de volúmenes
• El más sencillo es hostPath
• Corresponde a un directorio o fichero del nodo donde se crea el Pod
• En nuestro ejemplo, se ha montado en el directorio /home del contenedor
• Solo es interesante cuando el Pod no va a estar en multinodo ya que
• La información no se replica entre nodos
• Por tanto, el contenido puede variar (y variará) dependiendo del nodo donde se aloje
POD
1
10.1.1.1
Fichero1.zip
POD
2
10.1.1.3
Fichero2.zip
https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes

namespaces
• Instalar un clúster de Kubernetes On Premise (por ejemplo, sobre
bare metal o sobre Open Stack) no es sencillo
• Hay un montón de consideraciones de sistemas que hay que tener en
cuenta
• No es cómodo tener múltiples clústers de Kubernetes corriendo
en una empresa, uno para cada entorno (dev, test, pre, pro)
• Es más caro de instalar
• Es más caro de mantener
• La única justificación puede ser la de aislar el entorno, y la visibilidad, para
diferentes proyectos à Se recomienda que PRO esté aislado al menos
• Un namespace es un clúster de K8s virtual que corre sobre un
clúster físico.
• De este modo no tenemos que mantener múltiples clústers de K8s

namespaces
• Podemos consultar los namespaces activos en nuestro clúster
físico a través del siguiente comando

deployment
• El deployment es la unidad de más alto nivel que podemos
gestionar en Kubernetes
• Permite definir diferentes funciones
• Control de réplicas
• Escalabilidad de pods
• Actualizaciones
• Despliegues automáticos
• Rollback a versiones anteriores
• ¿cómo se define?
• Con un YAML (kilométrico), por supuesto

deployment
Cuántos ReplicaSets antiguos queremos
conservar para poder hacer rollback
Modo de actualización
• RollingUpdate: actualiza los pods a la
nueva versión
• Recreate: elimina los pods antiguos y
crea los nuevos

• Las herramientas y metodologías de seguridad tradicionales no sirven para proteger
las aplicaciones nativas en la nube basadas en contenedores
• Sistemas ya no interviene de forma directa en el despliegue de estas aplicaciones
• Son los propios desarrolladores los que se encargan del ciclo completo de despliegue
• Por otra parte, el despliegue ya no depende de una infraestructura concreta
• Puede terminar en cualquier máquina dentro del clúster de computación
• Si además es Cloud público, puede incluso acabar en cualquier centro de datos dentro de la región
• Los desarrolladores y los equipos de DevOps desempeñan un papel fundamental en
el diseño y la implementación de aplicaciones nativas en la nube, y a menudo actúan
al margen de los equipos de seguridad y tecnología tradicionales
• à BREAK THE SILOS
Seguridad en contenedores

• La seguridad debe integrarse con una infraestructura y unas herramientas que van
cambiando según lo decidan los desarrolladores
• La rápida adopción de tecnologías basadas en contenedores se justifica dado que las
organizaciones tienen más opciones de computación disponibles
• Implementaciones de varias nubes o de nube hibrida
• Kubernetes
• Contenedores como servicio (CaaS)
• Funciones sin servidor (serverless / FaaS)
• Los entornos nativos en la nube están sujetos a cambios constantes y de gran magnitud. Para
los equipos de seguridad, la automatización es imprescindible para proteger los
microservicios que utiliza una organización, que se multiplican y varían con el tiempo

• Encontramos retos de seguridad únicos, asociados al uso de contenedores.
• La anatomía de un contenedor favorece tremendamente la automatización
• Docker por ejemplo identifica cómo se empaqueta, cómo se almacenan y despliegan aplicaciones
• Debido a que los contenedores encapsulan todas sus dependencias, se pueden mover
muy fácilmente desde un entorno de desarrollo, a test y de ahí a producción.
• Por ejemplo, Google lanzan 2 billones de contenedores por semana en su infraestructura
• Esto plantea retos de escalabilidad, y tenemos que pensar en qué controles se pueden establecer
para securizar despliegues masivos
• La aproximación tradicional de crear y mantener controles o políticas de seguridad estáticas para
cada entorno, deja de ser válida, principalmente porque es INMANTENIBLE en el tiempo

• Por tanto, dado que el cambio se ha convertido en una constante…
• Las organizaciones han cambiado sus ciclos de desarrollo y han pasado de una release de
software al trimestre, a varias releases por semana.
• Con cada nueva versión las aplicaciones varían, y por tanto es necesario aplicar controles de
seguridad continuos y automatizados.
• Otro de los retos que se plantean es la necesidad de pensar y adoptar la seguridad
por parte de equipos que tradicionalmente no la han considerado una prioridad.
• La seguridad debe comenzar desde el desarrollo de software y, por tanto, cuando las
empresas definan su modelo DevSecOps deben pensar en inyectar controles de seguridad no
intrusivos en cada una de las etapas de los pipelines.
• Como recomendación general, estos controles deberán permitir alertar, dando visibilidad de
los riesgos de seguridad a los equipos involucrados, pero también deberán permitir bloquear
un despliegue si no se cumplen las políticas de seguridad fijadas para un entorno concreto.

• Las imágenes son instantáneas estáticas de un sistema operativo (y las dependencias
necesarias para ejecutar la aplicación) en un instante de tiempo
• La ’estaticidad’ de las imágenes las hace proclives a falta de actualizaciones de seguridad
• Una imagen creada hoy, con todo actualizado, puede estar libre de vulnerabilidades conocidas
por días o semanas después de su creación
• Pero inevitablemente se descubrirán vulnerabilidades en la imagen o en alguno de sus componentes
• En un entorno no contenerizado, simplemente se actualizan las máquinas
• Pero las imágenes son inmutables, por lo que se requiere hacer una nueva versión y subirla al repositorio de
imágenes para que los sistemas que las usan se actualicen
• Y cambiar la configuración del orquestador para que apunte a las nuevas imágenes actualizadas…
Riesgo 1 à vulnerabilidades con imágenes

• Se requiere de herramientas y procesos específicos para la gestión
de vulnerabilidades en imágenes
• Las herramientas tradicionales cuentan con ciertas asunciones,
como la durabilidad del host y los mecanismos de actualización de
aplicaciones, que no aplican a las tecnologías de contenedores
• Estas herramientas a menudo son incapaces de detectar
vulnerabilidades dentro de los contenedores, dándonos una falsa
sensación de seguridad
vulnerabilidades con imágenes

•Algunos aspectos clave a tener en cuenta
• Policy-driven. Las organizaciones deben ser capaces de crear quality
gates en todo el ciclo de vida de la imagen que garanticen que solo
las imágenes que cumplen el estándar de seguridad puedan ser
utilizadas
• Integración con el ciclo de vida completo de las imágenes
• Visibilidad de vulnerabilidades en todas las capas de la imagen, no
solo de la imagen base, también de frameworks, software de teceros
y software propio
vulnerabilidades con imágenes

contramedida 1 – vulnerabilidades con imágenes

Container vulnerability scanning
44
• Las imágenes Docker también
son código
• Las imágenes base pueden tener
vulnerabilidades importantes
• Es necesario que hagamos un
escaneo de esas imágenes, del
mismo modo que hacemos un
escaneo del código que
contendrán esas imágenes

Herramientas open source
45
• Anchore
• También versión Enterprise
• Grype (https://github.com/anchore/grype)
• Proporciona un CLI para escanear imágenes Docker
• Instalación (MacOS)
• La ejecución es sencillísima
• grype nombredelaimagen:version

Herramientas open source
46
• Anchore
• También versión Enterprise
• Grype (https://github.com/anchore/grype)
• Proporciona un CLI para escanear imágenes Docker
• Instalación (MacOS)
• La ejecución es sencillísima
• grype nombredelaimagen:version

grype
47
• Se puede configurar para que falle si se detectan
vulnerabilidades de una severidad concreta
• Devuelve esto:
• Y hace fallar el pipeline!
• Severidades posibles:
• Negligible
• Low
• Medium
• High
• Critical

Herramientas similares
48
• Clair (Open Source)
• https://github.com/quay/clair
• Snyk (Free para proyectos Open Source)
• https://snyk.io/
• OpenSCAP
• https://github.com/OpenSCAP
• Dagda (también escanea contra malware!!)
• https://github.com/eliasgranderubio/dagda

Herramientas similares
50
• Clair (Open Source)
• https://github.com/quay/clair
• Snyk (Free para proyectos Open Source)
• https://snyk.io/
• Falco
• https://sysdig.com/opensource/falco/
• OpenSCAP
• https://github.com/OpenSCAP
• Dagda (también escanea contra malware!!)
• https://github.com/eliasgranderubio/dagda

• Un clásico
• Ejemplos
• Imagen que corre todo con privilegios de administrador
• Imagen que tiene instalado un SSH daemon
• Imagen con credenciales por defecto
• …
• Lo de siempre en sistemas, pero ahora en imágenes. Not new.
Riesgo 2 – image missconfiguration

• Contramedidas recomendadas
• Se deben configurar las imágenes para que corran con usuarios sin privilegios (o
con los mínimos necesarios)
• Añadir al proceso de build la validación de la configuración de las imágenes,
incluyendo las recomendaciones del vendor
• Informes continuos, constantemente actualizados, centralizados y monitorización
constante de imágenes para identificar, lo más prematuramente posible,
debilidades y riesgos
• Policy-driven. Procesos y automatismos que permitan prohibir la ejecución de
máquinas que no cumplan con el quality-gate
• Uso de imágenes base solo de fuentes de confianza (oficiales)
contramedida 2 – image missconfiguration

• Contramedidas recomendadas
• Actualización frecuente de las imágenes base para reducir la superficie de ataque
• Usa siempre como imagen base tecnologías específicas para contenedores
• No uses Ubuntu, Debian ni sistemas operativos de propósito general
• En su lugar, utiliza Alpine Linux, Windows Nano Server, etc.
• Es más engorroso, porque tienes que instalar dependencias básicas, pero reducen muchísimo la superficie de ataque
• Nunca, amig@, nunca habilites SSH en un contenedor
• Los contenedores deben correr de forma inmutable
• Habilitar acceso por SSH abre la puerta a cambios, que violan este principio
• Y además exponen al contenedor a un enorme riesgo de red
• Si tienes que acceder a un contenedor, utiliza el API del runtime…

Pero no añadas paquetes software, ni actualices, ni
hagas nada más que consultar, recuerda la
inmutabilidad de los contenedores.

RECOMENDACIONES DE
SEGURIDAD PARA
KUBERNETES

La hiperconvergencia
Firewall
Request
API
Gateway
R
e
q
u
e
s
t
Request
EC2 Instance
S3 Buckets
Request
1500 VCPUs
x1500
> 4000 pods
x4000
Edge Node
Factory
Resource
Edge Node
Factory
Resource
AD Node

A qué deberíamos aspirar…
Telemetry
Event
Buffer
PROCESS
TAG
NORMALIZE
VALIDATE
PARSE
ENRICH ANALYZE
ALERT
ACT!!
TRAIN?
Security
Command
Centre

Lo primero es lo primero: el rbac

rbac
• Se manejan 3 elementos
• Clientes
• Usuarios y service accounts
• Recursos a los que un usuario o service account necesita acceder
• Pods, secrets, nodes, volumes…
• Operaciones que puede hacer sobre esos recursos
• List, Create, Watch, Get, Delete, Patch
• Al final es la definición de las operaciones que se pueden realizar
sobre un recurso concreto
• Los roles se pueden definir a nivel de namespace (RoleBinding), o
a nivel de cluster (ClusterRoleBinding)

Hardening en kubernetes
• Implementar TLS para proteger el tráfico entre los nodos y el
control plane
• Implementar autenticación y autorización para los usuarios del
clúster
• Cifrar los secrets
• Los secrets se almacenan codificados en base64, pero no encriptados
• Cualquier usuario con acceso al cluster puede obtener todos los secretos
sin esfuerzo
• Se pueden utilizar herramientas específicas como Hashicorp Vault
• O sealed-secrets
https://github.com/bitnami-labs/sealed-secrets

utiliza un secret manager
• Existen en el mercado herramientas que se encargan de
almacenar con seguridad claves, tokens, certificados y datos
sensibles
• Cuando esos datos se requieren, se lanza una consulta a esta
herramienta, que devuelve los datos encriptados
• Con una librería, se desencriptan en tiempo de ejecución esas
claves, justo antes de ser utilizadas
• Es una MUY BUENA PRÁCTICA, cuando desarrollo se
acostumbra a trabajar con ella, los leaks bajan a prácticamente
cero
• Ejemplo: HashiCorp Vault
https://www.vaultproject.io/

• Security Context
• Define la configuración de control de acceso y privilegios para un POD
• Incluye:
• Control de acceso discrecional: permisos para acceder a un objeto, como un fichero, basado
en userId y/o GroupId
• Ejecución como contenedor privilegiado, o no
• Linux Capabilities: da a un proceso algunos privilegios, pero no todos los de root
• AppArmor: utiliza perfiles de programas para restringir las capabilities a determinados
programas
• SAecComp: filtra llamadas de procesos al sistema
• AllowPrivilegeEscalation: controla cuando un proceso puede ganar más privilegios que su
proceso padre
• readOnlyRootFileSustem: monta el sistema de ficheros del contenedor en modo solo lectura

• Security Context
• Para añadir un security context en un
pod, hay que utilizar el campo
securityContext
• Las políticas del securityContext
aplican a todos los contenedores que
hayan dentro del pod

• Resource Quotas
• Define los límites de recursos que pueden utilizar los pods

• Restricción del tráfico de red entre pods
• De forma predeterminada todos los pods en un clúster pueden
comunicarse entre sí (incluso entre namespaces)
• Restringir el acceso de la red a los servicios hace que sea mucho más difícil
para los atacantes moverse de forma lateral dentro de tu clúster
• Ofrece a los servicios cierta protección contra la denegación accidental o deliberada del servicio
• Dos formas de controlar el tráfico:
• Istio
• Políticas de red de Kubernetes

• Restricción del tráfico de red entre pods
• El tráfico ENTRANTE a un pod desde una red externa al clúster se
permite si hay una regla de ingress definida para ese pod
• El tráfico SALIENTE de un pod hacia una red externa al clúster se permite
si hay una regla de egress definida para ese pod
• El tráfico ENTRE PODS se permite si y solo si hay una regla egress
definida entre el pod A y el B, y a la inversa, una regla de ingress entre el
pod B y el A, explícitamente
• Se recomienda empezar definiendo las políticas de ingress antes que la
de egress

• Es una de las partes más complicadas de securizar, dado que las
herramientas de seguridad tradicionales no están diseñadas para
monitorizar la ejecución de los contenedores, ya que no pueden
ver su interior y mucho menos establecer una línea base de cómo
debería comportarse
• Es interesante proteger los entornos de ejecución gracias al aprendizaje
automático (Machine Learning)
• Pero también hay tecnología basada en reglas que puede ser interesante
como FALCO
Defensa en tiempo de ejecución

Proyecto opossum
IMDEEA/2020/64
AppSec
DevSecOps
InfraSec
OPOSSUM

Users clustering
Request 1 – User 1
Request R – User U
.
.
.
Request r – User u
.
.
.
Data stream clustering

Unified approach Request r
r: request Id (1,…,R)
u: user Id (1,…,U)
t: time stamp (1,…,T)
f: feature (1,…,F)
o: observarion (1,…,Nu)
feature
engineering
User u time t Feat 1 … Feat F
Observation 11
Observation 12
Observation 21
User 1
.
.
.
Observation 1N1
User 2 User u User U-1 User U
Observation 22
.
.
.
Observation 2N2
Observation 1
Observation 2
.
.
.
Observation uNu
… …
Observation 1
Observation 2
.
.
.
Obs. (U-1)U(N-1)
Observation 1
Observation 2
.
.
.
Observation UNU
Clustering+Anomaly detection across users
Anomaly
detection
across time
(individual user)
“observation”

falco
• Motor de detección de riesgos nativo para Kubernetes
• Proyecto de la CNCF, Open Source donado por Sysdig
• Utiliza reglas que describen el comportamiento esperado de los
contenedores
• Si estas reglas no se cumplen, se generan alertas
• Existen reglas out-of-the-box para detectar actividad maliciosa y
exploits conocidos basados en CVEs
• También puede utilizarse para monitorizar dockers en un host
Linux (sin Kubernetes)

falco
• Falco controla
• Escalada de privilegios utilizando contenedores privilegiados
• Cambios en namespaces
• Lectura/Escritura en directorios habituales /etc, /usr/bin, /usr/sbin, etc.
• Enlaces simbólicos
• Cambios de propiedad en objetos
• Actividad de red sospechosa
• Spawning de procesos
• Ejecución de binarios Shell
• Ejecución de binarios basados en SSH, SCP, SFTP, etc.
• Mutación de coreutils
• Mutación de logs
• Etc.

falco
• Falco se instala directamente en el sistema host, aunque se
puede instalar sobre Kubernetes también
• No obstante, se recomienda instalarlo en el sistema host para tener el
sistema de detección de riesgos aislado en caso de que el clúster de
Kubernetes se vea comprometido
• En este caso, las alertas de Falco se consumen a través de agentes de
solo lectura que sí que corren en kubernetes
• Si se instala sobre Kubernetes, existe una definición en Helm que
permite su instalación de forma sencilla
https://github.com/falcosecurity/charts/tree/master/falco

falco
• Si se instala en el host, el proceso de instalación varía en función
de la distribución de UNIX. Para sistemas Debian/Ubuntu el
proceso es el siguiente:
curl -s https://falco.org/repo/falcosecurity-3672BA8F.asc | apt-key add -
echo "deb https://download.falco.org/packages/deb stable main" | tee -a
/etc/apt/sources.list.d/falcosecurity.list
apt-get update -y
apt-get -y install linux-headers-$(uname -r)
apt-get install -y falco

falco
• Las reglas son el corazón de Falco

falco
• Falco ofrece 25 reglas predefinidas out-of-the-box
• Estas reglas se basan en las buenas prácticas más comunes para
contenedores
• Escritura de ficheros en directorios conocidos
• Lectura de ficheros sensibles (configuración, etc.)
• Ejecución de binarios

falco
• Se recomienda publicar las alertas que Falco vaya generando en
un bróker de mensajería Pub/Sub, como por ejemplo Kafka
• De esa manera, cuando Falco detecta una anomalía, empuja una
alerta al bróker
• Los suscriptores a ese bróker pueden recibir esas alertas
• Se recomienda categorizar los topics de la siguiente forma
• FALCO.* à Todas las alertas
• FALCO.Notice à alertas con prioridad ”Notice”
• FALCO.Critical à alertas con prioridad “Critical”
• Etc.

falco
• De este modo, los subscribers del bróker
pueden TOMAR ACCIONES automatizadas,
como por ejemplo
• Matar el Pod en cuestión
• Congelar los nodos físicos para evitar nuevas
planificaciones. Si un nodo ha sido comprometido, lo
mejor que podemos hacer es no planificar ningún
pod nuevo en ese nodo, hasta asegurarnos de que
la amenaza ha desaparecido
• Aislar el pod utilizando una NetworkPolicy. De ese
modo evitamos desplazamientos laterales. Vale, ese
pod está “chingao”, pero no vas a poder saltar a
otros pods
• Y claro… enviar notificaciones al equipo de seguridad

falco
• Se recomienda utilizas sistemas FaaS para la respuesta
automática
• Kubeless, u OpenFaaS, se pueden conectar directamente con
Falco y suscribirse a esos eventos
• De ese modo, se pueden suscribir múltiples funciones para
reaccionar a los diferentes eventos de seguridad
• Una función para eliminar un pod
• Otra para notificar al equipo de seguridad
• Y otra para aislar un pod utilizando una NetworkPolicy por ejemplo
• Las funciones son pequeñas y reutilizables, lo que nos dará una
enorme potencia y flexibilidad a la hora de aplicar las políticas de
seguridad ante incidentes detectadas por Falco

falco
• Por supuesto, se puede conectar Falco a un SIEM para que las
alertas generadas se reflejen adecuadamente
• Esta integración se puede hacer de igual manera, a través de
FaaS

Explicar Riesgos / Contramedidas / Ejemplos
Explicar Riesgos / Contramedidas / Ejemplos

OTRAS CHARLAS QUE TE
PUEDEN INTERESAR…

https://es2.slideshare.net/fjbarrena/totoconf2020-tcnicas-osint-que-te-dejarn-con-el-papo-torcido
https://www.youtube.com/watch?v=W4PTlwDJgZI

https://www.slideshare.net/fjbarrena/welcome-to-gotham-nuevas-formas-ingeniosas-y-terrorficas-de-ciberataques
https://www.youtube.com/watch?v=ngrlQeFYlQM&t=3141s

https://www.slideshare.net/fjbarrena/codemotion-2021-the-rustalorian-este-es-el-camino
https://www.youtube.com/watch?v=ey0Lf2gceXw&t=2140s

VLCSofting 2021 - HARD AS A POD 落. HARDENING DE DESPLIEGUES EN KUBERNETES CON MUCHO FLOW

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Similar a VLCSofting 2021 - HARD AS A POD 落. HARDENING DE DESPLIEGUES EN KUBERNETES CON MUCHO FLOW

Similar a VLCSofting 2021 - HARD AS A POD 落. HARDENING DE DESPLIEGUES EN KUBERNETES CON MUCHO FLOW (20)

Más de Francisco Javier Barrena

Más de Francisco Javier Barrena (15)

Último

Último (19)

VLCSofting 2021 - HARD AS A POD 落. HARDENING DE DESPLIEGUES EN KUBERNETES CON MUCHO FLOW