La comunidad de CloudNativePG se complace en anunciar la disponibilidad inmediata de CloudNativePG 1.30.0.

Esta versión menor introduce el nuevo CRD DatabaseRole para la gestión declarativa y compatible con GitOps de roles de PostgreSQL así como un mecanismo de elección de primario basado en Lease que mejora la seguridad del failover. Además, incluye mejoras relevantes de seguridad y operativas, consolidando aún más CloudNativePG como el operador líder para ejecutar cargas de trabajo de PostgreSQL en Kubernetes.

Nos complace anunciar también la disponibilidad de las versiones de mantenimiento 1.29.2 y 1.28.4, siendo esta última la última versión prevista dentro de la serie 1.28.x. Recomendamos a los usuarios de 1.28 que planifiquen la actualización a 1.29 o 1.30.

Con la publicación de CloudNativePG 1.30.0, la serie 1.28.x llega al final de su ciclo de vida  (EOL) el 30 de junio de 2026, y se confirma que la fecha de fin de vida útil de la serie 1.29.x será el 29 de septiembre de 2026.

Lo más destacado en in 1.30.0

CRD DatabaseRole para la gestión declarativa de roles

La principal incorporación en la versión 1.30 es el nuevo recurso personalizado DatabaseRole, que permite gestionar un rol de PostgreSQL como un objeto de Kubernetes independiente, en lugar de definirlo directamente dentro de la sección .spec.managed.roles del Cluster. Cada rol dispone ahora de su propio ciclo de vida, estado y configuración RBAC, lo que encaja mejor con flujos de trabajo GitOps y permite mantener las definiciones de roles junto a las aplicaciones que los utilizan. Migrar un rol existente es tan sencillo como trasladar su definición a un manifiesto dedicado.

Un DatabaseRole puede incluir también un bloque clientCertificate, lo que permite que el operador genere y renueve automáticamente un certificado TLS de cliente. Este certificado es firmado por la CA de cliente del clúster y se guarda en un Secret llamado <databaserole-name>-client-cert. Esto habilita la autenticación en PostgreSQL mediante cert sin necesidad de contraseña, y el Secret se elimina automáticamente si la funcionalidad se desactiva o si se borra el recurso

Lease primario para una elección segura del nodo primario

CloudNativePG 1.30 incorpora un objeto Kubernetes de tipo Lease, con el nombre del clúster, que funciona como un mecanismo de exclusión mutua para controlar la promoción del nodo primario. El gestor de instancias debe adquirir este lease antes de convertirse en primario y lo libera durante un apagado limpio, lo que permite que las réplicas puedan promocionarse sin esperar a que expire completamente el TTL. Los intervalos de tiempo (timmings) se pueden ajustar mediante la nueva sección .spec.primaryLease.

En términos de arquitectura, el lease actúa como una puerta de control de promoción, no como una barrera. El aislamiento del primario sigue siendo el encargado del fencing; el Lease simplemente reduce la ventana en la que podría producirse una promoción no coordinada durante las transiciones.

Mayor seguridad y resiliencia del sistema

Esta versión incorpora mejoras importantes orientadas a reforzar la estabilidad, la seguridad y la integridad de la cadena de suministro de software:

• Anclaje de search_path  (CVE-2026-55769): Se corrigió una vulnerabilidad de escalada de privilegios (CWE-426) en la que un propietario de base de datos podía insertar operadores sobrecargados en el esquema public. A partir de ahora, el operador fija el search_path = pg_catalog, public, pg_temp en las conexiones del pool.
• Codificación de contraseñas SCRAM-SHA-256 (CVE-2026-55765): El operador ahora aplica SCRAM-SHA-256 a las contraseñas en texto plano antes de emitir comandos CREATE/ALTER ROLE, de forma que en logs o capturas de extensiones solo pueda aparecer el verificador SCRAM y no la contraseña en claro.
• Comunicación autenticada entre instancias (GHSA-7qwx-x8ff-3px9): la comunicación entre el operador y el gestor de instancias ahora está protegida mediante autenticación con certificados ECDSA. Este refuerzo de seguridad es nuevo en la versión 1.30.0 y no se ha incluido en versiones anteriores, por lo que en esas versiones sigue siendo necesario restringir el puerto de estado de la instancia mediante una NetworkPolicy.

