Cómo pasar del exploit automático de bugs hecho por IA a la detección de malware en nanosegundos con eBPF & Spectral Clustering

Un aviso a las 03:00. Sonaba la alerta en Grafana mientras la mitad del cluster roncaba en modo low-power. Nada extraordinario… hasta que el panel del IDS cambió de verde a rojo en menos de 200 ms. Veintisiete llamadas execve disparadas en ráfaga, seguidas del clásico combo mmap + mprotect que todo shellcode loader necesita para saltar de la página de datos a la de instrucciones.

Figura 1: Cómo pasar del exploit automático de bugs hecho por IA

a la detección de malware en nanosegundos con

eBPF & Spectral Clustering

Al revisar la traza eBPF vimos que los buffers escritos alcanzaban 7.3 bits/byte de entropía — signo inequívoco de ofuscación o compresión agresiva. La fingerprint no coincidía con ninguna firma YARA ni regla Falco. Aquello olía a malware de generación sintética, amasado por un LLM con exceso de temperatura.

Figura 2: Linux Exploiting en 0xWord

A las 03:00:27 el blue-team contuvo la amenaza: un bpf_lsm abortó el execve antes de que la burbuja llegara a task_struct. La incógnita era clara: ¿podemos repetir esa hazaña sin humanos desvelados?

El problema: ofensiva con esteroides de IA

La línea de producción de 0-days ya no es artesanal. Un agente autónomo basado en GPT-4 es capaz de explotar 87 % de vulnerabilidades one-day cuando se le da la descripción CVE, superando por paliza a escáneres clásicos y a modelos menores (0 %). Este mismo paper advierte que, sin descripción, la tasa baja al 7 %, pero la ventana entre la publicación del advisory y el parche sigue siendo mortal.

Figura 3: LLM Agents can Autonomously Exploit One-day Vulnerabilities

En el contexto del examen SLAE32, un experimento técnico publicado en 0xboku demostró cómo el shellcode polimórfico creado manualmente puede alterar hasta un 33 % de su estructura (de 108 a 144 bytes) usando registros MMX y modificaciones de instrucciones, manteniendo su funcionalidad para evadir detección. Este caso, aunque no involucra LLMs, ilustra cómo técnicas clásicas de ofuscación ya desafían firmas SHA 256 y patrones estáticos, obligando a adoptar detección basada en comportamiento o modelos de IA entrenados en entropía y anomalías de ejecución.

1.1 No basta con “parchear rapidito”

Incluso con un SLA de parches de 24 h las organizaciones quedan expuestas durante todo el ciclo virtual —release de exploit, write-up en blog, publicación del PoC—. Necesitamos detección y respuesta en tiempo real, preferiblemente antes de que los bytes maliciosos crucen la frontera usuario-kernel. 

La hipótesis: el kernel susurra en nanosegundos 

El Extended Berkeley Packet Filter (eBPF) es nuestra oreja en ring 0:

• Se carga como byte-code verificado; imposible desbordar el kernel.
• Engancha tracepoints/kprobes a cualquier syscall sin recompilar ni reiniciar.
• Copia eventos a espacio de usuario mediante ring buffer (cero copias).
• Overhead bajo: Alto rendimiento al trazar syscalls execve y mprotect en workloads OLTP.

Figura 4: Arquitectura de eBPF

2.1 Características que sí delatan a un loader

1. n-grams de syscalls (window=5): captura lógicas como open → read → mmap → mprotect → execve.
2. Entropía de payload: indica compresión/cifrado.
3. Δt entre syscalls: ciertos packers insertan “sleep-gaps” para evadir monitoreo.
4. Delta de privilegios: salto uid 1000 → 0 es red-flag.
5. Llamadas ptrace: frecuente en stagers que se inyectan en procesos confiables.

Los cinco valores se normalizan y forman un vector de 256 dimensiones que alimenta el algoritmo de Machine Learning.

Figura 5: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

El truco de magia: Spectral Clustering sin etiquetas

Mientras los IDS clásicos aprenden con datasets estáticos —y sufren cuando aparecen comportamientos inéditos— el Spectral Clustering trabaja a ciegas:

1. Construye una matriz de similitud S calculando distancia Jensen-Shannon entre histogramas de vectores (researchgate.net).
2. Obtiene el Laplaciano normalizado L = D⁻¹ᐟ² (D − S) D⁻¹ᐟ²
3. Extrae los k autovectores de menor autovalor y proyecta los puntos.
4. Aplica k-means en ese nuevo espacio.

Nota: investigamos Eigen-updates streaming, técnica que recalcula solo los autovectores afectados por un cambio local en S, logrando refrescar el modelo de 2- 3 ms sin reconstruir toda la matriz.

PoC I — portátil del blue team

Durante las pruebas iniciales quisimos demostrar que la detección basada en eBPF + Spectral Clustering cabe incluso en un laptop de respuesta rápida—el típico “equipo de guerra” que un analista lleva a un incidente.

• Tracepoint raw_syscalls:sys_enter: el programa eBPF cuenta todas las syscalls y las lanza a un ring buffer (overhead ≈ 0.7 % CPU) .

• Extractor en user-space: cada 500 ms levanta el histograma por PID y lo paddea a longitud constante.

• Cálculo de similitud: matriz RBF simetrizada + self-loops mínimos para garantizar conectividad.

• Spectral Clustering: con k = 2 → etiqueta “normal” vs “anómalo”; la decisión llega en ≈ 35 ms.

