«Spite-Driven Engineering: cómo la frustración técnica puede mejorar la seguridad en la era cloud con IA»

Introducción

La frase «el sistema funciona, no lo toques» es moneda corriente en equipos de infraestructura, especialmente cuando se trabaja con stacks cloud-native donde cada capa de abstracción promete simplificar la complejidad. Pero como advierte Alex Zenla, CTO y cofundador de Edera, esa actitud pasiva es exactamente lo que abre la puerta a vulnerabilidades evitables en entornos críticos. En un podcast publicado por InfoQ, Zenla expone una filosofía radicalmente práctica: la ingeniería impulsada por el enojo (spite-driven engineering). No se trata de rechazar herramientas existentes por principio, sino de cuestionar abstracciones defectuosas cuando generan problemas reales —como kernels Linux inseguros, contenedores mal aislados o GPUs mal aprovechadas— y construir soluciones que las reemplacen con lógica explícita, verificable y performante.

El enfoque no es nuevo en el mundo del software —recordemos cómo Linus Torvalds creó Git por frustración con los sistemas de control de versiones centralizados—, pero sí adquiere urgencia en la era AI-native, donde los equipos de DevOps heredan problemas de seguridad de capas inferiores que nadie se atreve a tocar. Según Zenla, el problema no es la falta de herramientas, sino la tolerancia a la mediocridad técnica en infraestructuras que escalan a miles de nodos.

Qué ocurrió

Zenla no habla de teorías abstractas: su empresa, Edera, nació de su frustración con dos problemas concretos que observó durante su década en IoT y luego en Google:

1. El aislamiento frágil en Linux: Los kernels monoliticos —incluso con KVM o containers— no garantizan aislamiento seguro entre tenants, especialmente en entornos multi-tenant como los clouds públicos. Esto se agrava con el uso de GPUs consumer-grade repurposadas para cargas de IA, donde la compartición implícita de recursos introduce riesgos de side-channel attacks.

1. La ilusión del «todo en uno»: Herramientas como Docker y Kubernetes simplificaron el despliegue, pero a costa de abstracciones opacas que ocultan fallos críticos. Por ejemplo, el uso de runc en entornos antiguos (pre-2020) permitía escapes de contenedores mediante exploits como CVE-2019-5736, donde un container podía sobrescribir el binario de runc en el host. La solución de Edera es aislar cada workload en una zona segura mediante un hipervisor minimalista basado en Rust, sin compartir el kernel Linux.

En su charla en QCon 2025, Zenla citó a Ariadne Conill —ex-maintainer de Alpine Linux y creadora de Wolfi OS— como coautora intelectual de esta filosofía. Conill, que trabajó en Chainguard desarrollando distribuciones inmutables, reforzó la idea de que la seguridad no se puede delegar a abstracciones genéricas. Su trabajo con Wolfi (una distro basada en musl libc diseñada para entornos cloud) demostró que incluso paquetes aparentemente inocuos como apk-tools podían ser vectores de ataque si no se validaban estáticamente.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

El problema central que exponen Zenla y Conill tiene tres aristas críticas para los equipos técnicos:

1. DevOps: La deuda técnica se acumula en silencio

• Datos concretos: Según un informe de Sysdig 2025, el 68% de los clusters Kubernetes en producción ejecutan kernels Linux con parches de seguridad desactualizados (versiones afectadas: desde Ubuntu 20.04 LTS hasta RHEL 8.6). Esto no es un problema de «parchear cuando se pueda», sino de diseño de sistemas: kernels monoliticos no fueron concebidos para entornos multi-tenant seguros.
• Ejemplo práctico: En entornos con Kubernetes 1.25 y Docker 20.10, el uso de hostNetwork: true en pods permite a un atacante en un namespace acceder al tráfico de red del host. La solución no es solo parchear, sino eliminar esa opción en la API server (configurar --allow-privileged=false y usar CNI estrictos como Calico con políticas NetworkPolicy).

2. Seguridad: Los kernels Linux son el nuevo «bloque de notas» de los atacantes

• Vectores reales:

– Exploits conocidos: Herramientas como Dirty Pipe (CVE-2022-0847) demostraron que incluso kernels recientes pueden ser vulnerables a corrupción de archivos críticos si no se configuran correctamente los permisos de CAP_DAC_READ_SEARCH.

• Impacto cuantificado: Un estudio de Google Cloud 2024 encontró que el 42% de los incidentes de seguridad en GKE se debían a configuraciones inseguras del kernel (ej: módulos cargados dinámicamente, sysctl mal configurados).

3. Cloud: La ilusión de la compartición segura

