Cadena de confianza del modelo (4/4): quién sirve el modelo y en qué máquina confías

Sun, 26 Jul 2026 17:00:00 +0200

Los tres artículos anteriores han cerrado preguntas sobre el artefacto: qué contrato expone el modelo servido, de dónde salen sus bytes y por qué te fías de ellos. Queda la que casi nadie se hace hasta que la formula un auditor: el proceso que ahora mismo devuelve tokens por el puerto 8000, ¿es de verdad el motor de inferencia, o es algo que se ha colado en el clúster y ha heredado su token? Y una segunda, peor: la máquina en la que corre, ¿es de fiar, y frente a quién?

Son problemas distintos con proyectos distintos. La identidad de carga la resuelve SPIFFE/SPIRE, graduado en la CNCF desde 2022. El aislamiento del entorno lo recorren Kata Containers y Confidential Containers, promovido este último a incubating de la CNCF el 22 de julio de 2026, cuatro días antes de publicarse este artículo. Lo primero es barato y casi siempre rentable; lo segundo es caro —más de lo que sugiere la nota de prensa del fabricante— y solo se justifica ante un modelo de amenaza concreto.

TL;DR

Identidad de usuario ≠ identidad de carga. OIDC dice qué persona hay detrás de una petición; no dice qué proceso la atiende. Tokens de ServiceAccount, claves estáticas y API keys del gateway son credenciales portador: quien las tiene, las es.
SPIFFE define un identificador URI (spiffe://dominio/ruta) y un documento verificable (SVID, X.509 o JWT) entregado por una Workload API que no exige que la carga posea secreto previo alguno. SPIRE lo implementa con atestación de nodo y de carga; defaults: default_x509_svid_ttl 1 h, default_jwt_svid_ttl 5 min, ca_ttl 24 h.
La identidad solo vale si algo la aplica: Istio/Envoy vía SDS, Cilium con autenticación mutua (con reservas serias) o un ext_authz con OPA delante del gateway.
Tres peldaños de aislamiento: contenedor con kernel compartido → Kata Containers (kernel y VM propios; v3.32.0 de junio de 2026) → Confidential Containers (TEE de hardware, hipervisor fuera de la base de confianza, atestación remota con Trustee según RFC 9334).
El sobrecoste del modo confidencial va del ~0 % al ~28 % según qué se mida: solo GPU en CC con lotes grandes ronda el 4-8 %, mientras que el stack completo (CVM con Intel TDX más H100 en CC), medido de forma independiente en 2026, da +21,8 % a +27,8 % de TTFT y −17,7 % a −21,1 % de throughput. Heurística honesta: reservar un 15-25 % de capacidad extra.
MIG y vGPU están prohibidos en modo CC según la arquitectura de referencia de NVIDIA, y todas las GPU de un nodo van en el mismo modo.
Criterio de cierre: el orden es contrato → digest → firma verificada en admisión → identidad de carga → TEE.

La analogía: el laboratorio de bioseguridad

Un laboratorio que manipula patógenos resuelve dos problemas parecidos a los nuestros, por separado.

El primero es quién entra. No basta la tarjeta de la empresa: en la esclusa hay una acreditación específica, de vigencia corta y renovación automática —si se pierde, caduca sola en una hora—, y no se entrega a quien la pida, sino tras comprobar de forma independiente que el solicitante está donde dice y es quien dice. Esa acreditación es el SVID; la comprobación previa, la atestación.

El segundo es en qué sala se trabaja, y aquí hay niveles de contención. En la poyata abierta el aire es común y lo que se aerosoliza afecta a todos: el contenedor normal, con un kernel compartido por todos los vecinos. Un peldaño arriba, la cabina de seguridad biológica, con barrera física y flujo de aire propio: Kata Containers. Arriba del todo, el laboratorio de máxima contención, donde el personal de mantenimiento cambia filtros sin ver jamás la muestra: el TEE, donde el operador mantiene la máquina pero no puede leer la memoria. Y antes de abrir la esclusa alguien verifica que la integridad del traje y de la sala es la esperada: la atestación remota con liberación condicionada de secretos.

La lección incómoda: el nivel máximo de contención no es “más seguridad”, es una decisión de coste. Nadie monta un BSL-4 para cultivar levadura. La pregunta no es cuánto aísla, sino de quién.

Parte A — Identidad de carga

El problema: seis servicios que se hablan y ninguno sabe quién es el otro

En un clúster de inferencia serio, como el de siete capas, el gateway habla con el motor de serving, el motor consulta la base vectorial, el recolector de trazas recibe spans de todos y los agentes con MCP invocan herramientas que a su vez llaman al gateway. Muchas conexiones este-oeste y, en la mayoría de despliegues, ninguna autenticada de verdad.

La identidad de usuario dice qué persona hay detrás de la petición y se resuelve con OIDC, como al poner Keycloak delante de MCP. La identidad de carga dice qué proceso la emite: no hay humano al otro lado, ni navegador, ni consentimiento, y el proceso nace y muere en segundos. Sus tres sustitutos habituales fallan por razones distintas:

Mecanismo	Dónde falla
Token de `ServiceAccount` proyectado	Granularidad de SA, no de carga: dos pods con el mismo SA son indistinguibles. No cruza el borde del clúster ni federa. Es un bearer token en el sistema de ficheros
Clave estática	No rota, se comparte por Slack, no distingue emisor de portador; filtrada, vale hasta que alguien lo note
API key del gateway	Autentica al cliente, no al proceso. Las claves virtuales de LiteLLM sirven para cuota y presupuesto, no para probar identidad

No hay vínculo criptográfico entre credencial y proceso: copiada la credencial, copiada la identidad. En un clúster multi-tenant como el del clúster H100, el aislamiento real depende entonces de la topología de red y no de la identidad.

SPIFFE: el estándar

SPIFFE y su implementación SPIRE graduaron juntos en la CNCF el 20 de septiembre de 2022. A julio de 2026 son infraestructura asentada, no una apuesta.

El SPIFFE ID es una URI de la forma spiffe://<trust-domain>/<workload-identifier>, por ejemplo spiffe://inferencia.example/ns/inferencia/sa/vllm: un nombre, no una credencial. El trust domain es la raíz de confianza —organización, entorno o sede—, y la guía recomienda separar en dominios distintos las cargas de emplazamientos o entornos de seguridad diferentes.

El SVID es la credencial que prueba ese ID. El X509-SVID lleva el SPIFFE ID en el SAN de tipo URI —no en el CN, que la especificación desaconseja como fuente de identidad— y es el formato preferente. El JWT-SVID existe para cuando hay proxies L7 que terminan TLS en medio, con el riesgo de repetición que la documentación advierte:

Certificate:
Issuer: C=ES, O=SPIFFE
Validity
Not Before: Jul 26 08:00:00 2026 GMT
Not After : Jul 26 09:00:00 2026 GMT
Subject: C=ES, O=SPIRE, CN=vllm.inferencia
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Alternative Name:
URI:spiffe://inferencia.example/ns/inferencia/sa/vllm

Una hora de validez, y lo que autentica es el SAN URI: el CN es decorativo.

La Workload API es la pieza elegante: un socket UNIX local del que la carga obtiene su SVID, su clave privada y el paquete de confianza, sin presentar ningún secreto. La documentación es explícita: “la Workload API no exige que la carga que la invoca tenga ningún conocimiento de su propia identidad ni posea ningún token de autenticación”. Eso resuelve el arranque en frío de toda la criptografía de identidad: el secreto que necesitarías para obtener el primer secreto.

SPIRE: cómo se emite ese documento

SPIRE tiene un servidor (la autoridad que firma) y un agente por nodo (que expone la Workload API), y encadena dos comprobaciones.

La atestación de nodo verifica que el agente corre donde dice. En Kubernetes el atestador de referencia es k8s_psat, que valida contra el API server un token proyectado con audiencia; en bare metal hay atestadores basados en TPM. Nota de honestidad: SPIRE v1.15.1, del 28 de mayo de 2026, es un parche de seguridad sobre una validación incorrecta de PKCS7 en el atestador azure_imds que permitía falsificar documentos atestados y suplantar una máquina virtual.

La atestación de carga responde a nuestra pregunta inicial. El atestador k8s recibe el PID del proceso que abre el socket, deduce el pod por su pertenencia a cgroups y consulta al kubelet los metadatos. De ahí salen los selectores: namespace, service account, nombre y UID de pod, etiquetas, propietario, nodo y —crítico— contenedor e imagen por tag o por digest. Desde SPIRE v1.15.0 (19 de mayo de 2026) el soporte de Sigstore dejó de ser experimental, habilitando selectores por estado de verificación de firma, sujeto y emisor del certificado y registro de transparencia. Eso cierra el círculo de la serie: se puede exigir que solo el contenedor cuya imagen tiene firma cosign válida del emisor esperado —lo verificado en el artículo 3/4— reciba el SVID del motor. La procedencia pasa de comprobación de admisión única a precondición de la identidad en ejecución.

spire-server entry create \
 -parentID spiffe://inferencia.example/spire/agent/k8s_psat/prod/nodo-gpu-a \
 -spiffeID spiffe://inferencia.example/ns/inferencia/sa/vllm \
 -selector k8s:ns:inferencia \
 -selector k8s:sa:vllm \
 -selector k8s:container-name:vllm \
 -selector k8s:container-image:vllm/vllm-openai@sha256:aa11bb22cc33 \
 -x509SVIDTTL 3600 \
 -federatesWith spiffe://sede-b.example

Los selectores son conjuntivos: un pod en otro namespace, con otro SA o con otra imagen no obtiene ese SVID aunque comparta nodo.

Los TTL por defecto tienen tres consecuencias. La rotación es continua, no un evento: el código que carga el certificado una vez al arrancar se romperá exactamente una hora después. La caída del servidor tiene reloj: veinte minutos son invisibles, dos horas tumban las comunicaciones autenticadas del clúster, y la guía de escalado admite que “una única instancia de servidor SPIRE representa un punto único de fallo”, con el almacén de datos como cuello de botella y cifras orientativas que van de dos réplicas de 1 CPU y 1 GB para 10 agentes a ocho de 16 CPU y 16 GB para 5000 agentes y 10 000 cargas. Y los selectores por tag son frágiles: el runtime puede reportar un tag u otro según el nodo y el momento, así que usar digest, como en el artículo 2/4.

Federación entre trust domains

Dos sedes con clústeres independientes, o un socio externo que expone un reranker, no deben compartir autoridad. La federación SPIFFE hace que cada dominio publique un bundle endpoint con su material público de confianza y que el otro lo consulte periódicamente: el perfil https_web lo autentica con PKI web y https_spiffe con un X509-SVID del propio dominio, habilitando rotación y revocación automáticas de la raíz. La relación es unidireccional, los paquetes de dominios distintos no deben fusionarse nunca y el refresco es por sondeo con sugerencia por defecto de cinco minutos. En la práctica: el gateway de la sede A acepta peticiones del motor de la sede B sin compartir CA ni base de identidades, y cortar la relación es borrar un paquete, no revocar certificados.

De identidad a autorización efectiva

Un SVID no bloquea nada por sí solo; alguien tiene que comparar el ID presentado contra una política.

Istio + SPIRE es la integración más rodada: Istio detecta un socket UNIX que implementa la API SDS de Envoy y el proxy obtiene de ahí sus identidades en lugar de de istiod, montado con el SPIFFE CSI Driver (recomendado sobre hostMount). Dos condiciones rompen despliegues: el trust domain de SPIRE y el de Istio deben coincidir exactamente, y SPIRE solo emite a cargas registradas previamente, incluidos los componentes de Istio. Con eso, la política se escribe en identidad y no en IP:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: vllm-solo-desde-gateway
 namespace: inferencia
spec:
 selector:
 matchLabels:
 app: vllm
 action: ALLOW
 rules:
 - from:
 - source:
 principals: ["inferencia.example/ns/inferencia/sa/gateway"]
 to:
 - operation:
 methods: ["POST"]
 paths: ["/v1/chat/completions", "/v1/completions"]

Es una capa sobre la NetworkPolicy de hardening por capas: allí cerrábamos pares de comunicación por topología; aquí exigimos además quién llama y a qué ruta.

Cilium ofrece autenticación mutua apoyada en SPIRE, tentadora si ya se usa eBPF para la red de datos. Toca ser crítico: sigue marcada como beta en la documentación estable, y The New Stack publicó una crítica argumentada de que el diseño no preserva las propiedades de mTLS durante la vida de la conexión —usa el handshake solo para autenticar y descarta las claves de sesión— y de que el modelo de identidad se apoya en cachés IP-identidad eventualmente consistentes por nodo, lo que puede permitir tráfico que la política debería denegar.

El gateway de inferencia y LiteLLM no hablan SPIFFE de forma nativa a fecha de este artículo, y conviene decirlo en lugar de sugerir una integración inexistente. El patrón que sí funciona es el que documenta el propio proyecto: un Envoy delante que termina mTLS con X509-SVID o valida un JWT-SVID y delega en OPA vía ext_authz. El gateway sigue con lo suyo —cuota, presupuesto, enrutado, como vimos al elegir gateway OSS y en el router L7— y la identidad de carga se resuelve un salto antes.

Agentes de IA y MCP: la pieza que faltaba

Un agente que invoca herramientas por MCP es un secreto compartido con patas: se le entrega una credencial estática, el servidor MCP no puede saber si quien llama es el agente legítimo o cualquier proceso con la misma cadena, y el radio de impacto es el conjunto entero de herramientas expuestas. El modelo de amenaza del aislamiento de agentes advertía de que un permiso concedido es un permiso usable; con credenciales portador es además transferible.

SPIFFE aporta lo que falta: el agente presenta un SVID de vida corta obtenido por atestación y el servidor MCP autoriza contra el SPIFFE ID. En 2026 ha dejado de ser teoría —hay trabajo en el IETF sobre registro dinámico de cliente OAuth basado en emisores de confianza SPIFFE, y Google publicó en junio de 2026 una Agent Identity basada en SPIFFE en su IAM—, aunque nada está estandarizado del todo.

Dos honestidades. SPIFFE responde “quién”, no “por qué”: para saber si la acción es la que el usuario pidió hacen falta trazabilidad (MCP con OTel) y detección en ejecución con Tetragon. Y ambas identidades deben componerse: el agente prueba la suya con un SVID y propaga la del usuario delegante en el token, autorizando sobre el par. Colapsarlas en una es cómo se acaba con agentes capaces de hacer, en nombre del sistema, cosas que ningún usuario podría.

Parte B — Aislamiento del entorno de ejecución

### Kata Containers: el sandbox de máquina virtual

Kata sustituye runc por un runtime que arranca una máquina virtual ligera por pod, con kernel propio y un kata-agent dentro; para Kubernetes es transparente vía RuntimeClass. A julio de 2026 la rama estable es la 3.32.x —la 3.32.0 es de junio de 2026, con Rust 1.94, Go 1.25.11, QEMU 11.0.1, kernel invitado 6.18.35 y containerd 2.3—, y en abril de 2026 se publicó el preview de la 4.0.0, que convierte el runtime en Rust (runtime-rs) en el predeterminado y deja el de Go en depreciación hasta la 5.0.0, por huella de memoria.

Para GPU el camino es passthrough VFIO. El NVIDIA GPU Operator lo automatiza con sandboxWorkloads.enabled=true y sandboxWorkloads.mode=kata, instalando el VFIO Manager, el Sandbox Device Plugin, el Confidential Computing Manager y el Kata Manager. Requiere virtualización y ACS en BIOS, IOMMU, kata-deploy 3.29.0 o superior, containerd (no CRI-O), el feature gate KubeletPodResourcesGet —por defecto desde Kubernetes 1.34— y quitar los drivers NVIDIA del host: la GPU se cede entera a la VM y la maneja el invitado.

apiVersion: v1
kind: Pod
metadata:
 name: vllm-kata
 namespace: inferencia
spec:
 runtimeClassName: kata-qemu-nvidia-gpu
 containers:
 - name: vllm
 image: vllm/vllm-openai@sha256:aa11bb22cc33
 resources:
 limits:
 nvidia.com/pgpu: "1"

Dos costes medibles. El de memoria: la VM reserva la suya y hay que declararla como overhead en la RuntimeClass para que el planificador no sobrecomprometa el nodo. Y el de arranque: según el estudio de contenedores confidenciales serverless de SESAME'24, el arranque en frío pasa de unos 6 s con runc a unos 7 s con Kata, y el caliente de 1 s a 2 s. Aceptable para un motor que tarda minutos en cargar pesos; inaceptable para funciones efímeras.

Confidential Containers: el TEE

Confidential Containers (CoCo) saca al hipervisor y al operador de la plataforma de la base de confianza. La CNCF lo promovió a incubating el 22 de julio de 2026, con más de 150 contribuidores activos, 26 repositorios y más de 1200 pull requests fusionadas, y con Microsoft Azure, Intel, AMD, IBM, NVIDIA, Alibaba y Red Hat detrás. Proyecto serio, pero incubating significa que no está graduado y que su superficie de integración cambia entre versiones.

Los componentes son los pods CoCo (contenedores sin modificar ejecutados en un TEE mediante Kata) y Trustee: KBS (Key Broker Service, que libera secretos condicionadamente), AS (Attestation Service, que valida la evidencia de hardware) y RVPS (Reference Value Provider Service, que custodia los valores de referencia). Dentro del invitado, el Attestation Agent recoge la evidencia y el Confidential Data Hub consume los secretos.

El flujo es una instancia limpia de la arquitectura RATS del RFC 9334: el agente dentro del TEE es el attester, el Attestation Service el verifier y el Confidential Data Hub el relying party. La evidencia es un informe firmado por hardware con las medidas del arranque; el AS lo valida contra los valores del RVPS; y solo si cuadra, el KBS libera la clave que descifra las capas de imagen o los pesos. Sin atestación válida no hay clave, y sin clave no hay modelo. Eso es lo que impide que el operador extraiga el modelo.

Aviso de cartografía: el repositorio confidential-containers/operator fue archivado en febrero de 2026 y el despliegue se movió a los charts de Helm y al trustee-operator. A julio de 2026 la última publicación de charts es la v0.21.0, alineada con kata-deploy 3.31.0, y Trustee v0.20.0, con TLS 1.3 y criptografía post-cuántica, complementos externos para el KBS y soporte multi-GPU vía Intel Trust Authority y NVIDIA NVSwitch.

apiVersion: confidentialcontainers.org/v1alpha1
kind: TrusteeConfig
metadata:
 name: trusteeconfig
 namespace: operators
spec:
 profileType: Restrictive
 httpsSpec:
 tlsSecretName: trustee-tls-cert

El perfil Permissive existe para desarrollo y no debe salir de ahí: es el modo en el que la atestación no bloquea.

El hardware: CPU y GPU

Del lado de CPU los dos TEE relevantes son AMD SEV-SNP e Intel TDX; la arquitectura de referencia de NVIDIA fija como base EPYC Milan/Genoa y Xeon Emerald/Granite Rapids. El soporte de host ya no es la parte difícil.

Del lado de GPU, la descripción técnica del diseño de las primeras GPU confidenciales explica qué se compra con el modo CC de una H100. La memoria se parte en una Compute Protected Region a la que cortafuegos de hardware impiden acceder tanto a la CPU por PCIe como a otras GPU por NVLink. Todo lo que cruza la frontera CPU-GPU pasa por bounce buffers cifrados con AES-GCM-256, y los búferes de comandos y los kernels CUDA se cifran y firman antes de cruzar el bus. Hay cadena de confianza desde el arranque de la GPU con informe de atestación firmado, y solo firmware firmado por NVIDIA se ejecuta en modo CC, validado contra NRAS o localmente en entornos aislados. Y los contadores de rendimiento quedan deshabilitados por hardware como mitigación de canales laterales: es la telemetría de la que depende buena parte de la observabilidad con DCGM.

Qué no protege: la memoria HBM del paquete no está cifrada —se considera resistente a interposadores, lo que es una afirmación sobre dificultad física y no una garantía criptográfica—; nada frente a denegación de servicio, porque el operador que no puede leerte sí puede apagarte; nada frente a canales laterales de tiempo o de patrón de acceso; y nada frente a un bug en tu propio código dentro del enclave o la inyección de prompt, que sigue siendo trabajo de guardrails.

En Blackwell, NVIDIA anuncia (2 de julio de 2026) cifrado de NVLink que extiende la computación confidencial a hasta 8 GPU, inexistente en Hopper y que marca la diferencia entre poder servir un modelo grande con paralelismo de tensor o no. La arquitectura de referencia lista H100, H200, RTX Pro 6000 Blackwell Server Edition y B200 en passthrough de una GPU, y H100/H200 en modo PPCIe y B200 para multi-GPU.

Los números del sobrecoste, con fuente y con criterio

Aquí conviene desconfiar de todo el mundo, papers incluidos. La dispersión publicada va del 0 % al 28 %, y no es contradicción: es que no miden lo mismo.

Fuente (fecha)	Qué mide	Resultado	Naturaleza
NVIDIA, blog Blackwell (jul. 2026)	B200 con CC activado	−1,0 % a −7,5 % de throughput; latencia por token bajo el 8 %; “hasta el 98 % del rendimiento nativo”	Claim de fabricante
Corvex, HGX B200 con TDX (2026)	Despliegue “verificado”, NVSwitch cifrado	“Rendimiento casi nativo”, sin cifras propias	Claim comercial
arXiv 2409.03992 (2024)	Solo GPU H100 en CC, Llama-3.1 8B/70B	−0,36 % a 6,85 % de throughput; TTFT hasta +19 %; overhead → 0 al crecer el modelo	Independiente, parcial
arXiv 2509.18886 (sep. 2025)	TEE de CPU (TDX/SGX) y de GPU (H100), Llama2 7B/13B/70B	CPU TEE: bajo 10 % de throughput y 20 % de latencia. GPU TEE: 4-8 %	Independiente
arXiv 2607.19353 (may. 2026)	Stack completo: H100 en CC dentro de CVM con TDX, Mistral-7B y Qwen3-30B-A3B bajo carga	TTFT +21,8 % y +27,8 %; throughput −17,7 % y −21,1 %; en lazo cerrado, 11,5-20,2 %	Independiente, completo

La reconciliación: la penalización no está en el cómputo de la GPU, está en el camino de datos. La propia NVIDIA cuantifica el cuello: el ancho de banda efectivo del interconexionado CPU-GPU en modo CC queda limitado por el rendimiento de cifrado de la CPU, “en torno a 4 GB/s”. De ahí, tres reglas: cuanto mayor la relación cómputo/E-S, menor el sobrecoste —un 70B con lotes grandes y secuencias largas amortiza el peaje casi por completo, un 7B con lotes pequeños y prompts cortos lo paga entero—; añadir el TEE de CPU suma su propio coste, y ahí está la mayor parte de la diferencia entre el 4-8 % y el 20 %; y la carga del modelo y el arranque en frío son los peores casos, con decenas de gigabytes cruzando un bus cifrado a 4 GB/s, lo que vuelve más importante todo lo discutido en del disco a la HBM y en acelerar el cold start.

La recomendación de los autores del estudio de 2026 —reservar entre un 15 % y un 25 % de capacidad adicional— es la cifra que llevaría yo a un ejercicio de capacity planning, y no el “98 % del rendimiento nativo” del fabricante. Ambas pueden ser ciertas a la vez; solo una es prudente para dimensionar.

Cuándo merece la pena de verdad

Escenario	Kata	CoCo (TEE)	Razón
Tenants que no confían entre sí	Sí	Depende	Kata elimina el kernel compartido, vector real de escape
Código o modelos de terceros no auditados	Sí	Opcional	Un kernel compartido es demasiada superficie para código ajeno
Propiedad intelectual del modelo frente al operador de la infraestructura	No basta	Sí	Caso canónico: hospedaje ajeno, nube, socio que aporta el hierro
Datos regulados de terceros en infraestructura que no controlas	No basta	Sí	Ver defensa y sanidad
On-premise soberano, un tenant, operador de confianza	Útil	Sobre-ingeniería cara	Protege de un adversario que no tienes
Baja latencia con lotes pequeños	Sí	Mala idea	Peor punto de la curva coste/beneficio del cifrado del bus

El matiz que más dinero ahorra: los dos ejes son independientes. Kata sin TEE es barato y aporta la mayor parte del aislamiento entre tenants; CoCo solo aporta algo si tu modelo de amenaza incluye al operador. Si montas una factoría soberana con tu hierro y tu personal y respondes “no” a esa pregunta, el TEE es un coste sin contrapartida.

Trampas operativas

MIG y vGPU frente al modo confidencial. La arquitectura de referencia GA 1.0.0 de NVIDIA es tajante: MIG y vGPU están prohibidos en modo CC y los nodos en modo mixto no están soportados —todas las GPU de un host van en CC o ninguna—. Los foros muestran la contradicción típica de un área en movimiento: en febrero de 2026 un moderador afirma que MIG+CC no está soportado y en abril un usuario cita la página de MIG sugiriendo que Hopper y Blackwell ya lo permiten. A fecha de este artículo la arquitectura de referencia manda sobre la página de producto: si tu multi-tenancy se apoyaba en particionar la GPU con MIG, activar CC te devuelve a “una GPU entera por tenant”.

El arranque se alarga de forma no lineal. SESAME'24 desglosa dónde: la provisión de memoria SEV añade en torno a un segundo por cada 2 GB de invitado —SEV fija todas las páginas por adelantado, y una VM de inferencia asigna mucha—, el firmware OVMF unos tres segundos y el descifrado de capas otros tres a cinco. Escalar de 0 a 16 instancias pasa de 16 s con runc a 190 s: irrelevante para un Deployment estable, cambio de diseño para autoescalado agresivo con KEDA.

El acoplamiento de versiones es brutal. Kata, kata-deploy, GPU Operator, containerd, QEMU con parches propios, kernel del invitado, driver NVIDIA y Trustee son una matriz que hay que tratar como unidad: la arquitectura de referencia fija Kubernetes 1.32 o superior, Kata 3.29, GPU Operator 26.3.1 o superior, containerd 2.2.2 o superior y QEMU 10.1. Súmalo al peso que ya arrastran los operators del stack.

La atestación falla tras actualizar firmware, y es lo normal. Los valores de referencia del RVPS describen un estado de arranque concreto. Al parchear el firmware SEV-SNP, el microcódigo o el firmware de la GPU, la versión de TCB cambia, la evidencia deja de cuadrar y el KBS no libera claves, así que los pods no arrancan. Como estas actualizaciones suelen responder a un boletín de seguridad, el escenario típico es “aplicamos el parche crítico un viernes y el sábado no arranca la inferencia”. El procedimiento correcto invierte el orden: actualizar primero los valores de referencia con ventana de solapamiento, y después parchear el hierro.

El servicio de atestación es un punto único de fallo por diseño. Si el KBS no responde, ningún pod confidencial nuevo obtiene su clave; los arrancados sobreviven, pero cualquier reprogramación o escalado, no. Misma dependencia que el servidor SPIRE y mismo tratamiento: alta disponibilidad real, alerta propia y degradación ensayada.

Cierre de serie: la cadena completa

El artículo 1/4 fijó el contrato: qué expone el endpoint y qué plano de control lo gobierna de forma reproducible. El 2/4 fijó la procedencia de los bytes: de qué registro salen, por digest inmutable y no por un tag móvil. El 3/4 fijó la prueba criptográfica de qué son: firma, atestaciones de construcción y AIBOM, verificadas en admisión. Y este 4/4 fija quién los ejecuta y dónde: un SVID que prueba la identidad del proceso servidor y un peldaño de aislamiento elegido para el adversario que de verdad tienes. Rota cualquiera de las cuatro, las otras tres valen menos de lo que parece: un modelo firmado impecablemente que sirve un proceso no identificado en una máquina que un tercero puede volcar sigue siendo un problema.

Con presupuesto limitado, el orden responde a coste por unidad de riesgo eliminado. Primero, digest en todas partes: casi gratis, elimina una familia entera de ataques de sustitución. Segundo, firma verificada en admisión: coste bajo y es lo primero que un auditor pide ver. Tercero, contrato y plano de control declarativos, que hacen auditable lo demás. Cuarto, identidad de carga con SPIFFE/SPIRE: caro en operación, pero es lo único que convierte el tráfico este-oeste en algo autorizable, e imprescindible en cuanto entran agentes con MCP. Y último, el TEE, solo si el operador de la infraestructura está en tu modelo de amenaza; Kata sin TEE puede adelantarse al cuarto puesto si hay tenants que no confían entre sí.

Mapeo de la serie a ENS, ISO/IEC 42001 y EU AI Act

El detalle está en controles técnicos ENS × ISO 42001 × EU AI Act; esta tabla es el resumen por eslabón.

Eslabón	Medida ENS (RD 311/2022)	ISO/IEC 42001 (Anexo A)	EU AI Act
1/4 Contrato y plano de control	`op.exp.2`; `op.mon.1`	A.6 ciclo de vida	Art. 12 (registro); Art. 13 (transparencia)
2/4 Registro y distribución por digest	`op.ext.3`	A.10 terceros	Art. 11 y Anexo IV (documentación técnica)
3/4 Firma, atestaciones y AIBOM	`op.exp.6`; `op.ext.3`	A.6.2 y A.7 datos y trazabilidad	Art. 15(5), envenenamiento de datos y de modelo
4/4-A Identidad de carga	`op.acc.1/2/5`; `op.exp.11`; `mp.com.2-3`	A.9 uso del sistema de IA	Art. 15(5), terceros no autorizados
4/4-B Aislamiento y TEE	`mp.info.3`; `op.exp.2`; `mp.com.4`	A.6 controles del ciclo de vida	Art. 15(4) robustez; Art. 15(5)

El Art. 15(5) es el que más carga soporta: exige que los sistemas de alto riesgo sean “resilientes frente a intentos de terceros no autorizados de alterar su uso, salidas o rendimiento”, y enumera el envenenamiento de datos y de modelo y los ataques a la confidencialidad. Los eslabones 3 y 4 son su implementación técnica. Para el marco de gestión, ver ISO/IEC 42001 como AIMS y el mapeo del AI Act.

Para una factoría de inferencia

Empieza la identidad de carga por el par gateway↔motor y por los agentes, no por todo el clúster. Registrar las cuarenta cargas el primer día es la forma más fiable de abandonar el proyecto: registra dos entradas, monta la política de Istio que exige el principal del gateway y vive con ella un par de semanas para aprender qué se rompe al rotar el certificado. Después, los agentes con MCP, donde las credenciales estáticas son el modelo de amenaza entero.

Separa la decisión de Kata de la de TEE, y tómalas en ese orden. Kata es un cambio de RuntimeClass con un segundo de arranque y algo de memoria. CoCo es un rediseño: pierdes MIG y los contadores de rendimiento de la GPU, ganas diez segundos o más de arranque, pagas un 15-25 % de capacidad y añades dos dependencias cuya caída impide arrancar cargas. Evalúa lo segundo con un modelo de amenaza escrito, no con una diapositiva.

Si vas a CoCo, ensaya el día del parche antes de necesitarlo. El fallo que tumbará tu inferencia no será un ataque, será una actualización de firmware que desalinea los valores de referencia del RVPS. Escribe el runbook —actualizar RVPS con solapamiento, parchear, retirar el valor antiguo—, ensáyalo en un nodo y monitoriza la tasa de éxito de atestación como métrica de primera clase, igual que para SPIRE: alerta sobre fallos de atestación antes de que se conviertan en 401 en el gateway.

Con esto se cierra la serie: del contrato al artefacto, del artefacto a su prueba, y de la prueba al proceso y a la máquina. Lo que queda por debajo ya no es cadena de confianza sino explotación diaria: ver qué hace cada proceso con Tetragon y medir si lo servido sigue siendo bueno con evals. La confianza se establece una vez; la vigilancia es continua.

Ver también

Cadena de confianza del modelo (1/4): KServe y el Open Inference Protocol — el contrato de API que abre la serie.
Cadena de confianza del modelo (2/4): registro y distribución con OCI y ORAS — por qué el digest lo es todo.
Cadena de confianza del modelo (3/4): firma, procedencia y AIBOM — la prueba que los selectores Sigstore vuelven precondición de identidad.
MCP crece: autenticación con Keycloak — la identidad de usuario con la que componer la de carga.
Aislar agentes de IA: del workstation al clúster — el modelo de amenaza al que SPIFFE pone credencial no transferible.
Tetragon: seguridad en runtime — la vigilancia que empieza donde acaba la cadena de confianza.
Infraestructura y cumplimiento normativo en defensa — donde el TEE deja de ser sobre-ingeniería.
Clúster H100: plataforma multi-tenant — donde MIG y modo confidencial chocan de frente.

Fuentes

CNCF, SPIFFE and SPIRE Projects Graduate from CNCF Incubator (20 sep. 2022) — https://www.cncf.io/announcements/2022/09/20/spiffe-and-spire-projects-graduate-from-cloud-native-computing-foundation-incubator/
SPIFFE, SPIFFE Concepts (SPIFFE ID, trust domain, SVID, Workload API) — https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/
SPIFFE, SPIFFE Federation specification — https://spiffe.io/docs/latest/spiffe-specs/spiffe_federation/
SPIFFE, Scaling SPIRE (dimensionamiento y punto único de fallo) — https://spiffe.io/docs/latest/planning/scaling_spire/
spiffe/spire, Releases (v1.15.0 de 19 may. 2026; v1.15.1 de 28 may. 2026, parche de azure_imds) — https://github.com/spiffe/spire/releases
spiffe/spire, Kubernetes Workload Attestor plugin (selectores, kubelet, cgroups, Sigstore) — https://github.com/spiffe/spire/blob/main/doc/plugin_agent_workloadattestor_k8s.md
spiffe/spire, SPIRE Server configuration reference (default_x509_svid_ttl, default_jwt_svid_ttl, ca_ttl) — https://github.com/spiffe/spire/blob/main/doc/spire_server.md
Istio, SPIRE integration (Envoy SDS, SPIFFE CSI Driver, trust domain) — https://istio.io/latest/docs/ops/integrations/spire/
SPIFFE, OPA Authorization with Envoy and JWT-SVIDs — https://spiffe.io/docs/latest/microservices/envoy-jwt-opa/readme/
The New Stack, How Cilium’s Mutual Authentication Can Compromise Security — https://thenewstack.io/how-ciliums-mutual-authentication-can-compromise-security/
Riptides, Bringing SPIFFE to OAuth for MCP — https://riptides.io/blog/bringing-spiffe-to-oauth-for-mcp-secure-identity-for-agentic-workloads/
CNCF, Confidential Containers becomes a CNCF incubating project (22 jul. 2026) — https://www.cncf.io/blog/2026/07/22/confidential-containers-becomes-a-cncf-incubating-project/
Confidential Containers, Attestation with Trustee (KBS, AS, RVPS, CDH) — https://confidentialcontainers.org/docs/attestation/
Confidential Containers, Deploy Trustee in Kubernetes (11 feb. 2026) — https://confidentialcontainers.org/blog/2026/02/11/deploy-trustee-in-kubernetes/
confidential-containers/trustee, Releases (v0.20.0: TLS 1.3, PQC, multi-GPU ITA, NVSwitch) — https://github.com/confidential-containers/trustee/releases
IETF, RFC 9334 — Remote ATtestation procedureS (RATS) Architecture — https://www.rfc-editor.org/info/rfc9334/
Kata Containers, Kata Containers 4.0.0 Preview (28 abr. 2026, runtime-rs por defecto) — https://katacontainers.io/blog/release-4-0-0-preview/
kata-containers, Release 3.32.0 — https://github.com/kata-containers/kata-containers/releases/tag/3.32.0
NVIDIA, Deploy with Kata Containers — GPU Operator — https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/deploy-kata-containers.html
NVIDIA, Deploying Proprietary Models Securely with Confidential Computing on Self-Hosted Kubernetes (GA 1.0.0; MIG y vGPU prohibidos en CC) — https://docs.nvidia.com/enterprise-reference-architectures/deploying-proprietary-models-confidential-compute-self-hosted-kubernetes/latest/reference-implementations.html
CACM, Creating the First Confidential GPUs (CPR, bounce buffers, contadores deshabilitados, HBM no cifrada) — https://cacm.acm.org/practice/creating-the-first-confidential-gpus/
NVIDIA, Confidential Computing on H100 GPUs for Secure and Trustworthy AI (límite de ~4 GB/s, NRAS) — https://developer.nvidia.com/blog/confidential-computing-on-h100-gpus-for-secure-and-trustworthy-ai/
NVIDIA, Hardware-Rooted AI Security That Won’t Slow You Down (2 jul. 2026; Blackwell, NVLink cifrado hasta 8 GPU) — https://developer.nvidia.com/blog/hardware-rooted-ai-security-that-wont-slow-you-down
Corvex, Confidential Computing Meets NVIDIA HGX B200 (claim comercial) — https://www.corvex.ai/blog/confidential-computing-meets-nvidia-hgxtm-b200-secure-ai-without-the-performance-trade-off
arXiv 2409.03992, Confidential Computing on NVIDIA Hopper GPUs: A Performance Benchmark Study — https://arxiv.org/html/2409.03992v1
arXiv 2509.18886, Confidential LLM Inference: Performance and Cost Across CPU and GPU TEEs (23 sep. 2025) — https://arxiv.org/abs/2509.18886
arXiv 2607.19353, Benchmarking Confidential GPU Inference on NVIDIA H100 under Intel TDX (may. 2026; heurística del 15-25 %) — https://arxiv.org/html/2607.19353
Segarra et al., Serverless Confidential Containers: Challenges and Opportunities (SESAME'24) — https://carlossegarra.com/assets/papers/sesame24-serverlesscoco.pdf
EU Artificial Intelligence Act, Article 15: Accuracy, Robustness and Cybersecurity — https://artificialintelligenceact.eu/article/15/
EU Artificial Intelligence Act, Article 12: Record-Keeping — https://artificialintelligenceact.eu/article/12/

Atestacion on lo0 — Blog Técnico