• Acción: si label == anomalía, lanzamos un hook LSM que cancela execve, e inmediatamente Grafana genera una alerta.

Figura 6: Pipeline de detección de anomalías in-kernel

con eBPF + Spectral Clustering (PoC I)

Qué aprendimos del portátil

• El ring buffer es clave: pasar a perf-event duplicaba la latencia.

• Padding + RBF: permite trabajar con huellas de procesos muy diversos (LibreOffice pesa > 300 syscalls/ventana; un curl apenas 18).

• El “modo laptop” es ideal para ofensiva inversa: llevas la detección in situ y cazas la amenaza antes de subir nada al SIEM.

PoC II — clúster K8s de producción

• DaemonSet carga el colector eBPF.

• Los vectores llegan por gRPC a un side-car que vive en el mismo node pool que OpenSearch, evitando saltos de red.

Figura 7: Arquitectura de telemetría y respuesta

en el clúster Kubernetes (PoC II)

• DaemonSet despliega el sensor en cada nodo (hostPID:true, privileged:true).

• Cilium exporta sus mapas eBPF (cilium/ebpf/v2) y nos evita duplicar sondas.

• Hubble Relay agrega eventos L4, que se fusionan con la matriz‐syscalls vía ID de contenedor.

Todos los dashboards viven en un Grafana-LOKI-Tempo stack; las alertas llegan a PagerDuty.

Correlación Hubble + syscalls — afinando el detector en microservicios ruidosos 

La tesis es sencilla, ya que los False Positives suelen aparecer cuando un microservicio legítimo realiza ráfagas inusuales de syscalls—por ejemplo, un side-car de logging que comprime registros antes de enviarlos.

Figura 8: Ensamblador X86: Teoría y Practica.

de Josué Acebedo Maldonado y Sheila A. Berta.

Si correlacionamos flujos L4/L7 de Hubble (la capa de observabilidad de Cilium) con la secuencia de syscalls del mismo container_id, obtenemos contexto de red que ayuda al modelo espectral a distinguir un backup ruidoso de un loader malicioso.

• Emparejar eventos: cada registro Hubble porta pod_uid y container_id. El extractor agrega esos campos al vector de 256 D.

• Nuevas features: dirección (ingress/egress), proto, bytes_sent y ratio packets/Δt.

• Reentrenar parcial (Eigen-update): cada 10 s para minimizar deriva.

Lecciones aprendidas

Después de estas pruebas, hemos visto como el  análisis no supervisado elimina la esclavitud de etiquetar muestras de malware. Además, el uso de eBPF permite hot-patch del sensor sin tener que reiniciar ni recompilar el kernel. En todo este proceso, el cuello de botella real es el cálculo completo de autovectores y el uso de Eigen-updates reduce la carga a la décima parte.

Figura 9: "Malware moderno: Técnicas avanzadas y su influencia en la industria"

de Sergio de los Santos en  0xWord

Además, correlacionar capa de red (Hubble) con syscalls baja los falsos positivos en escenarios de microservicios ruidosos, lo que es muy beneficioso. Por último, en todo este proceso es muy importante la UX del analista, y tener un panel que combine “Top anomalous pods” con la llamada exacta a mprotect(PROT_EXEC) ahorra 10 min de búsqueda a las 03 : 00.

Como próximos pasos en este aprendizaje, vamos a trabajar en  extender el modelo para cubrir tráfico  de los niveles L4/L7 completos. Proceder a automatizar las acciones de mitigación vía Falco + ArgoCD y explorar distancia de Wasserstein sobre los histogramas, prometedora para diferenciación fina de malware polimórfico. Además, queremos probar despliegue desde el edge en IoT (ARM64) con micro-agentes eBPF.

Autor: José Acevedo Maldonado, autor del libro Ensamblador X86: Teoría y Practica.

Contactar con José Acevedo Maldonado (neomatrix)

Cómo servir modelos de ML e IA (LLMs) en Kubernetes con KServe: Autoscaling Inteligente y Eficiencia en GPU

La Inteligencia Artificial no se detiene, y su adopción en producción tampoco, pero hay una brecha silenciosa entre entrenar un modelo y servirlo de forma eficiente, escalable y mantenible. Aquí es donde Kubernetes se convierte en el aliado perfecto, y donde herramientas como KServe (el sucesor de KFServing) brillan.

Figura 1: Cómo servir modelos de ML e IA (LLMs) en Kubernetes con KServe.

Autoscaling Inteligente y Eficiencia en GPU

En este artículo te cuento cómo puedes montar una plataforma moderna para servir modelos de IA y LLMs sobre Kubernetes, aprovechar las novedades más recientes de KServe, y hacer que tu infraestructura escale según uso real y consumo de GPU. 

Figura 2: Arquitectura de KServe

Spoiler: sí, se puede tener eficiencia, velocidad y buena arquitectura al mismo tiempo.

¿Por qué servir modelos sobre Kubernetes?

Entrenar un modelo es sólo la mitad del camino. Lo difícil viene después: ponerlo a funcionar en producción de forma fiable, segura y escalable.

• Alta disponibilidad
• Autoescalado según carga real
• Seguridad, versionado, observabilidad
• Integración con pipelines CI/CD y orquestadores como Argo Workflows o Kubeflow

Kubernetes permite todo esto. Pero no hay que reinventar la rueda, y ahí entra KServe.

Antes de continuar… ¿Qué es Kubeflow y qué ofrece?

Kubeflow es una plataforma Open Source pensada para desplegar, escalar y gestionar flujos de trabajo de Machine Learning (ML) sobre Kubernetes. Su objetivo principal es llevar el desarrollo de modelos de ML a producción de forma reproducible, escalable y portátil.

