Asegura una carga de trabajo de Kubernetes antes de enviarla

CVE-2026-19274 fue reportado con una puntuación CVSS de 9.6 después de que un permiso de escritura a nivel de namespace pudiera alcanzar un impacto de RBAC en todo el clúster a través del diseño de nombres de un operador. Security Arsenal informa que no había explotación confirmada al 4 de septiembre de 2026. El fallo estaba en la autoridad alrededor de la carga de trabajo. Su código de aplicación no era el problema.

ZeroPath informa que CVE-2026-10840 implicó que un operador de OpenShift Pipelines otorgara a cada usuario autenticado del clúster acceso de escritura a recursos personalizados de Kueue y cert-manager. El informe afirma que ese acceso podía permitir la interrupción de cargas de trabajo y la sobrescritura de certificados.

Pero ninguno de los dos incidentes necesitó una imagen de aplicación vulnerable para causar problemas. El objeto peligroso era la autoridad: quién podía escribir en qué recurso y cómo un operador traducía un objeto namespaced en permisos para todo el clúster.

Pero la gente sigue tratando la seguridad de Kubernetes como escaneo de imágenes con algunas comprobaciones YAML adjuntas. Ese enfoque pasa por alto dónde ocurren los peores fallos: identidad, admisión y los operadores de confianza encargados de conectarlos. Estos conceptos básicos de seguridad de Kubernetes comienzan con los límites alrededor de la imagen.

Así que seguiremos una carga de trabajo mientras se envía. Escribiremos el manifiesto, solicitaremos acceso, moveremos imágenes y Secrets mediante CI, pasaremos la admisión, restringiremos el alcance de red y, después, detectaremos cambios y abusos. No necesitas controlar cada enlace. Sí necesitas saber quién lo hace.

En este artículo

• Tu Deployment atraviesa cinco etapas operativas
• Tu carga de trabajo rara vez debería necesitar RBAC para todo el clúster
• Restricted PSA debería ser una prueba que tu pod supera
• Para payments-api, la contraseña de la base de datos tiene una ruta de almacenamiento
• Cierra las rutas de red que no pretendías abrir
• Haz que CI detenga el artifact incorrecto antes del despliegue
• Usa el CIS Benchmark para asignar responsabilidades
• Los audit logs muestran quién cambió el límite
• Haz estas seis preguntas antes de enviar

Tu Deployment atraviesa cinco etapas operativas

Y considera un Deployment ficticio llamado payments-api en el namespace payments. Usa un ServiceAccount, lee una credencial de base de datos desde un Secret, se conecta a una base de datos interna y ejecuta una imagen creada por CI.

Y su ruta tiene cinco etapas operativas. La revisión de identidad y del manifiesto comparten el primer límite:

1. Escribir y solicitar acceso: tu código y la identidad de despliegue envían recursos a Kubernetes; RBAC decide qué pueden cambiar.
2. Construir y almacenar el artifact: CI construye, escanea, firma y envía la imagen a un registro.
3. Admitir el pod: Pod Security Admission y cualquier política adicional deciden si el pod puede ejecutarse.
4. Conectar la carga de trabajo: la política de red limita los servicios alcanzables, mientras que la configuración de Secret controla el acceso a las credenciales.
5. Detectar cambios: los audit logs y las señales de runtime muestran quién cambió el límite y qué ocurrió después.

Puedes controlar la imagen, el Deployment, el ServiceAccount, las etiquetas del namespace y los permisos de CI. El equipo de plataforma puede controlar el servidor de API, etcd y kubelet. También puede controlar la configuración de admisión, la implementación de red y el pipeline de auditoría. Para las preguntas de identidad, empieza con la guía de gestión de identidad y acceso de Blackhawk.

Los servicios gestionados suelen operar gran parte del control plane, pero el límite exacto y las evidencias disponibles varían según el proveedor. Pregunta qué partes están gestionadas. Pregunta qué puedes configurar y qué pruebas puedes recibir. Un control plane gestionado no hace automáticamente seguros el RBAC de la aplicación, la política de pods, la procedencia de las imágenes ni el acceso a Secrets.

Para payments-api, CI establece hechos sobre el artifact. RBAC controla quién puede enviar o modificar recursos. La admisión comprueba configuraciones peligrosas del pod, mientras que la política de red limita las cargas de trabajo alcanzables. Los permisos de Secret protegen la credencial de la base de datos. El equipo de plataforma debería proporcionar evidencias de configuración para los límites que opera.

Tu carga de trabajo rara vez debería necesitar RBAC para todo el clúster

