Skip to content

Cuestionario sobre fundamentos de eBPF

Versiones compatibles: Kernel de Linux 4.18+, Kubernetes 1.25+ Última actualización: February 23, 2026

Este cuestionario evalúa tu comprensión general de eBPF (extended Berkeley Packet Filter), desde conceptos básicos hasta sus aplicaciones en entornos Kubernetes.

Preguntas de opción múltiple

  1. ¿Qué NO comprueba el verificador de eBPF?
    • A) Que no haya bucles infinitos
    • B) Que no haya acceso a memoria fuera de límites
    • C) Velocidad de ejecución del programa
    • D) Que no se usen variables sin inicializar
Ver respuesta

Respuesta: C) Velocidad de ejecución del programa

Explicación: El verificador de eBPF comprueba que no haya bucles infinitos (verificación de estructura DAG), que no haya acceso a memoria fuera de límites, que no se usen variables sin inicializar, que las llamadas a funciones helper sean correctas y que la terminación del programa esté garantizada para asegurar la seguridad del programa. La velocidad de ejecución del programa no es un elemento de verificación para el verificador.

  1. ¿Qué valor de retorno de un programa XDP (eXpress Data Path) envía el paquete de vuelta a la misma NIC?
    • A) XDP_DROP
    • B) XDP_PASS
    • C) XDP_TX
    • D) XDP_REDIRECT
Ver respuesta

Respuesta: C) XDP_TX

Explicación: Los valores de retorno de un programa XDP tienen los siguientes significados:

  • XDP_DROP: Descartar paquete
  • XDP_PASS: Pasar a la pila del kernel
  • XDP_TX: Devolver el paquete a la misma NIC
  • XDP_REDIRECT: Reenviar a otra interfaz
  • XDP_ABORTED: Manejo de errores

XDP_TX se usa cuando quieres enviar el paquete de vuelta a la interfaz de red que lo recibió.

  1. ¿Qué NO es una función principal de eBPF Maps?
    • A) Compartir datos entre el kernel y el espacio de usuario
    • B) Almacenamiento de estado
    • C) Compilar programas eBPF
    • D) Transmisión de datos de eventos
Ver respuesta

Respuesta: C) Compilar programas eBPF

Explicación: eBPF maps son estructuras de datos utilizadas para compartir datos entre el kernel y el espacio de usuario y para almacenar estado. Los maps se usan para la transmisión de datos de eventos (PERF_EVENT_ARRAY, RINGBUF), almacenamiento clave-valor (HASH), recopilación de estadísticas (PERCPU_ARRAY) y más. La compilación de programas eBPF la realizan Clang/LLVM y no es una función de los maps.

  1. ¿Cuál es la principal ventaja que proporciona eBPF cuando Cilium reemplaza a kube-proxy?
    • A) Rendimiento O(n) proporcional al número de servicios
    • B) Requiere evaluación de reglas iptables
    • C) Rendimiento O(1) mediante búsqueda en map
    • D) Usa Netfilter
Ver respuesta

Respuesta: C) Rendimiento O(1) mediante búsqueda en map

Explicación: El kube-proxy tradicional (modo iptables) presenta una degradación de rendimiento O(n) a medida que aumenta el número de servicios. Cilium usa eBPF maps para proporcionar un rendimiento de búsqueda constante O(1). Esto ofrece una mejora significativa del rendimiento en todos los aspectos, incluido el tiempo de establecimiento de conexiones, el uso de CPU y las conexiones por segundo.

  1. ¿Cuál es el propósito principal de bpftrace?
    • A) Compilar programas eBPF a C
    • B) Cargar módulos del kernel
    • C) Trazado de alto nivel al estilo DTrace
    • D) Construir imágenes de contenedor
Ver respuesta

Respuesta: C) Trazado de alto nivel al estilo DTrace

