Le blog de la CNCF présente une recette opérationnelle pour construire une pile open source de gestion des secrets sur Kubernetes, combinant OpenBao et CloudNativePG. OpenBao est le fork open source de HashiCorp Vault placé sous l’égide de la Linux Foundation, tandis que CloudNativePG transforme un cluster PostgreSQL en service auto-réparateur, doté d’une réplication synchrone et d’une authentification fondée sur les certificats. La recette s’appuie sur Kubernetes, un projet diplômé de la CNCF, et sur CloudNativePG, un projet Sandbox faisant l’objet d’une évaluation par le comité de supervision technique de la CNCF en vue de passer au stade Incubation.
L’idée principale n’est pas simplement d’utiliser PostgreSQL comme stockage ordinaire, mais de faire dépendre OpenBao d’un backend PostgreSQL hautement disponible, sans dépendre d’une base de données cloud propriétaire d’un fournisseur donné. La recette utilise trois instances CloudNativePG, avec une réplication synchrone fondée sur un quorum, de sorte qu’une seule réplique synchrone de secours disponible suffise à garantir la durabilité des données. En revanche, les opérations d’écriture peuvent s’arrêter si aucune réplique de secours ne satisfait la condition de durabilité requise.
Qu’est-ce qui change dans la conception ?
OpenBao utilise son backend de stockage PostgreSQL natif, avec l’activation de la table de verrouillage haute disponibilité via l’option ha_enabled = true. La configuration crée deux tables : openbao_kv_store pour stocker les données, et openbao_ha_locks pour conserver les enregistrements des verrous haute disponibilité. La recette désactive le stockage local par défaut dans le schéma OpenBao, car l’ensemble de l’état est censé rester dans CloudNativePG.
CloudNativePG exécute un cluster PostgreSQL de trois instances, en les dirigeant vers des nœuds dédiés et en assurant leur répartition entre des domaines de défaillance distincts à l’aide de sélecteurs de nœuds, de tolérances et de contraintes d’affinité entre pods. La recette utilise un catalogue d’images qui définit la version mineure de PostgreSQL 18, plutôt que d’écrire manuellement un tag d’image fixe, et présente également un test ayant utilisé une image sécurisée identifiée par un condensat SHA.
Authentification sans mots de passe
L’un des aspects les plus importants de la recette est la suppression des mots de passe de la connexion d’OpenBao à la base de données. CloudNativePG crée des objets DatabaseRole pour un rôle propriétaire du schéma et un rôle d’exécution restreint nommé openbao-rw, et chacun reçoit un certificat client TLS. Les règles pg_hba imposent une connexion TLS et un certificat client pour ces deux rôles, tandis que les connexions non chiffrées sont refusées.
Ce détail est important, car la création du certificat ne suffit pas à imposer automatiquement son utilisation : ce sont les règles PostgreSQL qui déterminent, pour chaque connexion, si l’authentification s’effectue par certificat, par mot de passe ou si elle est refusée. La recette définit également les permissions des fichiers de secrets assemblés dans les conteneurs sur 0640, car la bibliothèque libpq refuse les clés privées lisibles par le groupe ou par tous les utilisateurs lorsqu’elles sont montées avec la valeur par défaut 0644.
Comme DatabaseRole ne gère pas actuellement l’attribution des permissions au niveau des tables selon l’article, une tâche Job exécutée une seule fois lance les commandes de création des tables et accorde les permissions SELECT, INSERT, UPDATE et DELETE au rôle restreint. La tâche retire également à PUBLIC le privilège CONNECT, retire à PUBLIC l’utilisation du schéma public, puis accorde à openbao-rw le minimum requis. L’option skip_create_table est activée dans la configuration d’OpenBao afin que le rôle d’exécution restreint ne tente pas de créer lui-même les tables.
Qu’est-ce que cela signifie concrètement pour les opérateurs Kubernetes ?
La recette propose un parcours de test local utilisant le dépôt cnpg-playground, qui crée un cluster Kind de six nœuds et inclut des configurations CloudNativePG préétablies. L’expérience nécessite Docker, Kind, Helm et kubectl. Toutefois, la répartition des nœuds dans l’environnement de test impose une contrainte importante : les nœuds PostgreSQL sont dédiés et étiquetés, et il ne reste que deux nœuds généraux pour répartir trois répliques OpenBao avec une affinité obligatoire. La recette autorise donc temporairement OpenBao à utiliser un nœud du plan de contrôle dans l’environnement Kind, tout en déconseillant explicitement de transférer cette tolérance en production. Dans un cluster de production comprenant trois nœuds workers non étiquetés, ce traitement n’est pas nécessaire.
Après l’installation du chart OpenBao, il faut initialiser le cluster et désceller chaque instance séparément à l’aide des trois clés Shamir requises sur cinq. Le déscellement de la première instance ne déscelle pas les deux autres, et la politique par défaut OrderedReady du StatefulSet retarde la création de l’instance suivante jusqu’à ce que la précédente soit prête. Il convient donc de conserver en sécurité les clés de déscellement et le jeton root, puis de saisir les clés pour chaque instance dans l’ordre.
Après l’initialisation, OpenBao stocke l’état de démarrage et ses clés dans la table openbao_kv_store, et la valeur du secret de test est conservée sous forme de données chiffrées de type BYTEA, et non en clair, même en cas d’accès direct à la table PostgreSQL. L’article confirme la réussite d’un test d’écriture et de lecture d’un secret à l’aide de KV v2 et du rôle PostgreSQL restreint.
Limites opérationnelles et éléments non couverts par la recette
Le renouvellement des certificats est automatisé par CloudNativePG : la durée de validité d’un certificat client CNPG est de 90 jours et il est généralement renouvelé environ une semaine avant son expiration. Toutefois, OpenBao ne relit pas automatiquement les fichiers de certificats : le backend de stockage PostgreSQL ouvre le pool de connexions au démarrage du processus. Il faut donc planifier un redémarrage progressif des instances OpenBao après le renouvellement, de préférence pendant la fenêtre de renouvellement de 83 jours précédant l’expiration de l’ancien certificat.
En outre, la haute disponibilité au sein d’un cluster Kubernetes ne constitue pas à elle seule un plan complet de reprise. La recette ne crée pas automatiquement de sauvegardes ni de mécanisme de reprise après la perte de l’intégralité du cluster. Pour une utilisation en production, l’article recommande d’ajouter le Barman Cloud Plugin avec un stockage objet tel qu’Amazon S3, Google Cloud Storage ou Azure Blob Storage, et d’utiliser les ressources Backup et ScheduledBackup pour archiver le WAL et les sauvegardes de base, afin de permettre une restauration à un instant donné. Les objectifs de RTO et de RPO nécessitant la survie à la perte d’un cluster entier exigent un cluster PostgreSQL asynchrone dans un deuxième cluster ou une deuxième région.