Empieza por el ServiceAccount. Después inspecciona cada permiso asociado a él.

Usa por defecto un Role y un RoleBinding con alcance de namespace. Un ClusterRole o ClusterRoleBinding solo pertenece al diseño cuando la carga de trabajo realmente requiere acceso a todo el clúster. Un binding a cluster-admin no es un atajo; es admitir que nadie ha diseñado el permiso que la carga de trabajo realmente necesita.

Para payments-api, pregunta:

• ¿Qué ServiceAccount usa el pod?
• ¿A qué recursos puede acceder esa identidad?
• ¿Qué verbs están permitidos?
• ¿Necesita list y watch, o solo get?
• ¿CI necesita crear recursos en todo el clúster, o solo en payments?
• ¿Qué bindings instalan los operadores y Helm charts?

Si la aplicación solo consume un Secret o ConfigMap montado, puede que no necesite ningún permiso de Kubernetes API. Eso supone que el kubelet o la configuración de despliegue inyectan el valor; un proceso que llama a Kubernetes API para obtenerlo necesita un permiso explícito.

Por ejemplo, payments-api no debería tener acceso a la API si su credencial de base de datos llega mediante un Secret montado y el proceso nunca consulta Kubernetes. Su identidad de despliegue aún puede necesitar permiso para actualizar el Deployment y el Service en payments, pero esa es una identidad separada con una función distinta.

El mínimo privilegio genera fricción de depuración. “¿Por qué CI no puede desplegar?” suele ser el primer fallo útil porque identifica un permiso que alguien no ha diseñado.

Una revisión de IJERT sobre errores de configuración de RBAC y ServiceAccount describe riesgos que incluyen escalada de privilegios, acceso no autorizado a recursos, exposición de Secrets, abuso de la API y posible compromiso del clúster.

Los dos casos de operadores de 2026 hacen que el RBAC instalado forme parte de tu revisión. Security Arsenal informa que, en el caso de Instana, los objetos con alcance de clúster identificados por un nombre simple de recurso personalizado podían colisionar cuando existían recursos con el mismo nombre en distintos namespaces. Informa que el acceso de escritura a nivel de namespace era suficiente para alcanzar un impacto en todo el clúster.

Tu cambio es un ServiceAccount limitado y un binding con alcance de namespace. La prueba del equipo de plataforma debería ser una revisión de los bindings para todo el clúster, del RBAC generado por operadores y de las identidades autorizadas para modificarlos.

Restricted PSA debería ser una prueba que tu pod supera

PodSecurityPolicy se eliminó en Kubernetes 1.25. Pod Security Standards y el controlador integrado Pod Security Admission lo sustituyeron, y PSA es estable desde Kubernetes v1.25. Los perfiles son Privileged, Baseline y Restricted.

Privileged impone esencialmente ninguna restricción. Baseline bloquea escaladas de privilegios conocidas y admite cargas de trabajo comunes. Restricted es el objetivo útil para las aplicaciones que pueden cumplirlo.

restricted rechazará algunos manifiestos de pods que parecen normales. Esa fricción ayuda a encontrar configuraciones inseguras antes del despliegue.

Para payments-api, un pod compatible con Restricted debería establecer allowPrivilegeEscalation: false, usar un perfil seccomp permitido como RuntimeDefault, evitar hostPath, evitar contenedores e init containers privilegiados y eliminar capabilities restringidas. Debería evitar puertos privilegiados. Los requisitos exactos varían según la versión de Kubernetes y la versión del perfil configurada por el equipo de plataforma.

Elemento de revisión de Restricted	Qué compruebas
Escalada de privilegios	Establece allowPrivilegeEscalation: false.
Seccomp	Declara un perfil permitido, normalmente RuntimeDefault.
Acceso al sistema de archivos del host	Elimina los volúmenes hostPath.
Ejecución privilegiada	Mantén sin privilegios los contenedores y init containers.
Capabilities	Elimina las capabilities que la aplicación no necesita.
Puertos	Evita los puertos tratados como privilegiados por el perfil activo.

Los namespaces seleccionan el modo de PSA mediante etiquetas:

pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/enforce: restricted

audit registra las infracciones, warn las informa al usuario que realiza el envío y enforce rechaza el pod. La documentación de Kubernetes sobre Pod Security Admission afirma que los namespaces sin configuración deben considerarse inseguros y recomienda configurar todos los namespaces.

Un despliegue práctico comienza con audit y warn, y después pasa a enforce una vez reparadas las cargas de trabajo. Valida payments-api frente a la versión de Kubernetes del clúster y la versión del perfil Restricted configurada por el equipo de plataforma. Usa la respuesta de admisión o el informe de validación de la plataforma para resolver el fallo exacto en lugar de adivinar a partir de una lista genérica.

