Lyon, le 28 mai 2026
CloudNativePG ou comment embarquer un éléphant sur un porte-conteneurs !
La configuration d’une instance PostgreSQL, où qu’elle soit déployée, nécessite
d’être faite. La configuration des règles d’accès dans pg_hba.conf est
essentielle. Regardons une nouveauté de la version 1.29 de l’opérateur qui
permet de reconfigurer dynamiquement ce fichier.
Rappel sur pg_hba.conf
L’authentification à une instance est paramétrée au moyen de ce fichier. Lorsque le serveur PostgreSQL reçoit une demande de connexion, il connaît le type de connexion utilisé par le client (socket Unix, connexion TCP SSL, connexion TCP simple, etc.). Il connaît aussi l’adresse IP du client (dans le cas d’une connexion via une socket TCP), le nom de la base et celui de l’utilisateur. En fonction des règles présentes et de la méthode d’authentification indiquée, le client est autorisé, ou non, à se connecter.
Une instance déployée avec CloudNativePG voit son fichier pg_hba.conf être
pré-configuré. Il est possible de trouver les règles actuellement définies avec
la requête SQL suivante :
select type, database, user_name, address, netmask, auth_method from pg_hba_file_rules ;
type | database | user_name | address | netmask | auth_method
---------+---------------+-------------------------+---------+---------+---------------
local | {all} | {cnpg_metrics_exporter} | | | peer
local | {all} | {all} | | | peer
hostssl | {postgres} | {streaming_replica} | all | | cert
hostssl | {replication} | {streaming_replica} | all | | cert
hostssl | {all} | {cnpg_pooler_pgbouncer} | all | | cert
host | {all} | {all} | all | | scram-sha-256
La dernière ligne indique que toutes les demandes de connexion à l’instance
faites par n’importe quel utilisateur, sur n’importe quelle base et venant de
n’importe quelle source, doit utiliser le mécanisme d’authentification
scram-sha-256.
Restriction forte des accès
L’ajout de règles se fait via l’opérateur et doit être écrite dans la
définition YAML du Cluster. Prenons le cas de figure où l’on souhaite
autoriser uniquement un rôle d’administration (admin) à se connecter
à la base postgres à distance. Toutes les autres connexions doivent être
rejetées (reject). Cela donnerait quelque chose comme :
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: postgresql-prod
spec:
instances: 1
storage:
size: 1Gi
postgresql:
pg_hba:
- host postgres admin all scram-sha-256
- host all all all reject
Pour des raisons de sécurité, il est préférable de restreindre les connexions
provenant de sources bien identifiées. Ainsi le mot clé all dans cette ligne
- host postgres admin all scram-sha-256
devrait être changé par 10.244.0.10/32, la seule adresse IP source autorisée.
Une restriction forte est donc appliquée… mais qu’en est-il si l’adresse IP
autorisée venait à changer une fois ? la modification ne serait pas trop lourde
à effectuer. Deux fois ? On prendra notre mal en patience et on le ferait. Mais
100 fois ? 1000 fois ? Cela deviendrait intenable. Ceci est d’autant plus vrai
que, dans un contexte Kubernetes, la volatilité des Pods, et donc de leur
adresse IP, est grande et même inhérente à sa conception. Il faut donc avoir un
outil qui permettrait de tenir à jour le fichier pg_hba.conf de notre Cluster.
Résolution dynamique d’adresse
La version 1.29 de l’opérateur apporte cette solution en se reposant sur le
mécanisme de labels de Kubernetes. L’opérateur est capable de reconfigurer le
pg_hba.conf dynamiquement avec l’adresse IP des Pods qui ont un label
spécifique. Prenons l’exemple d’un Pod pgAdmin déployé avec une ressource
Deployment pour laquelle le label app=pgadmin est renseigné.
Dans la partie spec du Cluster, il est désormais possible de renseigner la
section podSelectorRefs qui permet d’indiquer une référence aux Pods
(podSelectorRefs) ayant un label spécifique (selector.matchLabels).
podSelectorRefs:
- name: app-pgadmin
selector:
matchLabels:
app: pgadmin
Aussi, dans la partie pg_hba, le champ correspondant aux adresses IP peut être
remplacé par la syntaxe suivante ${podselector:app-pgadmin}.
postgresql:
pg_hba:
- host postgres admin ${podselector:app-pgadmin} scram-sha-256
- host all all all reject
Désormais, dès lors qu’un Pod avec le label app=pgadmin est créé,
CloudNativePG ajustera le fichier pg_hba.conf et rechargera l’instance
PostgreSQL pour que la nouvelle adresse IP soit autorisée à se connecter.
Le passage du paramètre spec.replicas à 2 du Deployment pgAdmin est bien
“reporté” dans le fichier pg_hba.conf : deux lignes sont présentes avec les
adresses IP des Pods pgAdmin.
psql (18.3 (Debian 18.3-1.pgdg13+1))
Type "help" for help.
postgres=# select type, database, user_name, address, netmask, auth_method from pg_hba_file_rules ;
type | database | user_name | address | netmask | auth_method
---------+---------------+-------------------------+-------------+-----------------+---------------
local | {all} | {cnpg_metrics_exporter} | | | peer
local | {all} | {all} | | | peer
hostssl | {postgres} | {streaming_replica} | all | | cert
hostssl | {replication} | {streaming_replica} | all | | cert
hostssl | {all} | {cnpg_pooler_pgbouncer} | all | | cert
host | {postgres} | {admin} | 10.244.0.11 | 255.255.255.255 | scram-sha-256
host | {postgres} | {admin} | 10.244.0.12 | 255.255.255.255 | scram-sha-256
host | {all} | {all} | all | | reject
host | {all} | {all} | all | | scram-sha-256
(9 rows)
Conclusion
Maintenir un fichier pg_hba.conf pour autoriser ou interdire les accès est
important. Dans un environnement virtualisé ou baremetal, ce fichier n’est
généralement mis à jour que très ponctuellement. Dans des environnements Kubernetes
où la durée de vie des applications peut être très court, des mécanismes
d’automatisation sont nécessaires. C’est le cas de cette nouveauté de la version
1.29 de l’opérateur.
Des questions, des commentaires ? Écrivez-nous !