Figura 3: Componentes de Kubeflow

Kubeflow no es una herramienta única, sino un conjunto de componentes modulares que cubren distintas etapas del ciclo de vida del modelo de Machine Learning:

• Kubeflow Pipelines: Orquestación de pipelines de ML (entrenamiento, preprocesado, validación, etcétera).

• Katib: AutoML y búsqueda de hiperparámetros.

• KServe (antes KFServing): Serving de modelos con escalado automático y despliegues sin downtime.

• Notebook Servers: Entornos Jupyter en Kubernetes, listos para trabajar con datos y modelos.

• Central Dashboard y Profiles: Gestión multiusuario, RBAC, y control de recursos por equipo o proyecto.

Kubeflow se posiciona como una plataforma completa para MLops sobre Kubernetes, especialmente útil cuando necesitas estandarizar y automatizar todo el flujo de trabajo desde el desarrollo hasta el despliegue.

Figura 4: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Aunque KServe puede funcionar por separado de Kubeflow, se integra perfectamente como pieza de serving dentro del stack Kubeflow.

KServe: servir modelos como si fueran microservicios

KServe es un componente de Kubeflow, pero puede usarse de forma independiente. Te permite desplegar modelos como recursos de Kubernetes (CRDs), exponiéndose vía REST o gRPC, con soporte para, entre otros, PyTorch, TensorFlow, XGBoost, SKLearn, ONNX etc... e incluso tus propios contenedores.

• Lo bueno: cada modelo es un InferenceService, y tú defines lo que necesita: CPU, GPU, versiones, etcétera.

• Lo brutal: KServe soporta escalado automático hasta cero réplicas, y las vuelve a levantar cuando hay tráfico. Nada de infra desperdiciada.

GPU autoscaling

• Puedes escalar vertical y horizontalmente tus modelos en GPU.
• Mediante Prometheus Adapter + HPA Custom Metrics, se puede escalar según uso de memoria GPU, uso de batch o incluso peticiones por segundo.

Raw Deployment mode

• 1.- KServe por defecto usa Knative para autoescalar.
• Escala basándose en tráfico HTTP (requests por segundo).

• Esto no es suficiente cuando usas GPUs, ya que estas no se liberan con tráfico bajo.

• Además, los workloads con GPU suelen tener procesamiento batch o tiempos largos de inferencia, donde Knative no escala de forma óptima.

• 2.- Para modelos en GPU, muchas veces no se usa Knative, sino raw deployment mode en KServe, para tener más control.
• Aquí ya no dependes de Knative, sino de un Deployment + HPA.

Figura 5: Arquitectura para servir modelos

• 3.- Prometheus Adapter + HPA con métricas personalizadas
• Prometheus Adapter permite exponer métricas personalizadas (por ejemplo: uso de memoria GPU, utilización del device, número de peticiones, etc.) como Custom Metrics API.

• Con eso puedes configurar un HPA (Horizontal Pod Autoscaler) para escalar los pods de inferencia según esas métricas.

• Esto se usa en entornos donde se necesita un autoscaling más inteligente y específico, especialmente con GPU.

Scale down a cero

¿Qué significa “scale down a cero” en KServe?

• Es la capacidad de escalar a cero réplicas un modelo cuando no está recibiendo peticiones, y volver a levantarlo automáticamente (auto-scale up) cuando llega una nueva petición.

¿Qué beneficios tiene esta solución?

• Ahorro de costes brutal: Si tienes muchos modelos desplegados pero no todos se usan constantemente, con scale-to-zero no malgastas CPU ni RAM. Ideal en entornos cloud donde pagas por uso de recursos, como en clusters gestionados (EKS, GKE, AKS…).

• Optimización de recursos en el cluster: En vez de mantener todos los pods activos, los que no reciben tráfico se eliminan temporalmente, dejando espacio a otros workloads que sí lo necesitan. Ayuda a evitar sobrecargas y reduce la necesidad de sobredimensionar el cluster.

• Despliegue eficiente de muchos modelos: Puedes permitir que muchos equipos o usuarios publiquen sus propios modelos sin saturar el sistema. Esto habilita patrones como “multi-tenancy” eficiente para inferencias bajo demanda.

• Escalado bajo demanda: Si un modelo recibe tráfico repentino, KServe lo activa rápidamente. Esto es perfecto para modelos que solo se usan de vez en cuando o que funcionan como microservicios ML reactivos.

Canary rollout

KServe soporta dividir tráfico entre versiones de modelo (v1, v2, etcétera). Por ejemplo puedes hacer un 90/10, observar métricas y logs, y luego promover o descartar la nueva versión. Pero… ¿qué es Canary rollout? 

Figura 6: Canary Rollout

El Canary rollout te permite probar una nueva versión de un modelo (por ejemplo v2) con una pequeña parte del tráfico real, mientras que la versión estable (v1) sigue sirviendo la mayoría del tráfico. Esto es clave para:

• Validar rendimiento y exactitud del modelo en producción.
• Detectar errores o regresiones antes de hacer el cambio completo.
• Observar métricas y logs reales sin impactar a todos los usuarios.

Ejemplo de Canary rollout en KServe

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
 name: sklearn-iris
 namespace: kserve-test
spec:
 predictor:
   model:
     modelFormat:
       name: sklearn
     storageUri: "gs://kfserving-examples/models/sklearn/1.0/model-1"
   canaryTrafficPercent: 10
   canary:
     model:
       modelFormat:
         name: sklearn
       storageUri: "gs://kfserving-examples/models/sklearn/1.0/model-2"