Explicación: bpftrace es un lenguaje de trazado de alto nivel al estilo DTrace que te permite trazar el sistema con comandos simples de una sola línea. Por ejemplo, puedes realizar fácilmente tareas como contar llamadas al sistema, rastrear bytes leídos por proceso, trazar aperturas de archivos y rastrear conexiones TCP.

  1. En TracingPolicy de Tetragon, ¿qué acción termina inmediatamente un proceso cuando se detecta acceso malicioso a archivos?
    • A) action: Block
    • B) action: Sigkill
    • C) action: Deny
    • D) action: Terminate
Ver respuesta

Respuesta: B) action: Sigkill

Explicación: En TracingPolicy de Tetragon, action: Sigkill en matchActions termina inmediatamente el proceso con una señal SIGKILL cuando ocurre un evento que coincide con la policy. Esto se usa para bloquear el acceso a archivos sensibles o conexiones de red maliciosas en tiempo real.

  1. ¿Qué NO es una característica principal de Hubble?
    • A) Observación de flujos de red
    • B) Seguimiento de consultas DNS
    • C) Compilar programas eBPF
    • D) Monitoreo de decisiones de policy
Ver respuesta

Respuesta: C) Compilar programas eBPF

Explicación: Hubble es una plataforma de observabilidad de red integrada en Cilium que recopila y monitorea flujos de red, consultas DNS, solicitudes HTTP, decisiones de policy y más. Hubble es una herramienta de observabilidad y no proporciona funcionalidad de compilación de programas eBPF.

  1. ¿Qué problema resuelve CO-RE (Compile Once, Run Everywhere)?
    • A) Mejorar la velocidad de ejecución de los programas eBPF
    • B) Portabilidad entre diferentes versiones del kernel
    • C) Reducir el uso de memoria
    • D) Reducir la latencia de red
Ver respuesta

Respuesta: B) Portabilidad entre diferentes versiones del kernel

Explicación: CO-RE usa libbpf y BTF (BPF Type Format) para permitir que los programas eBPF compilados una vez se ejecuten en varias versiones del kernel. Esto reduce las dependencias de los encabezados del kernel y maneja automáticamente la reubicación de structs, eliminando la necesidad de recompilar para cada versión del kernel.

  1. ¿Qué detecta Falco usando eBPF?
    • A) Uso de ancho de banda de red
    • B) Comportamiento anómalo en tiempo de ejecución
    • C) Capacidad del disco
    • D) Temperatura de la CPU
Ver respuesta

Respuesta: B) Comportamiento anómalo en tiempo de ejecución

Explicación: Falco es un proyecto CNCF que usa eBPF para detectar comportamiento anómalo en tiempo de ejecución. Detecta y alerta sobre amenazas de seguridad como leer archivos sensibles, ejecutar shells en contenedores e intentos de escalada de privilegios con base en reglas.

  1. ¿Cuál es el límite de tamaño de stack para programas eBPF?
    • A) 128 bytes
    • B) 256 bytes
    • C) 512 bytes
    • D) 1024 bytes
Ver respuesta

Respuesta: C) 512 bytes

Explicación: Los programas eBPF tienen un límite de tamaño de stack de 512 bytes. Para sortear este límite, necesitas usar maps como PERCPU_ARRAY para asignar búferes más grandes. Este límite existe para garantizar la seguridad del kernel.

Preguntas de respuesta corta

  1. ¿Cómo se llama el compilador que convierte bytecode eBPF en código máquina nativo?
Ver respuesta

Respuesta: Compilador JIT (compilador Just-In-Time)

Explicación: El compilador JIT convierte bytecode eBPF en código máquina nativo. Esto proporciona una mejora de rendimiento de 4 a 5 veces en comparación con el intérprete, y se aplican optimizaciones específicas de la arquitectura. Se puede habilitar configurando /proc/sys/net/core/bpf_jit_enable en 1.

  1. ¿Cómo se llama el tipo de programa eBPF que traza dinámicamente llamadas a funciones del kernel?
