El blog de CNCF presenta una receta operativa para construir una pila de código abierto de gestión de secretos en Kubernetes, que combina OpenBao y CloudNativePG. OpenBao es el fork de código abierto de HashiCorp Vault bajo el paraguas de Linux Foundation, mientras que CloudNativePG convierte un clúster de PostgreSQL en un servicio autorreparable, con replicación síncrona y autenticación basada en certificados. La receta aprovecha Kubernetes, un proyecto graduado de CNCF, y CloudNativePG, un proyecto Sandbox sometido a la evaluación del comité técnico de supervisión de CNCF para pasar a la etapa de Incubation.
La idea principal no es simplemente utilizar PostgreSQL como un almacén convencional, sino hacer que OpenBao dependa de un backend de PostgreSQL altamente disponible y sin depender de una base de datos en la nube propiedad de un proveedor concreto. La receta utiliza tres instancias de CloudNativePG, con replicación síncrona basada en quórum, de modo que basta con que haya disponible una única réplica síncrona para garantizar la durabilidad de los datos. En cambio, las operaciones de escritura pueden detenerse si no hay una réplica que cumpla la condición de durabilidad requerida.
¿Qué cambia en el diseño?
OpenBao utiliza su almacenamiento nativo de PostgreSQL, con la tabla de bloqueo de alta disponibilidad activada mediante la opción ha_enabled = true. La configuración crea dos tablas: openbao_kv_store para almacenar los datos y openbao_ha_locks para conservar los registros de bloqueos de alta disponibilidad. La receta desactiva el almacenamiento local predeterminado en el esquema de OpenBao, porque se supone que todo el estado debe permanecer en CloudNativePG.
CloudNativePG ejecuta un clúster de PostgreSQL de tres instancias, dirigiéndolas a nodos dedicados y logrando su distribución entre dominios de fallo separados mediante selectores de nodos, tolerancias y restricciones de afinidad de contenedores. La receta utiliza un catálogo de imágenes que especifica la versión menor de PostgreSQL 18, en lugar de escribir manualmente una etiqueta de imagen fija, y también muestra un caso de prueba que utilizó una imagen asegurada mediante un resumen SHA.
Autenticación sin contraseñas
Uno de los aspectos más importantes de la receta es eliminar las contraseñas de la conexión de OpenBao con la base de datos. CloudNativePG crea objetos DatabaseRole para un rol propietario del esquema y un rol de ejecución restringido llamado openbao-rw, y ambos reciben un certificado de cliente TLS. Las reglas de pg_hba exigen una conexión TLS y un certificado de cliente para estos dos roles, mientras rechazan las conexiones no cifradas.
Este detalle es importante porque crear el certificado por sí solo no obliga automáticamente a utilizarlo; son las reglas de PostgreSQL las que determinan, para cada conexión, si la autenticación se realizará mediante certificado, mediante contraseña o si será rechazada. La receta también establece los permisos de los archivos de secretos montados dentro de los contenedores en 0640, porque la biblioteca libpq rechaza las claves privadas que pueden ser leídas por el grupo o por todos los usuarios cuando se montan con el valor predeterminado 0644.
Como DatabaseRole actualmente no gestiona, según el artículo, la concesión de permisos a nivel de tabla, se ejecuta una tarea Job única con comandos para crear las tablas y conceder los permisos SELECT, INSERT, UPDATE y DELETE al rol restringido. La tarea también revoca el permiso CONNECT de PUBLIC y el permiso de uso del esquema público de PUBLIC, y después vuelve a conceder el mínimo necesario a openbao-rw. En la configuración de OpenBao se activa la opción skip_create_table para que el rol de ejecución restringido no intente crear las tablas por sí mismo.
¿Qué significa esto en la práctica para los operadores de Kubernetes?
La receta ofrece una ruta de prueba local mediante el repositorio cnpg-playground, que crea un clúster Kind de seis nodos e incluye configuraciones de CloudNativePG preconfiguradas. La prueba requiere Docker, Kind, Helm y kubectl. Sin embargo, la distribución de nodos en el entorno de prueba impone una limitación importante: hay nodos de PostgreSQL dedicados y etiquetados, y para distribuir tres réplicas de OpenBao con afinidad obligatoria solo quedan dos nodos generales. Por ello, la receta permite temporalmente que OpenBao utilice un nodo del plano de control en el entorno Kind, con una advertencia explícita de no trasladar esta tolerancia a producción. En un clúster de producción con tres nodos de trabajo no etiquetados, este tratamiento no sería necesario.
Después de instalar el esquema de OpenBao, hay que inicializar el clúster y quitar el sello de cada instancia por separado utilizando las tres claves de Shamir requeridas de un total de cinco. Quitar el sello de la primera instancia no quita el sello de las otras dos, y la política predeterminada OrderedReady del StatefulSet retrasa la creación de la siguiente instancia hasta que la anterior esté lista. Por lo tanto, las claves para quitar el sello y el token raíz deben guardarse de forma segura, y después deben introducirse las claves en cada instancia siguiendo el orden.
Después de la inicialización, OpenBao almacena el estado de arranque y sus claves dentro de la tabla openbao_kv_store, y el valor del secreto de prueba se conserva como datos cifrados de tipo BYTEA, no como texto en claro, incluso al acceder directamente a la tabla de PostgreSQL. El artículo confirma el éxito de una prueba de escritura y lectura de un secreto mediante KV v2 y el rol restringido de PostgreSQL.
Limitaciones operativas y aspectos no cubiertos por la receta
CloudNativePG renueva automáticamente los certificados: el certificado de cliente de CNPG tiene una duración de 90 días y normalmente se renueva aproximadamente una semana antes de expirar. Sin embargo, OpenBao no vuelve a leer automáticamente los archivos de certificados; la interfaz de almacenamiento de PostgreSQL abre el conjunto de conexiones al iniciar el proceso. Por lo tanto, hay que planificar un reinicio gradual de las instancias de OpenBao después de la renovación, preferiblemente dentro de la ventana de renovación de 83 días previa a la expiración del certificado antiguo.
Además, la alta disponibilidad dentro de un clúster de Kubernetes no equivale a un plan completo de recuperación. La receta no crea automáticamente copias de seguridad ni mecanismos de recuperación ante la pérdida del clúster completo. Para uso en producción, el artículo recomienda añadir Barman Cloud Plugin con un almacén de objetos como Amazon S3, Google Cloud Storage o Azure Blob Storage, y utilizar los recursos Backup y ScheduledBackup para archivar el WAL y las copias base, y permitir la recuperación a un momento determinado. En cuanto a los objetivos RTO y RPO que requieren sobrevivir a la pérdida de un clúster completo, se necesita un clúster de PostgreSQL asíncrono en un segundo clúster o región.