• storageUri: del bloque principal. Apunta a model-1, la versión actual y estable del modelo.
• canary: Define model-2 como la nueva versión que se quiere probar.
• canaryTrafficPercent: 10: indica que el 10% del tráfico entrante será dirigido a model-2, mientras que el 90% restante seguirá siendo servido por model-1.

Novedades destacadas

Desde la versión v0.15.0, KServe ha incorporado mejoras significativas para el despliegue de modelos de lenguaje (LLMs), incluyendo soporte distribuido con vLLM, mejoras en el runtime de Hugging Face y optimizaciones para almacenamiento y readiness. Esto abre la puerta a escenarios como:

• Servir un modelo LLaMA o Falcon en múltiples nodos GPU.

• Integrar modelos de Hugging Face con pipelines existentes y autoscaling por demanda.

• Aprovechar técnicas avanzadas como RAG o agentes con herramientas directamente desde Kubernetes.

Si antes KServe era ideal para modelos tradicionales de Machine Learning, ahora también lo es para los modelos de última generación. 

Algunas otras funcionalidades adicionales:

• Soporte para descarga de archivos individuales desde GCS Google Cloud Storage), lo que mejora los tiempos de inicio.

• Readiness probes más precisas, especialmente para modelos en transformers, mejorando la confiabilidad de despliegues en producción.

• Introducción de “KServe Guru” en Gurubase.io, un espacio para encontrar y compartir soluciones de la comunidad.

Arquitectura tipo: Cómo lo montamos

Una plataforma de inferencia moderna sobre Kubernetes podría verse así:

• KServe + Istio: para gestión de modelos como microservicios.

• Knative Serving: para escalado a 0, cold start optimizado.

• Prometheus + Grafana: para métricas personalizadas de GPU o latencia.

• Cert-Manager + Ingress Gateway: TLS automático para exposición segura.

• ArgoCD o Flux: GitOps para definir modelos como código.

• GPU Operator de NVIDIA: para gestionar drivers y nodos GPU

¿Y si no quieres montar todo esto desde cero?

Aunque herramientas como KServe y Kubeflow son muy potentes, su configuración desde cero puede requerir tiempo, conocimientos avanzados de Kubernetes y una buena integración con infraestructura cloud o on-prem. Aquí es donde entran plataformas como Axebow.io, que están diseñadas para facilitar el despliegue de aplicaciones, entornos de Machine Learning e IA y plataformas completas sobre Kubernetes. Esto permite que equipos de IA y Data Science se enfoquen en desarrollar y servir modelos sin preocuparse por los detalles de infraestructura.

Figura 7: Puedes probar Axebow sin coste

Axebow.io proporciona configuraciones optimizadas para rendimiento, autoscaling con GPU y despliegues reproducibles, lo que reduce la complejidad operativa y acelera el time-to-production. Si estás interesado en saber más, contacta con nosotros.

Autores: Miguel Angel Chuecos /  Carlos García Blanco, CEO de Kumori

Contactar con Carlos García Blanco

Platform Engineering as a Service con Axebow: La encrucijada de la Nube y la ilusión del progreso.

Desde hace más de una década la industria tecnológica ha estado experimentado una evolución constante hacia la computación en la nube, impulsada por las promesas de escalabilidad, flexibilidad y eficiencia en costes. Evolución que ha ido acompañada por el surgimiento de una plétora de herramientas y plataformas, intencionalmente diseñadas para simplificar el desarrollo y la gestión de recursos en la nube. Pero... ¿hemos avanzado lo suficiente en la última década?.

Figura 1: Platform Engineering as a Service con Axebow.

La encrucijada de la Nube y la ilusión del progreso.

Si nos paramos a analizar la situuación actual, a pesar de estos avances, la complejidad fundamental de aprovisionar y gestionar recursos virtualizados sigue siendo prácticamente la misma. Hemos pasado de escribir scripts personalizados para orquestar nuestra infraestructura a utilizar herramientas más sofisticadas, como por ejemplo Terraform.

Paralelamente, y a un nivel superior, hemos introducido un mayor grado de automatizaciones con orquestadores de contenedores como Kubernetes. Sin duda hemos ido progresando, pero, ¿estamos significativamente mejor que hace diez años a la hora de simplificar la puesta a punto de servicios basados en software?

La Evolución de las Herramientas de Desarrollo Cloud

En los primeros días de la computación en la nube, desarrolladores y administradores de sistemas dependían en gran medida de scripts manuales para gestionar máquinas virtuales y otros recursos. Scripts de shell, Python y otras soluciones ad hoc fueron la norma (aún lo son en algunos casos). Estos scripts a menudo son específicos de la plataforma, carecen de estandarización y son difíciles de mantener. Lo que es peor, en muchos casos son scripts específicos para la puesta en producción de servicios concretos, por lo tanto no generalizables.

La llegada de la aproximación de Infraestructura como Código (IaC, en sus siglas en inglés) y sus herramientas (Terraform, CloudFormation, Ansible, ...), prometió poner orden en el caos. Estas herramientas permiten a los ingenieros definir configuraciones de infraestructura en código, versionarlas y desplegarlas de manera confiable en diferentes entornos. A primera vista, esto parece un avance significativo.

También hemos visto una proliferación de marcos y herramientas que intentan simplificar el desarrollo en la nube, introduciendo nuevas abstracciones que, por desgracia, conllevan curvas de aprendizaje importantes y muchas oportunidades para errar en su uso.

