SPO v1: la primera versión estable ya está acá

Security Profiles Operator llegó a v1. Después de seis años de evolución, el proyecto que arrancó como un operador solo para seccomp en 2020 acaba de graduar sus ocho CRDs a versión estable. La noticia la confirmó Sascha Grunert de Red Hat en el blog de la CNCF el 26 de junio de 2026, y viene con auditoría de seguridad de terceros, cero vulnerabilidades críticas encontradas, y una migración sin tiempo de inactividad desde cualquier versión anterior.

El Security Profiles Operator (SPO) es un operador de Kubernetes que te permite gestionar perfiles de seguridad —seccomp, SELinux y AppArmor— como recursos nativos del clúster, grabar perfiles desde workloads en vivo usando eBPF o audit logs, y asignarlos a pods de forma declarativa. Básicamente, transforma lo que antes era un dolor de cabeza manual y propenso a errores en algo automatizado y auditable. Y con esta v1, el proyecto cierra un ciclo de maduración que los consumidores downstream venían pidiendo hace rato.

¿Qué novedades trae Security Profiles Operator v1.0.0?

La novedad central es que las ocho definiciones de recursos personalizados (CRDs) del operador pasan a v1. Hablamos de SeccompProfile, SelinuxProfile, AppArmorProfile, ProfileRecording, ProfileBinding, y sus variantes Raw y Log. Algunas de estas APIs ya estaban estables en la práctica —SeccompProfile lleva más de cinco años dando vueltas— pero les faltaba la etiqueta formal para que los consumidores downstream pudieran comprometerse a largo plazo.

SPO está disponible en OperatorHub desde 2022 y se distribuye como parte de OpenShift desde la versión 4.12. O sea, el volumen de uso ya era considerable. Lo que faltaba era el sello.

Ahora bien, el salto a v1 no fue solo ceremonial. El equipo metió una auditoría de seguridad completa con un tercero y un ciclo de endurecimiento. El resultado: cero vulnerabilidades críticas y un montón de mejoras defensivas que convierten al operador en una base mucho más sólida para entornos productivos. Si alguna vez tuviste que mantener perfiles SELinux a mano en un clúster grande, sabés que cualquier hardening extra es bienvenido (y necesario).

¿Cómo se hizo la auditoría de seguridad y qué se endureció?

La auditoría la ejecutó un equipo externo —el anuncio de Grunert no da el nombre, pero especifica que fue third-party— y el dato más relevante es que no apareció ni una vulnerabilidad crítica. Eso no significa que no hubiera nada para mejorar, porque el equipo de desarrollo aprovechó el ciclo para aplicar ajustes que, en conjunto, cambian bastante el panorama de seguridad interna del operador.

Los cambios concretos que llegaron con este endurecimiento:

• RawSelinuxProfile ahora tiene un campo enableRawSelinuxProfiles que no estaba antes. Sin esto, el operador directamente no procesa perfiles SELinux raw. Un gate explícito en vez de asumir que todo viene limpio.
• El modo permissive dejó de ser un string suelto y pasó a ser un enum. Menos ambigüedad, menos errores por tipeo.
• Validación de entradas en AppArmorProfile. Si mandás fruta, el operador te rebota antes de aplicarla. Antes podía pasar.
• Límite de 500 KB en el tamaño de la política SELinux raw. Parece un número grande, pero hay políticas de SELinux que se van de mambo. Esto frena cargas maliciosas o simplemente archivos corruptos.
• Prevención de backtracking en los parsers. Ataques ReDoS, básicamente. Si un perfil maligno intenta explotar backtracking catastrófico en el parser, ahora rebota.
• Límites en el grabador eBPF: se limitó la cantidad de archivos emitidos y la longitud de las rutas. Así evitás que un contenedor bombardee al grabador con eventos basura.

¿Alguien esperaba una lista tan larga? Probablemente no. Pero cuando abrís el capó después de seis años, siempre saltan cosas. Lo bueno es que las encontraron antes que un atacante. Complementá con nuestra comparativa de CI/CD 2026.

¿Cómo es la migración a v1 sin tiempo de inactividad?

Acá es donde el equipo de SPO hizo las cosas bien de verdad. La migración no requiere pasos manuales: la conversión automática traduce cualquier manifiesto viejo (v1alpha1, v1alpha2, v1beta1) a v1. Vos subís un YAML con apiVersion v1alpha1 y el clúster lo almacena como v1. Cuando lo leés de vuelta, el operador te lo devuelve en la versión actual del recurso.

