Secure Boot para módulos de kernel propios: firmado, flujo de trabajo MOK y estrategia de distribución

Secure Boot para módulos de kernel propios es, para los operadores de infraestructuras modernas Linux y Kubernetes, un aspecto central de seguridad y operación. En esta guía encontrará instrucciones orientadas a la práctica: qué componentes intervienen, cómo firmar módulos de forma segura, cómo operacionalizar el flujo de trabajo MOK (Machine Owner Key), qué estrategias de distribución tienen sentido en flotas, cómo integrar DKMS y qué precauciones específicas requieren los clústeres de Kubernetes. El objetivo es una operación reproducible, pasos de verificación claros y una estrategia de recuperación fiable.

¿Por qué Secure Boot bloquea módulos propios?

UEFI Secure Boot valida la integridad de bootloaders y kernels mediante una cadena de certificados. shim es un boot-stub firmado por el equipo de la distribución que puede cargar el kernel y, al mismo tiempo, proporciona mecanismos (p. ej. MOK) para que los operadores registren sus propios certificados. Una vez que el kernel ha activado el modo Lockdown, verifica las firmas de los módulos de kernel (.ko) cargados posteriormente. Si falta una firma de confianza o el certificado correspondiente, la carga se rechaza y controladores, plugins de almacenamiento o funciones de red pueden dejar de funcionar.

Aclaración de términos: PK, KEK, db y MOK

PK significa Platform Key (clave principal de firmware), KEK son Key Exchange Keys (para la gestión de firmas) y db es la base de datos de firmware con certificados de confianza. MOK (Machine Owner Key) es un mecanismo en shim que permite a los operadores registrar sus propios certificados sin modificar la PK/KEK/db de la firmware. En el kernel, los certificados aceptados se gestionan en keyrings — si no están ahí, la verificación falla.

Comprobaciones preparatorias del sistema

Antes de adaptar procesos o pipelines, determine el estado por sistema. Compruebe el estado de Secure Boot, el modo Lockdown y las herramientas.

# Basischecks
sudo mokutil --sb-state 2>/dev/null || echo "mokutil fehlt oder Secure Boot nicht aktiv"
sudo mokutil --list-enrolled 2>/dev/null || echo "Keine enrolled MOKs oder mokutil nicht vorhanden"
cat /sys/kernel/security/lockdown 2>/dev/null || echo "Lockdown-Status nicht verfügbar"
dmesg | egrep -i "module verification failed|Required key not available|lockdown" | tail -n 50

Si dmesg muestra mensajes como «module verification failed», es un indicador claro de problemas de firma o de claves.

Firmado: concepto, protección de claves y procedimiento

Un módulo de kernel se firma con una firma PKCS#7 que el kernel verifica al cargarlo. Formalmente necesita dos artefactos: una clave privada de firmado (para crear la firma) y el certificado asociado (público), que en los sistemas destino se registra como de confianza. El principio operativo más importante: la clave privada no debe distribuirse entre muchos servidores.

Generación de claves (ejemplo seguro)

mkdir -p /root/module-signing && cd /root/module-signing
# Privaten RSA-Schlüssel + Self-Signed-Zertifikat erzeugen
openssl req -new -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes 
  -subj "/CN=Kernel Module Signing (MOK)/" 
  -keyout MOK.priv -out MOK.pem
# Konvertieren ins DER-Format für mokutil/import
openssl x509 -in MOK.pem -outform DER -out MOK.der
chmod 600 MOK.priv
chmod 644 MOK.pem MOK.der

Nota: la opción -nodes elimina la frase de contraseña; eso permite el firmado automatizado, pero aumenta el requisito de protección sobre el almacenamiento de la clave (HSM, servidor de firmado seguro o bóveda de CI/CD).

Operacionalizar el flujo de trabajo MOK

El flujo clásico: importa el certificado público (formato DER) con mokutil –import. Eso genera una solicitud Pending-Enrollment que debe confirmarse en el siguiente arranque en la interfaz Shim basada en firmware/gráfica. Ahí es donde con frecuencia fallan los despliegues: la confirmación requiere consola/monitor o acceso serial.