Figura 2: Docker: SecDevOps 2ª Edición de Fran Ramírez, Elias Grande

y Rafael Troncoso en 0xWord.

Kubernetes es un excelente ejemplo. Nació de la necesidad de facilitar la orquestación de contenedores, y ha tenido éxito hasta cierto punto. Pero para muchos desarrolladores, la transición a Kubernetes a menudo se siente como intercambiar un conjunto de complejidades (p.e., gestión de servidores) por otro (gestión de manifiestos, clústeres, políticas de red, etc...). El viejo dolor de cabeza de gestionar recursos ha sido reemplazado por nuevas complejidades en la gestión de objetos de Kubernetes.

La Persistencia de la Complejidad

Por lo tanto, a pesar de la adopción de herramientas como las ya expuestas, la complejidad asociada con el desarrollo en la nube no ha disminuido sustancialmente. Podemos enumerar algunas de sus razones:

1. Curvas de Aprendizaje nada despreciables: Herramientas como Terraform (o incluso Kubernetes) introducen sus propios lenguajes específicos de dominio (DSL) (interno, en el caso de Kubernetes, basado en YAML), y conceptos que sus usuarios deben aprender. Comprender las sutilezas de estos lenguajes puede ser tan desafiante como dominar un nuevo lenguaje de programación.

2. Características Específicas de la Plataforma: Aunque las herramientas de IaC intentan ser independientes de la plataforma, la realidad es que proveedores cloud como AWS, Azure, Google Cloud, etc... tienen servicios, configuraciones y peculiaridades únicas. Esto requiere un profundo conocimiento específico del proveedor cloud, lo que va en contra del objetivo de simplificación de las herramientas. Plataformas como Kubernetes tampoco se salvan de tratar con esta especificidad.

3. Servicios en la Nube en Evolución Constante: Los proveedores Cloud lanzan continuamente nuevos servicios y características. Mantenerse al día con estos cambios requiere aprendizaje constante y actualizaciones al código de infraestructura existente, añadiendo una carga adicional de mantenimiento.

4. Complejidad de los Sistemas Distribuidos: Los servicios basados en software son inherentemente aplicaciones distribuidas. Utilizan microservicios (posiblemente basados en contenedores), arquitecturas sin servidor o una combinación de ambas. Gestionar su ciclo de vida en la nube introduce capas adicionales de complejidad que las herramientas de IaC por sí solas no pueden abstraer (ni es su objetivo).

5. Gestión de Estado y Depuración: Manejar el estado de los recursos en la nube es una tarea no trivial. Herramientas como Terraform mantienen archivos de estado que pueden convertirse en fuentes de conflictos, llevando a problemas de despliegue difíciles de depurar.

Caso concreto I: Scripts de Terraform vs. Scripts Tradicionales

Consideremos la transición de scripts tradicionales a scripts de Terraform. Si bien Terraform proporciona una forma estructurada de definir recursos, los scripts pueden volverse extremadamente complejos en infraestructuras grandes. Módulos, variables y gráficos de dependencias intrincados pueden hacer que las configuraciones de Terraform sean tan difíciles de leer y mantener como los scripts que reemplazaron.

Además, errores en las configuraciones de Terraform pueden conducir a despliegues parciales o modificaciones no intencionadas de recursos, requiriendo una planificación cuidadosa y pruebas exhaustivas, prácticas que eran igualmente necesarias con los scripts tradicionales.

Caso concreto II: Kubernetes vs. Métodos de Implementación Tradicionales

Consideremos el auge de Kubernetes como la solución de facto para la orquestación de contenedores. Kubernetes promete simplificar la implementación, escalado y gestión de aplicaciones en contenedores. Sin embargo, esta simplificación aparente viene con su propio conjunto de complejidades.

• Configuraciones Complejas: Kubernetes utiliza archivos YAML para definir recursos como Pods, Servicios y Deployments. Estos archivos pueden volverse extremadamente detallados y difíciles de gestionar, especialmente en aplicaciones grandes con múltiples microservicios.

• Curva de Aprendizaje Pronunciada: Dominar Kubernetes requiere una comprensión profunda de conceptos como namespaces, ingress controllers, volúmenes persistentes y políticas de red. Esto puede ser abrumador para equipos que migran desde entornos tradicionales.

• Infraestructura Adicional: Para ejecutar Kubernetes, a menudo se necesita infraestructura adicional, como sistemas de almacenamiento distribuidos y soluciones de red avanzadas. Esto añade más capas que deben configurarse y mantenerse.

• Herramientas Complementarias Necesarias: La gestión efectiva de un clúster de Kubernetes a menudo requiere herramientas adicionales como Helm para la gestión de paquetes, Prometheus para monitorización y Grafana para visualización, cada una con sus propias complejidades. No sólo esto, configurar un clúster Kubernetes para dotarlo de funciones básicas (ie. ingress, networking, ...) requiere tener que elegir de entre un nutrido elenco de soluciones, cada una con sus pros y sus cons, así como sus propias complejidades de configuración y gestión.

• Depuración y Resolución de Problemas: Cuando algo sale mal en Kubernetes, identificar y resolver el problema puede ser significativamente más difícil debido a la naturaleza distribuida y dinámica del sistema.

En comparación con los métodos de implementación tradicionales, donde las aplicaciones se despliegan en servidores físicos o máquinas virtuales con configuraciones más estáticas, Kubernetes introduce un nivel de abstracción que, si bien es poderoso, también puede ser difícil de manejar sin la experiencia adecuada.