La conversión aplica a los valores enum. Si tu perfil tenía mode: “RUNNING” en v1alpha2, el operador lo traduce a mode: Running en v1.

Un ejemplo concreto, tomado del migration guide oficial:

Antes (v1alpha1):

kind: ProfileRecording
spec:
kind: SeccompProfile
recorder: logs
podSelector:
matchLabels:
app: nginx

Después (v1):

kind: ProfileRecording
spec:
kind: SeccompProfile
recorder: Logs
podSelector:
matchLabels:
app: nginx

¿El único cambio? logs pasó a Logs. Y si no lo cambiás, el operador lo hace por vos. El tiempo de inactividad es cero porque los pods con perfiles asignados no se reinician durante la actualización del operador —los perfiles ya están aplicados a nivel de kernel y el cambio de versión de API no los toca.

¿Qué cambios de enumeraciones y API debo conocer?

El cambio más visible es la migración de todos los valores enum a PascalCase. Si estás escribiendo perfiles a mano o generándolos con scripts propios, esto te afecta. Si usás las constantes que expone el proyecto (SCMP_ACT_*, SCMP_CMP_*), no se toca nada —esas se mantienen en mayúsculas para coincidir con la especificación OCI y los encabezados del kernel de Linux. Tema relacionado: la comparativa Jenkins vs GitHub Actions.

Las CRDs que cambian de versión son ocho: SeccompProfile, SelinuxProfile, AppArmorProfile, RawSeccompProfile, RawSelinuxProfile, RawAppArmorProfile, ProfileRecording y ProfileBinding. Si tenés scripts de despliegue, vale la pena revisar los apiVersion, aunque —repito— los webhooks te cubren si no querés tocar nada ahora.

Ojo con un detalle: si generás perfiles programáticamente y usás los strings viejos como literales en código, el cambio a PascalCase te va a romper la comparación. No es grave, pero es de esas cosas que encontrás un viernes a las 18:00.

¿Cómo se integra SPO con la distribución de perfiles por OCI y el upstream de Kubernetes?

SPO ya soporta distribución de perfiles como artefactos OCI, y este caso de uso inspiró el KEP 6061, que propone agregar soporte nativo en kubelet para consumir perfiles de seguridad desde registros OCI. Dicho de otra forma: el operador no solo resolvió el problema práctico, sino que está moldeando cómo Kubernetes va a manejar los perfiles de seguridad en el futuro.

El equipo de SPO dejó claro que el operador no va a desaparecer cuando Kubernetes tenga soporte nativo. Las funcionalidades avanzadas —grabación con eBPF, autoría estructurada de perfiles, enriquecimiento de logs— se mantienen como ventaja diferencial. La v1 sienta las bases para que esa integración futura sea limpia: APIs estables, comportamientos predecibles y una superficie de ataque reducida.

Si estás corriendo cargas en Kubernetes y todavía gestionás perfiles de seguridad a mano, el camino es: grabás con SPO, almacenás en un registro OCI, y cuando el KEP 6061 madure, kubelet va a poder consumirlos sin intermediarios. Mientras tanto, el operador sigue siendo la pieza central de ese flujo.

¿Qué ejemplos prácticos de uso hay en SPO v1?

Ponele que tenés un clúster corriendo en OpenShift 4.12 (o superior) y querés generar perfiles seccomp para un deployment de Nginx sin escribir una syscall a mano. Con SPO v1, creás un ProfileRecording que apunte a los pods etiquetados con app: nginx, lo dejás correr un rato en producción con tráfico real, y el operador genera el perfil por vos usando audit logs o eBPF. Para más detalles técnicos, mirá la guía de hreflang para SEO multiidioma.

El grabador eBPF ahora tiene límites de cantidad de archivos y longitud de rutas. Si el contenedor hace cosas raras —abrir una cantidad excesiva de archivos con rutas muy largas— el grabador corta y te avisa en vez de llenarte el disco con basura. Un detalle chiquito pero que en producción hace la diferencia entre un perfil útil y uno que pesa 3 MB y nadie revisa.

Para equipos que corren infraestructura en Latinoamérica, donde muchas veces hay clústeres on-premise o en proveedores locales como donweb.com, tener perfiles de seguridad bien definidos y distribuibles por OCI significa que podés replicar configuraciones consistentes entre ambientes sin depender de un operador corriendo en cada clúster. El operador graba una vez, el perfil viaja como artefacto OCI, y lo aplicás donde quieras.

Errores comunes al adoptar SPO v1

