2 articles tagués avec « vault »

Quand vous construisez une plateforme Kubernetes de production de zéro, vous accumulez des identités non-humaines plus vite que prévu. Au moment où la plateforme minicloud a atteint sa maturité opérationnelle — un cluster k3s bare-metal de 5 nœuds exécutant plus de 70 workloads — elle comptait plus de 35 identités non-humaines distinctes réparties en six catégories différentes. La plupart sont invisibles en exploitation normale. Vous ne les remarquez que lorsque l'une casse.

Cet article cartographie chaque type d'identité non-humaine utilisé sur la plateforme, explique comment ils diffèrent, et documente les leçons opérationnelles tirées de ceux qui ont causé des incidents.

Chaque cluster Kubernetes qui utilise cert-manager pour le TLS porte en lui le même risque silencieux : la clé privée de la CA qui signe tous vos certificats internes se trouve dans un secret Kubernetes, stocké en clair dans le datastore de votre cluster.

Sur les clusters managés avec chiffrement etcd au repos, ce risque est correctement atténué. Sur k3s avec kine et SQLite — comme tournent beaucoup de clusters bare-metal — la table des secrets est en clair. Quiconque peut lire state.db depuis le nœud du plan de contrôle peut extraire la clé privée de votre CA et forger des certificats que tout votre cluster fait confiance.

Cet article couvre comment nous avons migré la clé privée de la root CA minicloud dans le moteur de secrets PKI de HashiCorp Vault, avec le même certificat de CA pour que rien d'autre n'ait à changer — aucune reconfiance, aucune interruption, aucun changement sur nos 43 ressources Certificate.