El Problema Subyacente

En el fondo, el problema es la complejidad inherente de los entornos en la nube. Las herramientas sólo pueden abstraer la complejidad hasta cierto punto. Mientras los servicios en la nube sigan siendo tan diversos y complejos como lo son, gestionarlos requerirá un esfuerzo y conocimiento significativos.

La consecuencia es que es necesario un buen grado de especialización para gestionar buena parte de las tareas de gestión de recursos que es preciso tener en cuenta no sólo a la hora de poner servicios en producción, sino también durante el proceso de desarrollo del software, creando un buen número de ineficiencias.

¿Qué Necesitamos Cambiar?

Para responder a esta pregunta, debemos clarificar cuales son (o deberían ser) nuestros objetivos. La IaC y sus herramientas tienen como objetivos simplificar (¿?) el proceso de aprovisionamiento de recursos y servicios en la nube. Sin embargo, podemos argumentar que esto no es realmente el objetivo último. El objetivo último debería ser doble:

1. Por una parte habilitar a los equipos de desarrollo el acceso transparente a aquellos recursos virtualizados que necesitan para apoyar su proceso de desarrollo.

2. Por otra parte, permitir la gestión ágil del ciclo de vida de los servicios basados en el software producido por esos equipos de desarrollo.

Es nuestro punto de vista que atender dichos objetivos sólo va a ser posible elevando el nivel de las abstracciones manejadas por desarrolladores y gestores de servicios de modo que la gestión de los recursos virtualizados se transparente gracias a la automatización que esos niveles de abstracción permiten.

Figura 3: Axebow permite que los developers se focalicen

en el código y no en la infraestructura.

Esta aproximación no es novedosa. Baste ver la evolución de los sistemas operativos modernos: el desarrollador no se preocupa de la gestión de los recursos existentes en el ordenador. Confía en el sistema operativo subyacente, y todos los actores que operan por encima del sistema operativo manejan un conjunto de abstracciones simples y a la vez potentes que les permiten ignorar totalmente la gestión de los recursos necesarios para las tareas de cómputo soportadas.

Figura 4: Con Axebow, los Developers no necesitan preocuparse

de la infraestructura, y los equipos de operaciones crean

infraestructura como servicio independiente de Cloud Provider.

Esta es también la dirección tomada por sistemas que, como Kubernetes, introducen un alto grado de automatización, aunque en este caso a un precio de complejidad que, en nuestra opinión, genera sus propios problemas.

Figura 5: Los equipos de DevSecOps pueden proveer infraestructura

como servicio a los developers independiente de Cloud Provider,

reduciendo complejidad y ahorrando costes en la gestión de entornos

de desarrollos, pruebas y producción, usando Axebow.

En conclusión, para lograr un progreso significativo, debemos poner el foco en la simplificación de las plataformas que ponemos a disposición de los equipos de desarrollo. La complejidad debe residir en la implementación de la plataforma, no en su uso, como frecuentemente sucede hoy en día. Solo cuando logremos que el acceso a la tecnología de la nube sea tan transparente como el acceso a la electricidad podremos constatar la dimensión de un auténtico progreso.

Figura 6: Prueba sin coste Axebow durante Octubre y Noviembre

Es lo que se ha pretendido con Axebow simplificar el proceso de despliegue reduciendo la complejidad existente y descrita. Podéis probar el servicio SIN COSTE durante ellos meses de octubre y noviembre.

Saludos,

Autor: José Bernabeu-Auban

Contactar con José Bernabeu-Auban

Kubernetes para profesionales: Desde cero al despliegue de aplicaciones seguras y resilientes. Nuevo libro de @0xWord

Desde hoy tenemos a la venta el nuevo libro en 0xWord de "Kubernetes para profesionales: Desde cero al despliegue de aplicaciones seguras y resilientes", escrito por Rafael Troncoso y centrado en ser un "pro", un "máster", un "groso", un "duro"... o un hacker que diríamos nosotros, desplegando Kubernetes. 

Figura 1: "Kubernetes para profesionales: Desde cero al despliegue de

aplicaciones seguras y resilientes" de Rafael Troncoso  en 0xWord

El libro, como es de esperar, pone mucho foco en conocer a fondo cómo desplegar servicios de forma profesional, poniendo especial énfasis en todas las opciones de seguridad. En desplegar de la manera más robusta cualquier aplicación utilizado la tecnología Kubernetes en sus más de 270 páginas. Así que, si eres de los que cree que hay que fortificar las aplicaciones en modo "Paranoid", este es tu libro si vas a hacerlo aprovechando Kubernetes.

Figura 2: "Kubernetes para profesionales: Desde cero al despliegue de

aplicaciones seguras y resilientes" de Rafael Troncoso  en 0xWord

El libro, como podéis leer en la descripción del mismo, te da más motivos por los que comprarse y estudiarse en profundidad este nuevo libro de Rafael Troncoso . 

"Predeterminado a convertirse en el “sistema operativo de la nube”. Así es como muchos ven a Kubernetes. La plataforma que está revolucionando el despliegue de aplicaciones modernas en sistemas de producción. Kubernetes es actualmente “el” orquestador de contenedores, y ha llegado para quedarse. No tiene actualmente rival alguno. Cualquier profesional que se dedique al desarrollo de software, operaciones o a la seguridad, si se quiere mantener relevante en esta industria, debe estar familiarizado con el funcionamiento y uso de Kubernetes. En este libro, aprenderás desde los conceptos básicos sobre dicha plataforma, hasta el despliegue de aplicaciones de forma segura y resilientes.

