5 articles tagués avec « security »

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.

La plupart des architectures d'identité d'entreprise n'ont pas commencé comme ce qu'elles sont aujourd'hui. Elles ont démarré en 1999 avec Active Directory, ont accumulé des intégrations LDAP au cours de la décennie suivante, et sont désormais à mi-chemin d'une migration vers l'identité cloud via Microsoft Entra ID — portant le poids de chaque couche qui l'a précédée.

Nous avons construit notre plateforme de zéro. Nous n'avons jamais eu de domaine on-premises. Nous n'avons jamais configuré LDAP. Nous avons sauté directement à la pile de protocoles que les entreprises passent des années et des sommes importantes à essayer d'atteindre. Cet article explique ce que nous avons choisi, pourquoi, et comment l'architecture d'identité résultante se compare au standard d'entreprise.

OpenShift Container Platform est une distribution Kubernetes d'entreprise avec des choix affirmés. Mon cluster minicloud est une pile k3s de 5 nœuds assemblée composant par composant à partir de projets CNCF. Après avoir traversé la construction complète — GitOps, observabilité, secrets, registre, OIDC, ingress, réplication de stockage, tests de chaos, correctifs de sécurité, mises à jour — je peux dire avec une certaine précision quelle est réellement la différence.

Ce n'est pas qu'OpenShift en fait plus. C'est qu'OpenShift a déjà fait chaque choix que vous auriez à faire vous-même, a empaqueté ces choix en une unité versionnée, testée et supportée, et les a imposés au niveau de l'architecture. Que ce soit un avantage ou une contrainte dépend entièrement de ce que vous cherchez à faire.

Les fournisseurs Kubernetes managés font paraître le patch de sécurité simple. Vous activez l'auto-mise à jour sur GKE, vous cliquez « mettre à jour le groupe de nœuds » sur EKS, et la CVE disparaît. Ce qui se passe réellement, c'est que le fournisseur patche l'image OS, remplace le nœud, valide le binaire, et restaure vos workloads — le tout dans le temps qu'il faut pour rafraîchir la console AWS.

Sur un cluster auto-géré, rien de cela n'est automatique. Vous possédez l'OS. Vous possédez le runtime. Vous possédez les images de base. Vous possédez les versions de charts Helm. Et quand une CVE tombe, vous possédez la décision sur la couche où elle vit et le mécanisme qui la fermera.

Cet article documente les cinq couches de patching sur minicloud — un cluster k3s de 5 nœuds sur des ThinkPads bare-metal — ce qui est automatisé, ce qui requiert une PR, et où étaient les manques et comment ils ont été comblés.