• Problema subestimado: Las GPUs en clouds públicos (AWS EC2 G5, GCP A3) suelen compartir memoria entre tenants mediante el driver NVIDIA. Esto permite ataques como CUDA-Side-Channel, donde un workload malicioso puede inferir datos de otro tenant midiendo tiempos de acceso a memoria compartida.
• Solución emergente: Proveedores como AWS ya ofrecen instancias con GPUs físicamente aisladas (ej: p4d.24xlarge con GPUs A100 dedicadas), pero requieren migración costosa. Zenla propone un enfoque alternativo: aislar la GPU a nivel de hipervisor, usando tecnologías como AMD SEV-SNP o Intel TDX para virtualizar la GPU sin compartir recursos.

4. SRE: La paradoja de la observabilidad

• Falla común: Equipos de SRE confían en herramientas como Prometheus o Grafana para monitorear contenedores, pero estas herramientas no pueden detectar escapes de aislamiento en kernels inseguros. Por ejemplo, un contenedor con CAP_SYS_PTRACE puede leer memoria del host sin dejar rastro en los logs de Kubernetes.
• Solución: Implementar auditorías de runtime con herramientas como Falco (CNCF) en modo kernel, configurando reglas para detectar:

  - rule: Container runs with elevated capabilities
    desc: "Detecta pods con CAP_SYS_ADMIN o CAP_NET_RAW"
    condition: >
      container and
      (container.capabilities contains CAP_SYS_ADMIN or
       container.capabilities contains CAP_NET_RAW)
    output: >
      "Contenedor peligroso detectado: %container.info.container.name%
      en namespace %container.info.k8s.namespace%
      con capabilities %container.capabilities%"
    priority: WARNING
  

Detalles técnicos

El problema del kernel Linux: un monolitico con 20 millones de líneas de código

Linux no fue diseñado para entornos multi-tenant seguros. Su modelo de seguridad se basa en:

• Capacidades (capabilities): Mecanismo para restringir privilegios de procesos, pero fácilmente eludible si un contenedor tiene CAP_SYS_ADMIN.
• Namespaces: Aislamiento de recursos (PID, network, mount), pero no de hardware. Por ejemplo, dos contenedores pueden compartir la misma GPU aunque estén en namespaces distintos.
• SELinux/AppArmor: Políticas de MAC que reducen el riesgo, pero requieren configuración manual y son propensas a errores de reglas.

• Versiones afectadas: Desde Linux 4.15 (2018) hasta 6.5 (2023).
• Parche crítico: CVE-2021-4034 («PwnKit») afectó a sistemas con polkit mal configurado, permitiendo escalada de privilegios incluso en containers con --read-only-rootfs. Aún hoy, el 15% de los clusters en producción (según datos de Sysdig) no tienen este parche aplicado.

Rust como alternativa: ¿Por qué no es la panacea?

Zenla destaca que Rust no es una solución mágica, pero sí un mecanismo para reducir clases de bugs cuando se usa correctamente:

• Ownership y lifetimes: Eliminan problemas de uso-after-free y race conditions en tiempo de compilación.
• Tipos de estado (typestate): Permiten modelar protocolos complejos (ej: manejo de sockets, conexiones TLS) como tipos que solo compilan si el estado es válido.
• Ejemplo en práctica: La librería ring de Mozilla usa Rust para implementar TLS 1.3 con verificación estática de propiedades de seguridad. En comparación, OpenSSL 3.x tiene 32 CVEs solo en 2024, incluyendo fallos críticos como CVE-2024-2511 (fuga de memoria en el heap).

La propuesta de Edera: Zonas seguras sin compartir kernel

La solución de Edera se basa en tres principios:

1. Aislamiento mediante hipervisor minimalista: Cada workload (container o VM) se ejecuta en una zona aislada, sin compartir el kernel Linux del host. Usan un hipervisor escrito en Rust que implementa:

– Políticas de seguridad predefinidas: Por defecto, deshabilitan features peligrosas como KVM_CREATE_IRQCHIP o KVM_SET_MP_STATE.

– Rendimiento: Afirman lograr un overhead del 5-8% vs. contenedores nativos, medido en benchmarks con sysbench en hosts con Ubuntu 24.04 y kernel 6.6.

1. Imagenes inmutables: Basadas en Wolfi OS (de Ariadne Conill), con:

– Firmado de imágenes: Cada imagen se firma con cosign y se verifica en runtime con rekor.

– Ejemplo de Dockerfile:

     FROM cgr.dev/chainguard/wolfi-base:latest
     RUN apk add --no-cache --virtual .build-deps \
         gcc musl-dev && \
         pip install --no-cache-dir --prefix=/usr/local certifi==2024.2.2
     COPY app.py /app/
     CMD ["python", "/app/app.py"]
     

1. Auditoría continua: Integración con Falco para detectar:

– Uso de ptrace en contenedores no privilegiados.

Qué deberían hacer los administradores y equipos técnicos

1. Para equipos de DevOps: Auditar el stack actual

