Administración de PostgreSQL

El botón Administrar de una tarjeta PostgreSQL (chart/postgres) — visible una vez que la aplicación está Running, reservado a los usuarios con el rol admin en el namespace.

La modal se conecta en directo a la base de datos de la aplicación (sin copia ni caché en el Control Panel) con la cuenta administradora que el chart creó en el despliegue. Tres pestañas:

Bases de datos

Lista las bases existentes (excluyendo las técnicas) y permite crear una nueva indicando su nombre.

Usuarios y permisos

• Crear / reiniciar un usuario: si aún no existe, se crea; si ya existe, se regenera su contraseña. La contraseña generada se muestra solo una vez, justo después de la operación — Postgres nunca la almacena en texto plano, así que no se puede volver a leer después. Anótela o cópiela de inmediato.
• Los roles marcados como Sistema (streaming_replica, cnpg_metrics_exporter, y la cuenta administradora creada por el propio chart) son roles técnicos de la plataforma: no aparecen en el campo Otorgar permisos, y su contraseña no puede reiniciarse desde esta interfaz.
• Hacer clic en un usuario despliega sus permisos actuales, base por base (captura arriba). El nivel mostrado se deduce de los privilegios realmente presentes en las tablas del esquema public — no de un historial de concesiones: Acceso a la base significa que se otorgó CONNECT pero aún no hay ninguna tabla (un ALTER DEFAULT PRIVILEGES pendiente de una tabla futura no deja rastro antes de que exista), y Permisos personalizados significa un conjunto de privilegios que no coincide con ninguno de los tres niveles siguientes (modificados a mano desde la pestaña Ejecutar SQL).
• Otorgar permisos aplica un nivel — Solo lectura, Lectura-escritura o Todos los permisos — a un usuario sobre una base, incluidos los objetos creados posteriormente (ALTER DEFAULT PRIVILEGES).

Ejecutar SQL

Un comando SQL libre contra la base elegida, con resaltado de sintaxis. Un SELECT devuelve una tabla de resultados; cualquier otro comando (DDL/DML) muestra el estado devuelto por Postgres (p. ej. CREATE TABLE, número de filas afectadas).

Warning

Esta pestaña ejecuta cualquier comando SQL, incluidos los destructivos (DROP TABLE, DELETE sin WHERE…). No hay confirmación intermedia: verifique el comando y la base seleccionada antes de ejecutar.

Tip

No hay un botón de eliminación dedicado para una base o un usuario: use la pestaña Ejecutar SQL (DROP DATABASE, o DROP OWNED BY seguido de DROP ROLE para un usuario que recibió permisos). Una base no puede eliminarse estando conectado a ella — seleccione otra base antes de ejecutar el DROP DATABASE.

Acceso externo

Botón Acceso externo de una tarjeta PostgreSQL — visible en cuanto la aplicación está Running, reservado a los usuarios con el rol admin en el namespace.

Por defecto, una base de datos solo es accesible desde el clúster (<nombre-app>-rw.<namespace>.svc.cluster.local). Exponer la base de datos le asigna un puerto TCP en el Gateway compartido, elegido automáticamente dentro de un rango reservado (parámetro de clúster CUSTOM_PORT_AUTO_RANGE, por defecto 30000-35000): no hay que indicar ningún número de puerto, y no puede ocuparse un puerto que ya use la plataforma. El nombre público de la base de datos es <nombre-app>-<namespace>.pg.<dominio> cuando la plataforma dispone de un certificado público para las bases de datos (véase más abajo), y <nombre-app>-<namespace>.<dominio> en caso contrario.

La exposición exige TLS por defecto:

• las conexiones sin cifrar se rechazan en esta base de datos, incluidas las procedentes del propio clúster (regla hostnossl … reject añadida al pg_hba);
• la base de datos sirve un certificado que cubre su nombre público, lo que permite usar sslmode=verify-full;
• la ventana muestra la URI de conexión y la URL JDBC correspondientes.

Certificado de confianza pública (caso normal). Cuando hay un certificado wildcard de Let's Encrypt configurado para las bases de datos (parámetro de clúster POSTGRES_PUBLIC_TLS_SECRET), la base lo sirve en lugar del certificado de CNPG. El cliente verifica el servidor con su propio almacén de certificados: ningún archivo que facilitarle, y la renovación es automática y sin corte. Las URL mostradas lo tienen en cuenta: sslrootcert=system para psql y libpq 16 o posterior (con una versión más antigua, apunte sslrootcert al bundle del sistema, p. ej. /etc/ssl/certs/ca-certificates.crt), sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory en JDBC para usar el truststore de Java.

Sin certificado público configurado, el nombre público se añade al certificado generado por CNPG, firmado por una CA propia de la base. La ventana permite entonces descargar el certificado de la CA — que debe facilitarse al cliente (sslrootcert) para verificar el servidor. CNPG renueva esa CA periódicamente (fecha de caducidad mostrada): habrá que reemplazar entonces el archivo descargado. Para verify-full, la URI hace referencia a ese archivo con su nombre de descarga (sslrootcert=<nombre-app>-ca.crt): colóquelo en el directorio de trabajo del cliente, o adapte la ruta.

Qué cambia «Exigir TLS» para los clientes existentes

La mayoría de los clientes negocian TLS por sí mismos en cuanto el servidor lo ofrece — lo que CNPG hace siempre — y por tanto no notan ninguna diferencia: psql, psycopg y el driver JDBC que incluye DigDash (pgjdbc 42.7, sslmode=prefer por defecto desde 42.2.9). Las conexiones que DigDash crea automáticamente hacia una base de datos del mismo namespace están en ese caso: ya están cifradas y siguen funcionando.

Solo se rechaza un cliente que desactive explícitamente el cifrado (sslmode=disable). Para imponer el cifrado del lado del cliente sin depender de la negociación, utilice ?sslmode=require; en JDBC, no use ssl=true por sí solo, que equivale a verify-full y falla sin certificado de CA.

Warning

Como para cualquier puerto expuesto, el reenvío en el cortafuegos externo no está automatizado: dirija el puerto mostrado al Load Balancer del clúster, cuyas direcciones se recuerdan en la ventana.

Restringir las direcciones de origen

El campo Direcciones IP autorizadas limita las conexiones externas a una lista de direcciones IP o rangos CIDR, uno por línea (203.0.113.7, 198.51.100.0/24, IPv6 aceptado). Se rellena al exponer la base o más tarde, con la base ya expuesta, mediante Guardar. Si se deja vacío, se acepta cualquier dirección que el cortafuegos externo deje pasar.

El filtrado lo aplica el proxy del Gateway compartido, antes de que la conexión llegue a la base de datos: a un origen rechazado se le cierra la conexión sin ningún intercambio con PostgreSQL. Se aplica a la dirección pública del cliente tal como llega al clúster (dirección de salida de una VPN o de un NAT corporativo, por ejemplo).

Note

Un cambio se aplica a las nuevas conexiones; una sesión ya abierta desde una dirección retirada no se corta. Las aplicaciones del clúster (DigDash…) deben usar el acceso interno, que no pasa por este filtrado — mediante el nombre público, aparecerían con la dirección del cortafuegos.

Retirar la exposición elimina el puerto y la ruta. La exigencia de TLS permanece — puede que algunos clientes ya se hayan adaptado a ella — y se modifica desde Configurar, categoría Seguridad.

Los volúmenes de una base de datos PostgreSQL no se redimensionan ni se copian desde la página Volúmenes: consulte Volúmenes.