Ver respuesta

Respuesta: Kprobes (o Kprobe)

Explicación: Kprobes es un tipo de programa eBPF que traza dinámicamente llamadas a funciones del kernel. A diferencia de Uprobes, que traza funciones del espacio de usuario, Kprobes traza funciones dentro del kernel. Por ejemplo, puedes trazar la función tcp_connect para recopilar información de conexiones TCP.

  1. ¿Cómo se llama la plataforma de observabilidad de red integrada en Cilium?
Ver respuesta

Respuesta: Hubble

Explicación: Hubble es una plataforma de observabilidad de red integrada en Cilium que recopila datos del dataplane eBPF, incluidos flujos de red, consultas DNS, solicitudes HTTP y decisiones de policy. Puedes observar el tráfico de red del cluster en tiempo real mediante Hubble CLI, Hubble UI y Hubble Relay.

  1. ¿Qué capability de Linux se requiere para cargar programas eBPF? (kernel 5.8 y superior)
Ver respuesta

Respuesta: CAP_BPF

Explicación: En kernel 5.8 y superior, se requiere la capability CAP_BPF para cargar programas eBPF. En versiones anteriores, se requería CAP_SYS_ADMIN. Además, CAP_PERFMON es necesaria para adjuntarse a eventos de monitoreo de rendimiento, y CAP_NET_ADMIN es necesaria para adjuntar programas XDP/TC.

  1. ¿Cómo se llama el proyecto CNCF que monitorea el consumo de energía de contenedores usando eBPF?
Ver respuesta

Respuesta: Kepler (Kubernetes-based Efficient Power Level Exporter)

Explicación: Kepler es un proyecto que usa eBPF para monitorear el consumo de energía de contenedores. Proporciona métricas en formato Prometheus como kepler_container_joules_total (consumo de energía por contenedor) y kepler_container_gpu_joules_total (consumo de energía de GPU).

Preguntas prácticas

  1. Escribe los comandos para usar bpftool para listar los programas eBPF cargados actualmente en el sistema y consultar información detallada sobre un programa específico.
Ver respuesta

Respuesta:

bash
# List loaded eBPF programs
sudo bpftool prog list

# Query detailed information for a specific program (ID: 123)
sudo bpftool prog show id 123

# Dump program bytecode
sudo bpftool prog dump xlated id 123

# Dump JIT compiled code
sudo bpftool prog dump jited id 123

Explicación:bpftool prog list muestra una lista de todos los programas eBPF cargados actualmente. Puedes comprobar el ID, tipo, nombre, ubicación de adjunción, etc. de cada programa. Usa bpftool prog show id <ID> para consultar información detallada sobre un programa específico, y dump xlated y dump jited para ver el bytecode y el código nativo compilado con JIT.

  1. Escribe un comando bpftrace de una sola línea para trazar en tiempo real las conexiones TCP que ocurren desde todos los procesos del sistema.
Ver respuesta

Respuesta:

bash
# TCP connection tracing (Method 1: using kprobe)
sudo bpftrace -e 'kprobe:tcp_connect { printf("%s (PID: %d) connecting...\n", comm, pid); }'

# TCP connection tracing (Method 2: using tracepoint, more detailed info)
sudo bpftrace -e 'tracepoint:tcp:tcp_connect { printf("%s -> %s:%d\n", ntop(args->saddr), ntop(args->daddr), args->dport); }'

# Count TCP connections by process
sudo bpftrace -e 'kprobe:tcp_connect { @[comm] = count(); }'

Explicación: bpftrace es un lenguaje de trazado de alto nivel al estilo DTrace que te permite trazar el sistema con comandos simples de una sola línea. kprobe:tcp_connect se activa cuando se llama a la función tcp_connect del kernel. comm representa el nombre del proceso y pid representa el ID del proceso. Usar tracepoints te permite obtener también direcciones IP de origen/destino e información de puertos.

  1. Escribe el comando para usar Hubble CLI para observar únicamente paquetes descartados de un namespace específico.