1. Listar todos los kernels en producción:

   kubectl get nodes -o json | jq -r '.items[].status.nodeInfo.kernelVersion'
   

– Si hay kernels < 5.15, planificar actualización inmediata (Ubuntu 22.04 LTS ya incluye 5.15, pero muchos clusters lo parchean sin actualizar el kernel base).

1. Eliminar privilegios innecesarios en Kubernetes:

     securityContext:
       privileged: false
       readOnlyRootFilesystem: true
       capabilities:
         drop: ["ALL"]
     

– Usar políticas de Pod Security admission (Kubernetes 1.25+):

     apiVersion: policy/v1
     kind: PodSecurity
     metadata:
       name: restricted
     spec:
       privileged: false
       allowPrivilegeEscalation: false
     

1. Aislar GPUs en entornos multi-tenant:

     aws ec2 modify-instance-metadata-options \
       --instance-id i-1234567890 \
       --http-endpoint enabled \
       --http-tokens required \
       --http-tokens-versionv2
     

– Configurar nvidia-container-toolkit para usar GPUs dedicadas:

     docker run --gpus all:1 nvcr.io/nvidia/k8s/cuda-sample:nbody
     

2. Para equipos de Seguridad: Implementar capas de defensa en profundidad

• Activar SELinux/AppArmor en todos los hosts:

  sudo setenforce 1  # Modo enforcing
  sudo aa-status      # Verificar políticas activas
  

• Configurar auditd para monitorear syscalls peligrosos:

  sudo auditctl -a exit,always -F arch=b64 -S open,execve,ptrace -F key=security
  

• Usar herramientas como Falco con reglas personalizadas:

  - rule: Kernel module loaded in container
    desc: "Detecta carga de módulos kernel desde un container"
    condition: >
      spawned_process and
      container and
      proc.name = "insmod" or proc.name = "modprobe"
    output: >
      "Módulo kernel cargado en container: %proc.name%
      por %user.name% en %container.info.container.name%"
    priority: CRITICAL
  

3. Para equipos de SRE: Mejorar la observabilidad sin confiar en herramientas inseguras

1. Despliegue de eBPF para monitoreo seguro:

   sudo apt install -y bpfcc-tools linux-headers-$(uname -r)
   sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%s -> %s\n", comm, str(args->filename)); }'
   

1. Integrar Falco con Prometheus/Grafana:

   # Reglas de Falco para exportar a Prometheus
   - rule: Unauthorized process started in container
     desc: "Proceso no autorizado en container"
     condition: >
       spawned_process and container
       and not container.entrypoint in ("/usr/bin/bash", "/bin/sh", "/usr/local/bin/python")
     output: >
       "Proceso sospechoso en container: %proc.name%
       ejecutado por %user.name%"
     priority: WARNING
     tags: [container, process]
   

1. Validar imágenes con Cosign:

   cosign verify --key cosign.pub ghcr.io/mi-empresa/mi-app:1.0.0
   

4. Para arquitectos: Evaluar soluciones alternativas al kernel Linux

• Hipervisores minimalistas:

– Firecracker (AWS, Rust, para VMs seguras).

– Edera (propuesta por Zenla, con zonas de aislamiento).

• Sistemas operativos alternativos:

– Unikernels (especializados para workloads).

La propuesta de «spite-driven engineering» de Alex Zenla no es un llamado a reinventar la rueda, sino a dejar de normalizar lo inseguro. El problema no es la falta de herramientas, sino la complacencia con abstracciones defectuosas que prometen simplificar la infraestructura pero ocultan riesgos críticos en kernels Linux, GPUs compartidas y contenedores con privilegios excesivos.

Los equipos técnicos tienen hoy herramientas concretas para actuar:

• Para DevOps: Auditar kernels, eliminar privilegios innecesarios y aislar GPUs.
• Para Seguridad: Implementar SELinux/AppArmor, auditd y Falco con reglas estrictas.
• Para SRE: Mejorar la observabilidad con eBPF y evitar confiar en logs de contenedores como única fuente de verdad.
• Para arquitectos: Evaluar hipervisores minimalistas en Rust (CrosVM, Firecracker) o soluciones como Edera cuando el riesgo justifique un cambio radical.

Como dice Zenla: «No se trata de odiar las herramientas existentes, sino de dejar de aceptarlas cuando fallan en lo básico». La seguridad en la era cloud no se construye con más abstracciones, sino con menos complacencia.

Fuentes

• Podcast de InfoQ: Spite-Driven Engineering
• Sysdig Container Security Report 2025
• Google Cloud: Kernel Attack Surface in GKE
• CVEs en OpenSSL 2024
• Falco: Reglas para Kubernetes
• Wolfi OS: Distro inmutable para cloud
• Edera: Zonas de aislamiento con Rust