# Zertifikat importieren (erzeugt Enrollment-Request)
sudo mokutil --import /root/module-signing/MOK.der
# Nach Reboot: enrolled keys auflisten
sudo mokutil --list-enrolled

Opciones operativas para flotas grandes:

• Imágenes preconfiguradas: imagen ya provista con MOKs (para entornos VM y cloud, si el proveedor de nube lo permite).
• Consola remota/automatización serial: utilice iKVM o APIs de redirección de consola para la confirmación automatizada.
• Gestión de firmware: en hosts físicos el OEM/proveedor de hosting puede gestionar claves de forma central en la base de datos de firmware.

No existe un método estándar universal y no interactivo para la inscripción de MOK en cualquier implementación de firmware; por eso se requiere un inventario preciso y un diseño de procesos.

Firmar módulos e integrar en CI/CD

La firma debe convertirse en un paso estándar en su pipeline de build/liberación. Para ello conviene usar un contenedor/host de firmado dedicado en la CI o un servicio de firma con almacenamiento seguro de secretos (HSM, Vault). Principios importantes:

• La firma como último paso de build antes del empaquetado.
• Nunca almacene las claves de firma directamente en los paquetes de destino ni en sistemas productivos.
• Verifique los módulos tras la firma con modinfo (Signer, sig_key, sig_hash).

Ejemplo: job de GitLab-CI para firmar

stages:
  - build
  - sign

build_module:
  stage: build
  script:
    - make -C src
    - cp src/mydriver.ko artifacts/
  artifacts:
    paths:
      - artifacts/

sign_module:
  stage: sign
  dependencies:
    - build_module
  image: ubuntu:22.04
  variables:
    SIGN_KEY_PATH: /buildsecrets/MOK.priv
    SIGN_CERT_PATH: /buildsecrets/MOK.pem
  script:
    - apt-get update && apt-get install -y openssl Linux-headers-$(uname -r)
    - /usr/src/Linux-headers-$(uname -r)/scripts/sign-file sha256 "$SIGN_KEY_PATH" "$SIGN_CERT_PATH" artifacts/mydriver.ko
  artifacts:
    paths:
      - artifacts/mydriver.ko

En la CI guarde la clave privada en un almacén de secretos protegido (GitLab CI/CD Variables con enmascaramiento o HashiCorp Vault). El runner realiza la firma en un entorno controlado.

Integración con DKMS: hooks y automatización

DKMS recompila módulos tras actualizaciones del kernel. Sin hooks, DKMS con frecuencia genera módulos no firmados que no se cargan después de un upgrade del kernel. Añada scripts de DKMS que firmen tras cada build.

Ejemplo: hook post-install de DKMS

# /usr/src//2.0/dkms.conf
# In dkms.conf
POST_BUILD="/usr/src//2.0/dkms-sign.sh"

# /usr/src//2.0/dkms-sign.sh
#!/bin/bash
set -euo pipefail
MODULE_PATH="$1/$2"
SIGN_KEY="/etc/secure-signing/MOK.priv"
SIGN_CERT="/etc/secure-signing/MOK.pem"

if [ -f "$MODULE_PATH" ]; then
  /usr/src/Linux-headers-$(uname -r)/scripts/sign-file sha256 "$SIGN_KEY" "$SIGN_CERT" "$MODULE_PATH"
  echo "Signed $MODULE_PATH"
else
  echo "Module $MODULE_PATH not found"
fi

Almacene las claves de firma en un host de firmado dedicado o en una ruta protegida con acceso restringido. En los hosts destino distribuya únicamente el certificado público para la fase de inscripción.

Estrategia de distribución para flotas

Una imagen objetivo robusta incluye:

• Firmado central en CI/CD o en un servicio de firma dedicado.
• Distribución del certificado público (MOK.der) de forma controlada mediante imagen, paquete o gestión de configuración (p. ej. Ansible/AWX), pero el enrolamiento aún requiere reinicio y acceso a consola.
• Entrega empaquetada (DEB/RPM) en lugar de copias de archivos individuales; scripts post-instalación ejecutan depmod y actualizaciones de initramfs.
• Canary-Rollouts: primero pocos hosts, validar y luego desplegar a gran escala.