Ver respuesta

Respuesta:

bash
# Observe dropped packets in a specific namespace
hubble observe --namespace production --verdict DROPPED

# Observe dropped packets with real-time streaming
hubble observe --namespace production --verdict DROPPED -f

# Output detailed information of dropped packets in JSON format
hubble observe --namespace production --verdict DROPPED -o json

# Observe dropped packets from a specific Pod
hubble observe --from-pod production/frontend --verdict DROPPED

Explicación: Hubble es una herramienta de observabilidad de red integrada en Cilium. La opción --namespace filtra por un namespace específico, y --verdict DROPPED filtra solo paquetes descartados. La opción -f proporciona transmisión en tiempo real, y -o json proporciona salida en formato JSON. Analizar paquetes descartados ayuda a diagnosticar problemas de network policy o errores de configuración.

Preguntas avanzadas

  1. Explica las tres ventajas principales que tiene eBPF sobre los módulos del kernel, y describe específicamente qué beneficios proporciona cada una en entornos Kubernetes.
Ver respuesta

Respuesta:

Ventajas principales de eBPF sobre los módulos del kernel y sus beneficios en entornos Kubernetes:

1. Seguridad (seguridad garantizada mediante el verificador)

  • Ventaja: El verificador de eBPF comprueba bucles infinitos, violaciones de acceso a memoria, variables sin inicializar, etc. antes de cargar el programa para evitar caídas del kernel.
  • Beneficio en Kubernetes: Los plugins CNI (Cilium) y las herramientas de seguridad (Tetragon, Falco) pueden ejecutarse de forma segura en clusters de producción. A diferencia de los módulos del kernel, incluso si hay errores, todo el sistema no se caerá, lo que mantiene alta disponibilidad.

2. Portabilidad (independencia de la versión del kernel mediante CO-RE)

  • Ventaja: Usando CO-RE (Compile Once, Run Everywhere) y BTF, los programas eBPF compilados una vez pueden ejecutarse en varias versiones del kernel. No se necesita recompilación para cada versión del kernel.
  • Beneficio en Kubernetes: Las mismas soluciones de red y seguridad se pueden desplegar en entornos de nodos heterogéneos (nodos con diferentes versiones del kernel). Los problemas de compatibilidad se reducen considerablemente durante actualizaciones del cluster o adiciones de nodos.

3. Carga dinámica (carga/descarga de programas sin reinicio)

  • Ventaja: Los programas eBPF pueden cargarse y descargarse dinámicamente sin reiniciar el sistema. La funcionalidad se puede agregar o cambiar en tiempo de ejecución.
  • Beneficio en Kubernetes: Las network policies, reglas de seguridad y configuraciones de observabilidad se pueden aplicar inmediatamente sin reiniciar nodos. Los cambios en Cilium NetworkPolicy o Tetragon TracingPolicy se reflejan en tiempo real, lo que permite mejoras de seguridad sin interrupción operativa.

Ventajas adicionales:

  • Rendimiento: La compilación JIT proporciona rendimiento a nivel de código nativo, lo que permite búsquedas de Service O(1) al reemplazar kube-proxy.
  • Dificultad de desarrollo: Relativamente más fácil que el desarrollo de módulos del kernel, lo que permite un desarrollo y despliegue rápidos de funcionalidades.
  1. Diseña un enfoque para detectar y bloquear el acceso a archivos sensibles dentro de contenedores usando una solución de seguridad basada en eBPF (Tetragon o Falco) en un cluster Kubernetes. Incluye ejemplos de TracingPolicy o reglas Falco en tu explicación.
Ver respuesta

Respuesta:

Diseño de seguridad para acceso a archivos sensibles basado en eBPF

1. Definición de requisitos de seguridad

  • Objetivos de detección: /etc/shadow, /etc/passwd, /etc/sudoers, /var/run/secrets/ (Kubernetes secrets)
  • Enfoque de respuesta: alerta en la detección, terminación del proceso para casos graves