Para que podáis ver en detalle el contenido, os he subido a mi cuenta de SlideShare el documento con el índice del mismo, con todos los temas que se tratan en el compendio que Rafael Troncoso  ha escrito sobre Kubernetes.

Figura 3: Índice el libro "Kubernetes para profesionales:Desde cero al despliegue de aplicaciones seguras y resilientes"de Rafael Troncoso en 0xWord

Por supuesto, con la compra del libro tendrás también Tempos de  MyPublicInbox, y podrás utilizarlos para consultar cualquier duda, enviar cualquier consulta o sugerencia a Rafael Troncoso, con el que puedes contactar a través de su buzón público.

Figura 4: Contactar con Rafael Troncoso en MyPublicInbox

Este es su tercer libro, ya que, como sabéis, Rafael Troncoso es también co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" además de ser uno de los fundadores del blog CyberHades. Así que si quieres aprender mucho sobre Kubernetes, éste es tu libro.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

DevOps, DevSecOps, el último gran olvidado.

La incorporación de la filosofía DevOps a las empresas no ha hecho más que aumentar en los últimos años. En consecuencia, ha surgido la aparición de nuevos roles como SRE, DevOps… que ayudan y facilitan a los equipos de desarrollo una puesta en valor del producto cada vez más rápida.

Figura 1: DevOps, DevSecOps, el último gran olvidado.

Justamente de esta necesidad de poner en valor cuanto antes nuestro producto, habla Carlos Buenosvinos en su ponencia en el evento CTO Summit del 2019. Él la define como "Deliveritis Aguda", ese “trastorno obsesivo compulsivo causado por la obsesión de entregar valor que generan espasmos físicos que suben código a producción”. Te recomiendo encarecidamente que escuches la charla. 


Figura 2: Deliveritis Aguda | Carlos Buenosvinos
Existen muchas herramientas para ello, tantas, que termina haciéndose imposible conocerlas todas. Algunas proporcionadas por nuestro proveedor de cloud y otras provenientes de nuestro CI/CD que nos ayudan en nuestro día a día a desplegar. En muchos casos se trata de grandes empresas que cuentan con departamentos para crear sus propias herramientas y disponer de las configuraciones necesarias que ayuden a desplegar de una forma rápida, así como mantener la infraestructura a punto y segura.

Crear una aplicación de esta metodología no es sencilla, debido a la gran cantidad de stacks que podemos estar empleando y a la evolución tan frenética de las herramientas existentes del mercado. Además, los proveedores cloud tampoco se quedan atrás en esto y siguen sacando una gran cantidad de features, lo que nos obliga a estar en constante proceso de aprendizaje.

Figura 3: Landscape del cnf.io

Todo esto hace que cada vez veamos proliferar más infraestructura automatizada mediante tecnologías como Openshift o Kubernetes, que nos aseguran unos mínimos de seguridad junto a las políticas de nuestro proveedor de cloud. A veces ésta es suficiente, pero en muchos otros casos dejamos de revisar puntos claves introducidos por estas tecnologías o incluso por el stack con el que desarrollamos nuestras aplicaciones.

DevSecOps   

También tengo que decir, que no siempre los problemas de seguridad surgen como consecuencia de nuestra infraestructura, como por ejemplo, la utilización de packages de terceros. La no aplicación de ciertos patrones a la hora de desarrollar pueden ser peajes libres para los ciberdelincuentes. Por eso mismo es tan importante aplicar el concepto DevSecOps e involucrarse en todas las fases de desarrollo de las aplicaciones desde el principio, empezando por el diseño de la infraestructura hasta su puesta en funcionamiento.

Figura 4: Libro de Docker:SecDevOps de 0xWord
escrito por Elias Grande, Fran Ramírez y Rafael Troncoso

DevSecOps también implica la automatización de algunas puertas de seguridad seleccionando las herramientas adecuadas de manera permanente para impedir que se ralentice el flujo de trabajo DevOps, así como acordar el uso de un IDE (entorno de desarrollo integrado) con funciones de seguridad. No obstante, su efectividad requiere más que herramientas nuevas: se basa en los cambios culturales de DevOps que integren el trabajo de los equipos de seguridad con la mayor agilidad posible.

Figura 5: Landscape de MomentuCyber

Al igual que ocurre en DevOps, existen también multitud de herramientas que nos ayudan a controlar la parte de seguridad de nuestra infraestructura. Nadie está libre de recibir algún tipo de ataque y esto es algo que han dejado patente en numerosas ocasiones tanto administraciones públicas como grandes empresas que invierten cientos de miles de euros y dólares en mejorar su seguridad.

Figura 6: Ataques informáticos en la administración pública

En conclusión, cuanto antes pongamos foco en la seguridad desde las fases iniciales del diseño de cualquier producto, menos posibilidades tendremos de recibir cualquier tipo de ataque, y en caso de sufrirlo, minimizar al máximo las consecuencias. Por eso es tan importante que las empresas cuenten con equipos de desarrollo dedicados exclusivamente a todos estos aspectos en materia de seguridad que hoy en día o se obvian o simplemente no se evalúan por desconocimiento.

Fórmate en DevOps / DevSecOps Online   

Si quieres ampliar más sobre el tema, te invito a ver esta mesa redonda sobre DevOps (que acaba de publicarse en abierto) en el CTO Summit, el evento en el que participé junto a más de 20 profesionales del sector de la tecnología el pasado 2020.


