AWS corrige un bypass de autorización en Private CA Connector for Kubernetes
CVE-2026-119115 permitía que un usuario autenticado con permiso de namespace obtuviera certificados de un emisor de clúster no autorizado. AWS fija el conector y EKS add-on, pero la versión nueva exige revisar issuerRef.kind antes de actualizar.
AWS publicó el 29 de octubre el boletín 2026-156 para CVE-2026-119115, un fallo de autorización en la resolución de emisores del AWS Private CA Connector for Kubernetes. Bajo ciertas configuraciones, un usuario autenticado cuya aprobación solo cubría un emisor de namespace podía obtener certificados firmados por un emisor de clúster fuera de su permiso, incluidos certificados de CA subordinada. No es una entrada anónima desde Internet: el escenario descrito parte de un usuario que ya puede solicitar certificados en el entorno.
El componente conecta cert-manager con AWS Private Certificate Authority para firmar solicitudes de certificados dentro de Kubernetes y también se ofrece como complemento de EKS. La diferencia entre un emisor limitado a un namespace y uno de alcance de clúster es un límite de autorización real: una petición no debe poder saltar de uno al otro por una resolución ambigua del tipo de recurso.
-SecureCrew dice: un permiso de namespace que termina firmando como clúster no es una elevación «de cortesía»; es justo el límite que había que mantener.-
El permiso de un emisor no se hereda del otro
El problema estaba en cómo el conector resolvía la referencia del emisor. Una cuenta con permiso para una entidad AWSPCAIssuer de namespace podía, en determinadas condiciones, hacer que la solicitud acabara en una entidad AWSPCAClusterIssuer, que tiene alcance de clúster. AWS y el aviso upstream describen el riesgo de que ese camino produjera certificados —incluidos los que permiten firmar otras autoridades— pese a que la política del usuario no autorizaba ese emisor.
La consecuencia potencial es seria porque un certificado válido puede establecer identidades de servicio y, en una cadena de confianza, una CA subordinada puede emitir otros certificados. El aviso describe una posibilidad de emisión no autorizada, no una prueba de que se hayan emitido certificados en una instalación concreta ni de que exista una intrusión. El requisito de autenticación y la configuración de emisores forman parte del alcance; no se debe traducir el CVE en «todo certificado de Kubernetes quedó expuesto».
-SecureCrew dice: en PKI, el nombre del objeto y su ámbito no son decoración de YAML; deciden quién puede firmar por quién.-
La versión corregida es más estricta con las referencias
AWS corrigió el conector aws-privateca-issuer en 1.10.1 y el complemento de EKS en 1.10.1-eksbuild.1. La versión corregida exige que el campo issuerRef.kind indique explícitamente el tipo de emisor correcto —AWSPCAIssuer o AWSPCAClusterIssuer— y que coincida con el recurso referenciado. Esto cierra la resolución ambigua, pero puede sacar a la luz manifiestos que antes renovaban certificados gracias a una referencia incompleta o mal tipada.
Antes de actualizar, AWS recomienda revisar los recursos CertificateRequest y Certificate, además de las anotaciones Ingress que crean solicitudes, para ajustar issuerRef.kind al ámbito real. Una solicitud con el tipo ausente o incorrecto puede quedar en estado Failed; si se declara un emisor de namespace para apuntar a uno de clúster, puede permanecer Pending. Si un certificado deja de renovarse, los servicios que dependen de él pueden fallar cuando llegue su expiración, por lo que conviene hacer la revisión antes del cambio y no descubrirlo durante una rotación nocturna.
Si el parche no puede desplegarse inmediatamente, AWS recomienda limitar las políticas de aprobación y las reglas RBAC tanto por nombre como por tipo de emisor. Esa mitigación estrecha las solicitudes que pueden aprobarse, pero no sustituye la actualización a una versión corregida. Las ramas o copias derivadas también necesitan incorporar el arreglo si incluyen el conector afectado.
-SecureCrew dice: un parche que endurece una validación también puede detener renovaciones mal declaradas; el certificado no conoce el calendario de cambios del equipo.-
Para los responsables de clústeres, el trabajo no termina en comprobar el número de versión: hay que identificar si se usa el chart o el complemento de EKS, validar el tipo y ámbito de cada emisor y comprobar que las solicitudes de certificado siguen avanzando después de actualizar. La buena noticia es que el fallo tiene una corrección concreta y una configuración revisable; la mala es que una autoridad de clúster no debería depender de que una referencia ambigua se interprete con benevolencia.
Diccionario de la Crew
cert-manager — Componente de Kubernetes que gestiona solicitudes y ciclos de vida de certificados.
CA — Autoridad certificadora que firma certificados y puede encadenarlos mediante autoridades subordinadas.
AWSPCAIssuer — Recurso que representa un emisor de AWS Private CA limitado a un namespace.
AWSPCAClusterIssuer — Recurso emisor de AWS Private CA con alcance de clúster.
issuerRef.kind — Campo de la solicitud que identifica el tipo de recurso emisor referenciado.
RBAC — Control de acceso basado en roles para usuarios y componentes de Kubernetes.
EKS — Servicio gestionado de Kubernetes de AWS.
