SOPS et Sealed Secrets : garder les secrets hors de Git pour les MSP Kubernetes

Deux projets open source établis, getsops/sops et bitnami/sealed-secrets, comblent une lacune fréquente des pipelines GitOps : garder les valeurs secrètes hors du texte en clair dans le contrôle de version tout en permettant au bon cluster de les déchiffrer automatiquement.

Ce que fait chaque outil

SOPS, avec environ 22 000 étoiles GitHub, chiffre les fichiers de configuration et de secrets avant leur commit, en s’appuyant sur des backends de type age, PGP ou KMS cloud. L’accès au déchiffrement est contrôlé par la détention de la clé, indépendamment de qui dispose d’un accès en lecture au dépôt. Sealed Secrets, maintenu avec environ 9 000 étoiles, adopte une approche liée au cluster : un outil côté client chiffre un Secret Kubernetes avec la clé publique du cluster cible, produisant une ressource personnalisée SealedSecret qu’il est sûr de stocker dans Git. Seul le contrôleur présent dans le cluster, qui détient la clé privée correspondante, peut la retransformer en Secret utilisable.

Où ils s’insèrent, et ce qu’ils ne remplacent pas

Utilisés ensemble, les deux outils couvrent les moitiés complémentaires d’un même problème : SOPS protège des fichiers arbitraires avant qu’ils n’atteignent Git, et Sealed Secrets protège le cas spécifique d’un Secret Kubernetes lié à un cluster donné. Ni l’un ni l’autre ne remplace la rotation des identifiants, le contrôle d’accès basé sur les rôles ou l’isolation réseau — un SealedSecret peut être commité sans risque, mais il reste du texte chiffré pour une frontière de déchiffrement précise, pas un substitut à l’accès à moindre privilège. L’hygiène pratique compte ici : restreindre qui peut exécuter une opération de déchiffrement en CI, ne jamais imprimer de valeurs déchiffrées dans les journaux de build, et surveiller la santé du contrôleur Sealed Secrets ainsi que son calendrier de rotation des clés de scellement. Valider toute modification de l’un ou l’autre pipeline dans un cluster hors production avant de la déployer.

L’habitude qui vaut la peine d’être adoptée

La valeur de chaque outil tient au contrôle qu’il impose — un build qui échoue lorsqu’un secret en clair se glisse dans un commit, ou une frontière de déchiffrement qu’un seul cluster peut franchir — et non au nom de l’outil sur une diapositive. Épinglez les versions, gardez les fichiers chiffrés revus dans les pull requests et traitez la rotation des clés comme une tâche planifiée plutôt que comme une réponse à incident.

Sources : getsops/sops, bitnami/sealed-secrets.