Evite distribuir la clave privada o desactivar Secure Boot de forma general.

Perspectiva de Kubernetes: operaciones de Worker y mejores prácticas

En Kubernetes, los Worker-Nodes son puntos de operación directos: la falta de módulos para CNI (red), CSI (almacenamiento) o drivers de hardware provoca pods que no arrancan o errores de almacenamiento. Por eso debe diferenciar claramente las estrategias de infraestructura y de clúster.

Estrategias para operadores del clúster

• Immutable Node Images: Construya imágenes de nodo (AMI/plantillas VM) con módulos ya firmados — así se evita la compilación DKMS en los nodos de producción.
• Rolling Upgrade con Canary-Pool: pruebe nuevas imágenes primero en nodos de prueba exclusivos.
• Node-Batching: nunca reinicie todos los workers simultáneamente; respete los PodDisruptionBudgets.
• Preflight-Gates: comprobaciones automatizadas antes del reinicio para verificar que hay módulos firmados para el kernel objetivo.

Ejemplo: proceso de reinicio para un Node

# Drain Node
kubectl drain node-01 --ignore-daemonsets --delete-emptydir-data --timeout=10m
# Reboot und Healthcheck
ssh root@node-01 'reboot'
# Nach Reboot: Node wieder in Betrieb nehmen
kubectl uncordon node-01
kubectl get nodes --selector=kubernetes.io/hostname=node-01 -o wide

DaemonSet para la comprobación preflight de módulos

Puede desplegar un DaemonSet privilegiado que ejecute modinfo en cada nodo y reporte campos de firma (atención: implicaciones de seguridad por los privilegios).

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: module-signature-check
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: module-signature-check
  template:
    metadata:
      labels:
        name: module-signature-check
    spec:
      hostPID: true
      hostNetwork: true
      containers:
      - name: checker
        image: busybox
        securityContext:
          privileged: true
        command: ["/bin/sh", "-c"]
        args:
          - for m in /lib/modules/$(uname -r)/**/*.ko; do if [ -f "$m" ]; then modinfo "$m" | egrep -i "signer|sig_key|sig_hash|vermagic" || echo "$m: no sig info"; fi; done; sleep 3600
      tolerations:
      - operator: "Exists"
      RESTartPolicy: Always

El checker aporta indicios sobre si los módulos críticos están firmados; no debe, sin embargo, sustituir a la instancia primaria de confianza.

Key-Rotation, Revocation und Notfallplanung

La rotación de claves es una tarea organizativa: planifique una fase de transición en la que se acepten simultáneamente las claves antiguas y las nuevas.

1. Genere un nuevo par de claves y publique el nuevo certificado (MOK) para la fase de enrolamiento.
2. Inscriba el nuevo certificado en todos los hosts (Canary → Batch).
3. Firme progresivamente los nuevos módulos con la clave nueva y distribúyalos.
4. Tras un periodo de observación, elimine la clave antigua.

Para la revocación (p. ej., clave privada comprometida) debe revisar los mecanismos de firmware o del kernel para el bloqueo (dbx o políticas locales); documente los procesos Break-Glass y el protocolo de comunicación.

Monitorización, pruebas y comprobaciones Preflight en CI

Las pruebas automatizadas son decisivas: CI debe comprobar antes del release que, tras la firma, un módulo informe un componente de firma con modinfo. En producción monitorice las entradas de dmesg y las métricas de disponibilidad de los nodos (Node-Readiness). Ejemplo de comprobación en CI:

# CI Preflight
modinfo artifacts/mydriver.ko | egrep -i "signer|sig_key|sig_hash" || (echo "ERROR: Modul nicht signiert" && exit 1)
# Simulierter modprobe (falls sicherheitsseitig erlaubt)
sudo modprobe -v artifacts/mydriver.ko || true
sudo dmesg | tail -n 50 | egrep -i "module verification failed|Required key not available" && exit 1 || echo "Preflight OK"