2. Implementación de Tetragon TracingPolicy

yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: sensitive-file-protection
spec:
  kprobes:
    # Monitor sensitive file opens
    - call: security_file_open
      syscall: false
      args:
        - index: 0
          type: file
      selectors:
        # Detect and log Kubernetes secret access
        - matchArgs:
            - index: 0
              operator: Prefix
              values:
                - /var/run/secrets/kubernetes.io/
          matchActions:
            - action: Post  # Event logging

        # Block system authentication file access
        - matchArgs:
            - index: 0
              operator: Prefix
              values:
                - /etc/shadow
                - /etc/sudoers
          matchNamespaces:
            - namespace: default
              operator: In
          matchActions:
            - action: Sigkill  # Immediately terminate process

3. Implementación de reglas Falco

yaml
# /etc/falco/rules.d/sensitive-files.yaml
- rule: Read Kubernetes Secrets
  desc: Detect reading of Kubernetes secret files in containers
  condition: >
    open_read and
    container and
    (fd.name startswith /var/run/secrets/kubernetes.io/ or
     fd.name startswith /etc/shadow or
     fd.name startswith /etc/sudoers) and
    not proc.name in (kubelet, containerd)
  output: >
    Sensitive file access detected
    (file=%fd.name user=%user.name process=%proc.name
     container=%container.name namespace=%k8s.ns.name
     pod=%k8s.pod.name)
  priority: WARNING
  tags: [security, filesystem]

- rule: Write to Sensitive System Files
  desc: Detect writing to sensitive system files
  condition: >
    open_write and
    container and
    fd.name in (/etc/passwd, /etc/shadow, /etc/sudoers)
  output: >
    Attempt to modify sensitive file
    (file=%fd.name user=%user.name process=%proc.name
     container=%container.name)
  priority: CRITICAL
  tags: [security, filesystem]

4. Despliegue y monitoreo

bash
# Install Tetragon and apply policy
helm install tetragon cilium/tetragon -n kube-system
kubectl apply -f sensitive-file-protection.yaml

# Monitor events
kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon \
  -c export-stdout -f | tetra getevents -o compact

# Install Falco (eBPF driver)
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=modern_ebpf

# Check Falco alerts
kubectl logs -n falco -l app.kubernetes.io/name=falco -f

5. Explicación de la arquitectura

┌─────────────────────────────────────────────────┐
│              Kubernetes Cluster                 │
│  ┌─────────────────┐    ┌─────────────────┐    │
│  │   Application   │    │   Application   │    │
│  │      Pod        │    │      Pod        │    │
│  └────────┬────────┘    └────────┬────────┘    │
│           │                      │             │
│  ┌────────▼──────────────────────▼────────┐   │
│  │              eBPF Layer                 │   │
│  │  ┌─────────────┐  ┌─────────────┐     │   │
│  │  │ Tetragon    │  │  Falco      │     │   │
│  │  │ TracingPol. │  │  Rules      │     │   │
│  │  └──────┬──────┘  └──────┬──────┘     │   │
│  │         │                 │            │   │
│  │         ▼                 ▼            │   │
│  │   [File Access Event Capture]          │   │
│  └────────────────────────────────────────┘   │
│                      │                         │
│  ┌───────────────────▼───────────────────┐   │
│  │           Security Response            │   │
│  │  • Event logging (Post)               │   │
│  │  • Process termination (Sigkill)      │   │
│  │  • SIEM alert forwarding              │   │
│  └───────────────────────────────────────┘   │
└─────────────────────────────────────────────────┘

Este diseño aprovecha la visibilidad a nivel de kernel de eBPF para detectar y responder al acceso a archivos sensibles en tiempo real sin modificar las aplicaciones.


Volver a los materiales de aprendizaje | Siguiente cuestionario: Tecnología de contenedores