1. Ignorar el límite de 500 KB en políticas SELinux raw. Hay equipos que cargan políticas SELinux generadas automáticamente que superan ese límite sin darse cuenta. Si tu pipeline inyecta políticas crudas y de repente empieza a fallar después de actualizar, revisá el tamaño. La solución suele ser dividir la política o usar el formato compilado.

2. Hardcodear strings de enum en scripts de monitoreo. Si tenés un script que filtra perfiles por status == “RUNNING”, dejó de funcionar. El webhook no traduce las comparaciones en tu código. Cambialo a “Running” y aprovechá para usar las constantes del SDK en vez de strings mágicos.

3. Asumir que el grabador eBPF captura todo. Con los límites nuevos de cantidad de archivos y longitud de rutas, hay workloads que generan más eventos de los que el grabador retiene. Si tu perfil generado no cubre todas las syscalls que el contenedor necesita, probablemente el grabador cortó antes. Revisá los logs del operador —avisa cuando trunca.

4. No probar la conversión bidireccional antes de migrar. Aunque el webhook funciona en vuelo, vale la pena hacer un dry run: actualizá el operador en staging, consultá tus recursos existentes con distintas versiones de API, y confirmá que todo se traduce como esperás. Especialmente si tenés perfiles con combinaciones raras de modos y acciones.

Preguntas Frecuentes

¿Qué es Security Profiles Operator?

Es un operador de Kubernetes que gestiona perfiles de seguridad seccomp, SELinux y AppArmor como recursos nativos del clúster. Te permite grabar perfiles desde workloads en vivo, distribuirlos como artefactos OCI y asignarlos a pods de forma declarativa. Lo mantiene Red Hat y es parte de la CNCF. Lo explicamos a fondo en la guía de OpenClaw para agentes locales.

¿Cómo migrar a SPO v1 sin tiempo de inactividad?

Actualizás el operador y listo. La conversión automática traduce los manifiestos v1alpha1, v1alpha2 y v1beta1 a v1. Los pods con perfiles asignados no se reinician porque el cambio de versión de API no afecta a los perfiles ya aplicados en el kernel.

¿Qué cambios de API hay en la versión v1 de SPO?

Los valores enum migran a PascalCase. Las constantes SCMP_ACT_* y SCMP_CMP_* no cambian. Las ocho CRDs se gradúan a v1 y se agregan validaciones nuevas como el límite de tamaño en RawSelinuxProfile y el campo enableRawSelinuxProfiles.

¿SPO v1 soporta perfiles SELinux y AppArmor?

Sí. SELinux se sumó a fines de 2020 y AppArmor a fines de 2021. En v1, las CRDs SelinuxProfile, RawSelinuxProfile, AppArmorProfile y RawAppArmorProfile son estables. SELinux raw ahora requiere el flag enableRawSelinuxProfiles explícito y tiene límite de tamaño en la política.

¿Cómo funciona la grabación de perfiles con eBPF en SPO?

Se crea un ProfileRecording apuntando a pods por etiquetas, el operador adjunta un programa eBPF que registra las syscalls que el contenedor ejecuta, y al finalizar genera un perfil seccomp en el formato correcto. En v1, el grabador tiene límites nuevos de cantidad de archivos y longitud de rutas, con advertencias cuando trunca.

Conclusión

SPO v1 no es un lanzamiento con features rimbombantes. Es el tipo de release que importa en entornos donde la estabilidad y la seguridad no se negocian: APIs que dejan de moverse, una auditoría que da tranquilidad, y una migración que no te rompe el finde. Después de seis años de evolución incremental, el operador está listo para que los equipos de plataforma lo adopten sin miedo a deprecaciones sorpresivas.

Si ya usás SPO, la actualización es trivial. Si no lo usás y gestionás perfiles a mano, la v1 es el momento justo para dejar de sufrir con YAMLs artesanales de seccomp y empezar a grabar lo que realmente hace cada contenedor. Las bases están firmes, el upstream de Kubernetes está mirando para el mismo lado, y el operador ya demostró que sabe bancarse producción.

Fuentes

• CNCF Blog: Security Profiles Operator v1 — Stable APIs, Security Hardened, and Shaping Upstream Kubernetes — anuncio oficial por Sascha Grunert (Red Hat), 26 de junio de 2026.
• GitHub — Migration Guide v1 — guía oficial de migración con ejemplos de conversión de API.
• Yolcy: Security Profiles Operator v1 — cobertura de la noticia con contexto adicional.