PSA es deliberadamente general. Kyverno u OPA Gatekeeper pueden añadir reglas para requisitos específicos de la organización, pero cada uno añade otro sistema de políticas de admisión, conjunto de pruebas, propietario y modo de fallo. Usa uno cuando alguien vaya a operarlo.

Tu cambio es un pod que supera Restricted o tiene una excepción documentada. La prueba del equipo de plataforma son las etiquetas del namespace, el modo de aplicación y el comportamiento de validación en el clúster objetivo.

Para payments-api, la contraseña de la base de datos tiene una ruta de almacenamiento

Una contraseña de base de datos tiene una ruta de almacenamiento, una lista de lectores y un responsable de rotación. Trátalos como decisiones de seguridad.

Un Secret nativo de Kubernetes almacena datos ordinarios como texto codificado en base64. Base64 solo codifica los datos; no los cifra. El cifrado en reposo depende de la configuración de etcd del clúster.

Haz referencia al Secret desde la carga de trabajo en lugar de incrustar su valor en un repositorio o manifiesto sin formato. Para payments-api, el Secret debería contener únicamente la credencial de base de datos que necesita, y solo el ServiceAccount o la ruta de despliegue previstos deberían poder leerlo.

Pide evidencias específicas al equipo de plataforma:

• ¿Está habilitado el cifrado en reposo de etcd?
• ¿Cómo se gestionan y rotan las claves de cifrado?
• ¿Qué identidades pueden leer Secrets en payments?
• ¿Cómo se registran las lecturas de Secrets sin colocar sus valores en logs?
• ¿Qué almacén externo de Secrets, si existe, se encarga de la rotación y la recuperación?

En clústeres autogestionados, el mecanismo --encryption-provider-config del servidor de API forma parte de la configuración del control plane. Los desarrolladores no deberían añadirlo por su cuenta a un clúster gestionado. Pide al operador la instantánea de configuración pertinente y su responsable.

El cifrado en reposo protege los datos almacenados. No impide que un ServiceAccount con privilegios excesivos solicite texto sin formato.

Sealed Secrets, External Secrets Operator y Vault pueden encajar en organizaciones que ya operan un almacén externo de Secrets. La elección correcta depende de la responsabilidad, la rotación, la recuperación y la forma en que las aplicaciones reciben las credenciales — nada de eso es visible en un manifiesto de Deployment.

Cierra las rutas de red que no pretendías abrir

RBAC responde qué puede hacer una identidad mediante Kubernetes API. La política de red responde a qué cargas de trabajo puede llegar un pod.

Apunta a una postura de denegación predeterminada, y después añade ingress y egress explícitos para el tráfico necesario. Para payments-api, eso significa permitir sus clientes de aplicación, DNS, la base de datos interna, las comprobaciones de estado y la telemetría. No significa permitir tráfico sin restricciones por todo el namespace.

Un despliegue práctico consiste en aplicar primero la política en un namespace que no sea de producción y probar después cada dependencia: tráfico correcto, tráfico rechazado, resolución DNS, telemetría y comportamiento ante fallos. El comportamiento exacto depende de la implementación de red del clúster.

El consejo de red merece el escrutinio más atento: denegar por defecto es un objetivo sólido, pero un manifiesto por sí solo no puede demostrar que tu CNI, tu ruta DNS y tu stack de observabilidad lo apliquen correctamente. Prueba esas afirmaciones en tu clúster.

El equipo de plataforma debería identificar las funciones de política de red compatibles y proporcionar las evidencias de aplicación. Tú deberías documentar las conexiones necesarias y probarlas. La política de red limita la accesibilidad; RBAC limita las acciones de la API. Ninguno de los dos repara un contenedor privilegiado o una imagen no confiable.

Haz que CI detenga el artifact incorrecto antes del despliegue

Escanea la imagen en CI antes de que llegue a la ruta de despliegue. Un escaneo posterior al despliegue no puede detener la admisión original, a menos que el clúster aplique por separado su resultado.

Usa esta secuencia:

• Elige una imagen base mantenida. Registra su origen y el responsable de las actualizaciones.
• Escanea las dependencias y la imagen final. Usa el scanner aprobado y la regla de salida de CI de la organización.
• Fija las referencias de imagen cuando la política lo permita. Esto evita que un despliegue seleccione silenciosamente una etiqueta mutable posterior.
• Firma y verifica los artifacts cuando sea compatible. Un flujo de trabajo basado en Sigstore puede establecer quién produjo una imagen y si cambió. La plataforma debe verificar la firma en algún punto significativo.
• Restringe las descargas en producción. Usa registros aprobados y registra los resultados fallidos de admisión o verificación.

