Kubernetes : les choix de Michelin pour la gestion des secrets

Comment gérer les secrets dans un environnement de conteneurs ?

Le CTO Asie de Michelin a récemment relaté des démarches entreprises dans ce domaine. Elles ont fait suite au déploiement d'une landing zone chez Alibaba Cloud à l'été 2024.

Avant d'entamer ces démarches, Michelin disposait de SOPS. Cet outil maison, développé en 2023, chiffre les fichiers de configuration. Il réduit ainsi le degré d'exposition des secrets qui y sont intégrés. Mais il ne résout pas les problèmes liés à leur exploitation. Parmi eux :

• Fuites potentielles lors du transfert entre le coffre-fort de secrets et les développeurs (risque élevé)
• Stockage des clés SOPS privées dans des projets GitLab (risque moyen)
• Injection de secrets dans des fichiers de configuration en clair lors de l'exécution (risque modéré)

Michelin a évalué trois approches palliatives autour de HashiCorp Vault :

• Récupérer les secrets dans Vault, les stocker sous forme de secrets Kubernetes, puis les injecter dans les pods d'applications en tant que variables d'environnement
• Intégrer, dans chaque pod d'application, un sidecar qui récupère les secrets dans Vault et les écrit dans des fichiers de configuration au sein du pod
• Pour les applications qui utilisent le framework Spring Cloud, une récupération directe des secrets dans Vault, sans jamais les stocker dans l'environnement Kubernetes

Concernant le niveau de sécurité et de conformité

La première approche, dite External Secrets Operator, présente un risque de compromission des secrets Kubernetes. Ceux-ci, en plus d'être accessibles notamment via le portail associé au Kubernetes managé d'Alibaba, sont disponibles au niveau du namespace. Les secrets étant stockés dans etcd, il faut chiffrer ce dernier pour la compliance.

La deuxième approche, dite Vault Agent Injector, réduit le risque d'exposition des secrets (pas de stockage persistant dans le cluster). Elle n'élimine toutefois pas la présence de secrets déchiffrés dans les configurations locales.

La troisième approche, dite Spring Cloud Vault, diminue encore plus le risque d'exposition, les secrets n'étant pas stockés dans Kubernetes. L'intégration directe avec Vault permet par ailleurs un audit détaillé. Et la gestion du contrôle d'accès peut se faire par authentification au niveau application plutôt que par l'intermédiaire du RBAC ou des comptes de service Kubernetes.

Concernant les performances et la complexité

External Secrets Operator est facile à implémenter (exploitation des ressources et des patterns Kubernetes standards) et requiert peu de changements au niveau des applications. Son démarrage est rapide (les secrets sont disponibles au lancement du pod), il consomme peu de ressources (pas de conteneurs supplémentaires) et passe bien à l'échelle (utilisation du plan de contrôle Kubernetes). La mise à jour de secrets peut néanmoins exiger le redémarrage de pods ou le rechargement d'apps. L'approche est, plus globalement, mieux adaptée aux secrets statiques que dynamiques.

Vault Agent Injector est plus complexe à implémenter (nécessite de configurer sidecars et annotations). Il peut exiger des changements dans le code des applications afin de lire des secrets depuis de nouveaux chemins ou variables d'environnement. Il induit par ailleurs un léger délai au démarrage (récupération des secrets par le sidecar) et une consommation de ressources plus importante (un sidecar par pod). Mais avec lui, on peut faire tourner et renouveler les secrets sans relancer les applications.

Spring Cloud Vault nécessite aussi des modifications de code (intégration de bibliothèques), en parallèle d'une gestion de dépendances. Lui aussi implique un délai de démarrage (l'application récupère les secrets). L'usage de ressources supplémentaires est en revanche minimal et le passage à l'échelle se fait avec les instances d'applications. L'intégration directe avec Vault garantit une bonne gestion des secrets dynamiques.

SOPS laissé dans la boucle

Si une application est développée avec Spring et qu'on peut la modifier pour intégrer Spring Cloud Vault, on préférera cette approche.

Sinon, dans le cas où il est acceptable de recourir à des secrets Kubernetes, on utilisera External Secrets Operator.

Autrement, on se servira de Vault Agent Injector sous deux conditions : accepter la surcharge et être en mesure de modifier l'app.

Dans les autres cas, Michelin préconise d'utiliser SOPS.

Illustration générée par IA