Estrategia de retroceso (Break-Glass) — por pasos

Si un despliegue provoca fallos:

• Identifique desde la consola los errores de dmesg y modprobe.
• Arranque, si es posible, con un kernel anterior desde el menú de arranque.
• Si el enrollment falla: realice el MOK-Enrollment manualmente a través de la consola (con acceso físico) o utilice procesos de consola remota preplanificados.
• Como último recurso y solo de forma temporal: desactive Secure Boot (firmware) para salvar sistemas críticos — y luego analice forensemente la causa.

Cada caso de Break-Glass debe documentarse, evaluarse y seguidamente modificarse el proceso para evitar que se repita.

Lista de comprobación operativa breve antes de un gran despliegue

• Inventario: hosts con Secure Boot, variantes de firmware y opciones de consola.
• Modelo de firma: clave privada segura, certificado público distribuido.
• CI/CD: firma automatizada; comprobaciones Preflight implementadas.
• DKMS: utilizar hooks o imágenes construidas.
• Kubernetes: estrategia de imagen de nodo, despliegue canario, scripts de drain/uncordon.
• Monitorización: patrones de dmesg, Node-Readiness, alertas.
• Rollback: backups de arranque/kernel, procedimientos de consola, contactos administrativos.

Conclusión

Secure Boot protege la cadena de arranque y aumenta la seguridad en el centro de datos, pero solo tiene sentido operativo si los procesos de firmado, la gestión de claves y el enrollment están organizados de forma rigurosa. Basándose en un modelo central de firmado, la firma automatizada en CI/DKMS-Hooks, la entrega empaquetada y despliegues canario cuidadosos, Secure Boot puede operarse de forma fiable en entornos heterogéneos Linux y Kubernetes. Planifique las rutas de enrollment, pruebe las comprobaciones Preflight y defina procedimientos claros de Break-Glass — así Secure Boot permanecerá activo y sus propios módulos del kernel seguirán disponibles y mantenibles a través de actualizaciones de kernel.

Secure Boot para módulos de kernel propios: riesgos operativos y alternativas de arquitectura

Además de la firma y del MOK-Enrollment debe considerar la arquitectura operativa y los posibles riesgos de punto único de fallo. Son decisivas tres áreas: custodia de claves, ruta de distribución y enrollment, y observabilidad. Patrones de arquitectura probados minimizan la superficie de ataque y el riesgo de fallo.

Modelo de arquitectura recomendado:

• Servicio central de firmado con HSM o Vault: la clave privada permanece en un servicio asegurado; CI/CD recibe solo tokens autorizados de corta duración. Así evita la distribución de claves privadas a los hosts destino.
• Metadatos de firma en los paquetes: complemente DEB/RPM con información del firmante y procedencia de checksums para que las herramientas de despliegue puedan tomar decisiones de preflight.
• Estrategias de enrolamiento separadas por clases de host: Cloud‑VMs, Bare‑Metal y Bare‑Metal con consola limitada requieren flujos de enrolamiento distintos (imagen con MOK previa, iKVM/serial para los enrolamientos, cambios de firmware del proveedor para hosts críticos).

Medidas operativas de precaución:

• Inventario: implementación del firmware, ¿consola disponible?, capacidades soportadas (shim, mokutil).
• Pool canario con telemetría: valide las cargas de módulos, la disponibilidad de nodos y los errores de dmesg antes de un despliegue masivo.
• Monitorización: centralice patrones de Journald/Dmesg para „module verification failed“ y configure alertas con SLOs.

Ruta de emergencia: defina procedimientos Break‑Glass claros y probados (Fallback‑Kernel, plan de consola remota, desactivación temporal de Secure Boot solo como última opción) y documente responsabilidades. Así vincula los requisitos de seguridad con un modelo operativo robusto para entornos empresariales y de clúster individuales.

Para este tema también son importantes la firma de módulos del kernel y el Machine Owner Key (Mok). El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que centrarse en la práctica.