Otras mejoras relevantes

• Actualizaciones principales en sitio con extensiones: las actualizaciones mayores en sitio mediante pg_upgrade están ahora soportadas para clústeres que emplean extensiones Image Volume, mediante el montaje simultáneo de las imágenes de extensiones de las versiones origen y destino, lo que permite una reversión limpia si la actualización falla.
• Administración de las imágenes de PgBouncer mediante Catálogos de Imágenes: ahora el Pooler puede utilizar una entrada de ImageCatalog o ClusterImageCatalog a través de spec.pgbouncer.imageCatalogRef. Cuando se modifica una entrada del catálogo, todos los Poolers que la referencian se sincronizan automáticamente y se actualizan mediante un nuevo despliegue.
• TLS para el endpoint de métricas del Pooler mediante .spec.monitoring.tls.enabled, con recarga automática de los certificados en cada handshake, sin necesidad de reiniciar el servicio.
• Cluster como objetivo de VPA/HPA gracias a un nuevo campo status.selector en el subrecurso scale , que vincula el Cluster con los pods que ejecutan sus instancias.
• Mayor visibilidad del estado del nodo primario — el operador genera ahora un evento de advertencia PrimaryStatusCheckFailed cuando un pod primario aparece como Ready para el kubelet, pero no supera la verificación /pg/status realizada por el operador, lo que permite identificar los aplazamientos del failover mediante kubectl describe cluster.

Esta versión también añade soporte para Kubernetes 1.36 y establece PostgreSQL 18.4 como la versión predeterminada.

Cambio importante en la API: La referencia al cluster pasa a ser inmutable para los recursos Database, Pooler, Publication, Subscription y ScheduledBackup. A partir de ahora, cualquier intento de reasignar uno de estos recursos a otro clúster será rechazado mediante una regla de validación CEL en el servidor de la API, ya que esa operación carecía de un comportamiento claramente definido.

Para conocer todos los cambios, mejoras y correcciones incluidos en esta versión, consulten las notas de la versión de CloudNativePG 1.30.

Versiones de mantenimiento: 1.29.2 & 1.28.4

Junto con el lanzamiento de la versión 1.30, también publicamos actualizaciones de mantenimiento para la serie estable anterior. Ambas incluyen las correcciones de seguridad descritas anteriormente, incorporadas mediante backport, entre ellas el anclaje de search_path y la codificación de contraseñas con SCRAM-SHA-256. Además, añaden soporte para VPA/HPA, mayor visibilidad del estado de la instancia primaria, recarga automática del complemento CNPG-I, compatibilidad con Kubernetes 1.36, PostgreSQL 18.4 como versión predeterminada y decenas de correcciones de errores:

• CloudNativePG 1.29.2: consulten las notas de la versión 1.29.
• CloudNativePG 1.28.4: versión final de mantenimiento prevista para la serie 1.28.x: consulten las notas de la versión 1.28. Se recomienda encarecidamente planificar la migración a una versión actualmente soportada y mantenida.

Recomendamos a todos los usuarios actualizar a las versiones estables más recientes para aprovechar nuevas funciones, mejoras de seguridad y correcciones de errores.

Para una transición fluida, consulten las instrucciones de actualización.

Únanse a la Comunidad

¡Únanse a nosotros y contribuyan a dar forma al futuro de Postgres nativo en la nube!

Si están utilizando CloudNativePG en producción, les animamos a que consideren la posibilidad de que su organización se una a la lista de los que han adoptado nuestro proyecto apoyando su crecimiento y evolución.

¡Gracias por su continuo apoyo! Actualicen hoy mismo y descubran cómo CloudNativePG puede elevar su experiencia con PostgreSQL a un nuevo nivel.