Figura 7: Roundtable DevOps en CTO Summit 2020

Además, si quieres especializarte en esta área y dar un salto profesional en tu carrera, te invito a que eches un vistazo al programa del Bootcamp Online DevOps de GeeksHubs Academy (empieza el 8 de Octubre) del que formo parte también y junto a un equipo de docentes con muchísima experiencia en el sector.

Figura 8: Temario del Bootcamp Online DevOps de GeeksHubs Academy

En esta formación 100% Online y con modalidad Part-Time para que puedas compaginarlo con tu actividad profesional actual, adquirirás competencias en gestión de la infraestructura e incluso en el análisis de seguridad de la misma. También serás capaz de desplegar y tratarla como código y lo más importante al fin y al cabo: te permitirá llevar a cabo despliegues más seguros e infraestructuras mucho más robustas en tus desarrollos. Y además, recibirás un libro de apoyo de 0xWord y 500 Tempos de MyPublicInbox.

Autor: Javier Rodríguez Soler, CTO en Widitrade

Contactar con Javier Rodríguez Soler

Máster Online en DevSecOps: Hasta el 27 de Abril puedes apuntarte #DevSecOps #SecDevOps

Como ya os había dicho en la entrada anterior, uno de los roles profesionales que más demandados se han hecho en los últimos cinco años y que tiene que ver con la ciberseguridad es el de DevSecOps o SecDevOps, que de las dos formas lo han estado solicitando las empresas. Este rol busca tener especialistas que automaticen los despliegues de los entornos, los entornos de seguridad, los desarrollos realizados, utilizando scripts automatizados que cubran todas las fases de ciclo de desarrollo y puesta en producción de un servicio con, por supuesto, todas las fases de seguridad.

Figura 1: Hazte un "Máster" en DevSecOps

De este tipo de actividades hemos hablado mucho por aquí, como hablaba hace poco del trabajo de SecDevOps y las Linux Capabilities, o el artículo que debes leer para entender bien este trabajo que se llama "SecDevOps: una explicación en 5 minutos (o alguno más)" donde vas a ver cómo se aplican los conocimientos de estos profesionales a las diferentes fases de la construcción de tecnología en las empresas. Esta, como ya he dicho es una profesión de las más demandadas hoy en día.

Figura 2: Máster en DevSecOps

Como ya sabéis, nosotros hicimos el libro de Docker: SecDevOps escrito por Fran Ramírez, Elías Grande y Rafael Troncoso en 0xWord precisamente por esta alta demanda para roles de ciberseguridad, y en el Campus Internacional de Ciberseguridad se ha diseñado el Máster en DevSecOps que dirigen nuestros compañeros Pablo González y Juanjo Salvador. La nueva fecha de inicio será el próximo 27 de Abril de 2021.

Figura 3: Máster Online en DevSecOps

Para este Máster Online de DevSecOps, el temario que se ha trabajado cuenta desde la parte pura de operaciones, hasta la parte pura de seguridad, para mezclar ambas con automatización de scripts en entornos de gestión de infraestructura, gestión de aplicaciones, y cumplimiento normativo, con un Trabajo Final de Máster que hemos diseñado los profesores. Estos son los módulos.

Módulo 1.- DevOps: Filosofía e Introducción.

Módulo 2.- DevOps: Construyendo la base.

Módulo 3.- DevSecOps: Ciclo de vida de desarrollo seguro.

Módulo 4.- DevSecOps: Monitorización.

Módulo 5.- SAST: Pruebas de seguridad a aplicaciones estáticas.

Módulo 6.- DAST: Pruebas de seguridad a aplicaciones dinámicas.

Módulo 7.- Infraestructura y Compliance.

Módulo 8.- Gestión de Vulnerabilidades.

Módulo 9.- Trabajo Final de Máster.

Dentro del Trabajo Fin de Máster yo, que como sabéis estoy de Mentor en el Campus Internacional de Ciberseguridad, he propuesto varios trabajos para diferentes Másters, así que lo mismo uno de estos trabajos acabas haciéndolo conmigo, si te gusta lo que yo propuesto, lógicamente.

Figura 4: Profesores del Máster en DevSecOps

El profesorado de este Máster Online DevSecOps, pues es de envidiar, por supuesto. Pablo González al que ya conocéis de muchos años conmigo por aquí, Fran Ramírez, Elías Grande y Rafael Troncoso que son los autores del libro de Docker:SecDevOps, Javier Espinosa, Head of Software de Movistar Home y Living Apps en mi unidad CDCO de Telefónica, Juanjo Salvador, Daniel Echeverry, escritor de los libros de Python para Pentesters [2ª Edición], Hacking con Python y DeepWeb: Tor, FreeNet e I2P, y Ricardo García, QA de seguridad en Telefónica.

Figura 5: Libro de Docker:SecDevOps en 0xWord de

Fran Ramírez, Elías Grande y Rafael Troncoso

Además, todos los alumnos de este Máster Online de DevSecOps tendrán como material de complemento para su formación, el libro de Docker:SecDevOps de Fran Ramírez, Elías Grande y Rafael Troncoso que hemos publicado en 0xWord y 500 Tempos de MyPublicInbox para poder consultar con ellos con cualquiera de nosotros cualquier duda, así que después de esta formación, si la aprovechas estudiante, sales listo para empezar a trabajar en estos roles tan demandados. Si quieres más información para convertirte en un "máster" en DevSecOps puedes pedirla en la web de Máster Online DevSecOps.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso) - Consigue 100 Tempos en MyPublicInbox