Administration PostgreSQL

Bouton Administrer d'une carte PostgreSQL (chart/postgres) — visible une fois l'application Running, réservé aux utilisateurs ayant le rôle admin sur le namespace.

La modale se connecte en direct à la base de l'application (pas de copie ni de cache côté Control Panel) avec le compte administrateur créé par le chart au déploiement. Trois onglets :

Bases de données

Liste les bases existantes (hors bases techniques) et permet d'en créer une nouvelle par son nom.

Utilisateurs & droits

• Créer / réinitialiser un utilisateur : s'il n'existe pas encore, il est créé ; s'il existe déjà, son mot de passe est régénéré. Le mot de passe généré n'est affiché qu'une seule fois, juste après l'opération — Postgres ne le stocke jamais en clair, il ne peut donc pas être relu ensuite. Notez-le ou copiez-le immédiatement.
• Les rôles marqués Système (streaming_replica, cnpg_metrics_exporter, et le compte administrateur créé par le chart lui-même) sont des rôles techniques de la plateforme : ils n'apparaissent pas dans le champ Accorder des droits, et leur mot de passe ne peut pas être réinitialisé depuis cette interface.
• Cliquer sur un utilisateur déplie ses droits actuels, base par base (capture ci-dessus). Le niveau affiché est déduit des privilèges réellement présents sur les tables du schéma public — pas d'un historique des accords : Accès à la base signifie CONNECT accordé mais aucune table pour l'instant (un ALTER DEFAULT PRIVILEGES en attente d'une future table ne laisse aucune trace avant qu'elle existe), et Droits personnalisés signifie un jeu de privilèges qui ne correspond à aucun des trois niveaux ci-dessous (modifiés à la main via l'onglet Exécuter SQL).
• Accorder des droits applique un niveau — Lecture seule, Lecture-écriture ou Tous les droits — à un utilisateur sur une base, y compris pour les objets créés ultérieurement (ALTER DEFAULT PRIVILEGES).

Exécuter SQL

Une commande SQL libre contre la base choisie, avec coloration syntaxique. Un SELECT retourne un tableau de résultats ; toute autre commande (DDL/DML) affiche le statut renvoyé par Postgres (ex. CREATE TABLE, nombre de lignes affectées).

Warning

Cet onglet exécute n'importe quelle commande SQL, y compris destructrice (DROP TABLE, DELETE sans WHERE…). Il n'y a pas de confirmation intermédiaire : vérifiez la commande et la base sélectionnée avant d'exécuter.

Tip

Il n'y a pas de bouton de suppression dédié pour une base ou un utilisateur : passez par l'onglet Exécuter SQL (DROP DATABASE, ou DROP OWNED BY suivi de DROP ROLE pour un utilisateur ayant reçu des droits). Une base ne peut pas être supprimée en étant connecté dessus — sélectionnez une autre base avant d'exécuter le DROP DATABASE.

Accès externe

Bouton Accès externe d'une carte PostgreSQL — visible une fois l'application Running, réservé aux utilisateurs ayant le rôle admin sur le namespace.

Par défaut, une base n'est joignable que depuis le cluster (<nom-app>-rw.<namespace>.svc.cluster.local). Exposer la base lui attribue un port TCP sur le Gateway partagé, choisi automatiquement dans une plage réservée (paramètre cluster CUSTOM_PORT_AUTO_RANGE, défaut 30000-35000) : aucun numéro de port à saisir, et aucun risque de reprendre un port déjà utilisé par la plateforme. Le nom public de la base est <nom-app>-<namespace>.pg.<domaine> quand la plateforme dispose d'un certificat public pour les bases (voir plus bas), <nom-app>-<namespace>.<domaine> sinon.

L'exposition exige TLS par défaut :

• les connexions non chiffrées sont refusées sur cette base, y compris depuis le cluster (règle hostnossl … reject ajoutée au pg_hba) ;
• la base sert un certificat qui couvre son nom public, ce qui rend sslmode=verify-full possible ;
• la modale affiche l'URI de connexion et l'URL JDBC correspondantes.

Certificat reconnu publiquement (cas normal). Quand un certificat wildcard Let's Encrypt est configuré pour les bases (paramètre cluster POSTGRES_PUBLIC_TLS_SECRET), la base le sert à la place du certificat de CNPG. Le client vérifie le serveur avec son propre magasin de certificats : aucun fichier à lui fournir, et le renouvellement est automatique et sans coupure. Les URL affichées en tiennent compte : sslrootcert=system pour psql et libpq 16 ou plus (avec une version plus ancienne, pointez sslrootcert vers le bundle système, par exemple /etc/ssl/certs/ca-certificates.crt), sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory en JDBC pour utiliser le truststore Java.

Sans certificat public configuré, le nom public est ajouté au certificat généré par CNPG, signé par une CA propre à la base. La modale permet alors de télécharger le certificat de la CA — à passer au client (sslrootcert) pour vérifier le serveur. CNPG renouvelle cette CA périodiquement (date d'expiration affichée) : le fichier téléchargé devra être remplacé à ce moment-là. Pour verify-full, l'URI référence ce fichier sous son nom de téléchargement (sslrootcert=<nom-app>-ca.crt) : placez-le dans le répertoire de travail du client, ou adaptez le chemin.

Ce que change « Exiger TLS » pour les clients existants

La plupart des clients négocient TLS d'eux-mêmes dès que le serveur le propose — ce que fait CNPG en permanence — et ne voient donc aucune différence : psql, psycopg, et le driver JDBC embarqué par DigDash (pgjdbc 42.7, sslmode=prefer par défaut depuis 42.2.9). Les connexions DigDash créées automatiquement vers une base du même namespace sont dans ce cas : elles sont déjà chiffrées et continuent de fonctionner.

Seul un client qui désactive explicitement le chiffrement (sslmode=disable) est refusé. Pour imposer le chiffrement côté client sans dépendre de la négociation, utilisez ?sslmode=require ; en JDBC, n'utilisez pas ssl=true seul, qui équivaut à verify-full et échoue faute de certificat de CA.

Warning

Comme pour tout port exposé, le forward pare-feu externe n'est pas automatisé : faites pointer le port affiché vers le Load Balancer du cluster, dont les adresses sont rappelées dans la modale.

Restreindre les adresses sources

Le champ Adresses IP autorisées limite les connexions externes à une liste d'adresses IP ou de plages CIDR, une par ligne (203.0.113.7, 198.51.100.0/24, IPv6 acceptée). Il se renseigne à l'exposition ou plus tard, base exposée, avec Enregistrer. Laissé vide, toute adresse que le pare-feu externe laisse passer est acceptée.

Le filtrage est appliqué par le proxy du Gateway partagé, avant que la connexion n'atteigne la base : une source refusée voit sa connexion coupée sans échange avec PostgreSQL. Il porte sur l'adresse publique du client telle qu'elle arrive au cluster (adresse de sortie d'un VPN ou d'un NAT d'entreprise, par exemple).

Note

Une modification s'applique aux nouvelles connexions ; une session déjà ouverte depuis une adresse retirée n'est pas coupée. Les applications du cluster (DigDash…) doivent utiliser l'accès interne, qui ne passe pas par ce filtrage — par le nom public, elles apparaîtraient avec l'adresse du pare-feu.

Retirer l'exposition supprime le port et la route. L'exigence de TLS, elle, reste en place — des clients ont pu s'y adapter entre-temps — et se modifie depuis Configurer, catégorie Sécurité.

Les volumes d'une base PostgreSQL ne se redimensionnent ni ne se copient depuis la page Volumes : voir Volumes.