El escaneo y la procedencia responden preguntas distintas. Un escaneo establece el estado de vulnerabilidades conocidas en un momento determinado; la procedencia establece el origen y la integridad.

Tu equipo es responsable del Dockerfile, las dependencias, el control de CI y la referencia de imagen. Pregunta al equipo de plataforma qué registros están permitidos, si las firmas se verifican durante la admisión y dónde aparece una verificación fallida. Una firma que nadie comprueba es documentación decorativa.

La guía de seguridad de la cadena de suministro de software de Blackhawk cubre el límite más amplio de build y dependencias.

Usa el CIS Benchmark para asignar responsabilidades

El Center for Internet Security mantiene el Kubernetes Benchmark como una lista de comprobación de hardening que depende de la versión. Juliet lo describe como unos 120 controles, que varían según la versión de Kubernetes. Cubren la configuración del servidor de API, RBAC y la política de red. También cubren la seguridad de los pods, el cifrado de etcd, la PKI y la configuración de kubelet.

Un benchmark es una evidencia útil y un material de lectura terrible para un desarrollador que necesita enviar algo hoy. Haz coincidir la versión del benchmark con el clúster y después divide el trabajo por artifact:

Área	Lo que cambias o verificas	Lo que demuestra el equipo de plataforma
RBAC	La identidad y los bindings de la carga de trabajo son limitados.	Se revisan los bindings para todo el clúster y los permisos de los operadores.
Seguridad de pods	El manifiesto supera Restricted o tiene una excepción documentada.	Las etiquetas del namespace y los modos de aplicación están configurados.
Secrets	Las referencias a Secrets y el alcance del acceso son limitados.	El cifrado de etcd y la gestión de claves están operativos.
Red	El ingress y el egress necesarios están documentados y probados.	El CNI aplica la política indicada.
Control plane	Las suposiciones del Deployment y de CI están registradas.	Se comprueban el servidor de API, kubelet, PKI, etcd y la configuración de auditoría.

La interpretación útil es sencilla: si un control cambia tu Deployment, ServiceAccount, las etiquetas del namespace, la referencia de imagen o las dependencias de red declaradas, tú eres responsable de corregirlo. Si cambia flags del servidor de API, etcd, kubelet, PKI o la retención de auditoría, solicita evidencias al equipo de plataforma.

Pide pruebas diferentes en cada límite: una revisión de bindings para RBAC, etiquetas del namespace para PSA, una instantánea de configuración de cifrado para etcd, un resultado de admisión para las firmas y un informe del benchmark del clúster que coincida con la versión.

Los audit logs muestran quién cambió el límite

La monitorización de runtime viene después de los primeros controles. La detección no compensa cluster-admin, el acceso sin restricciones a Secrets ni una imagen sin firmar.

El análisis de Security Arsenal sobre CVE-2026-19274 recomienda capturar la actividad create, update, patch y delete relacionada con clusterrolebindings y clusterroles. Captura también los recursos personalizados pertinentes y envía después esos registros a un SIEM.

El equipo de plataforma es responsable de la política de auditoría, el periodo de retención, la entrega al SIEM y las herramientas de runtime. Pide una query o alerta que identifique nuevos bindings para todo el clúster, cambios en los permisos de los operadores y acceso pertinente a Secrets sin registrar su contenido. Pregunta también cómo se investiga un incidente relacionado con tu carga de trabajo.

Deberías saber qué señales existen y quién las recibe. Eso es suficiente. No necesitas operar el pipeline de auditoría para darte cuenta de que nadie puede explicarlo.

Haz estas seis preguntas antes de enviar

1. ¿El pod usa un ServiceAccount con un alcance limitado?
2. ¿Se ha probado el namespace contra Restricted PSA y están documentadas las excepciones?
3. ¿Los Secrets están cifrados en reposo y solo son legibles por las identidades que los necesitan?
4. ¿La red aplica una denegación predeterminada con las conexiones necesarias explícitas?
5. ¿Se escaneó la imagen y puede la organización establecer su procedencia?
6. ¿Qué controles del servidor de API y de kubelet pertenecen al equipo de plataforma? ¿Y qué ocurre con etcd, los audit logs y el RBAC para todo el clúster? ¿Cuándo se demostró cada uno por última vez?

Envía el manifiesto con las seis respuestas adjuntas; cada control de la plataforma sin respuesta necesita un responsable y una fecha.