Cas 3. Norvent : une plateforme Kubernetes multi-équipes
Contexte¶
Norvent exploite une plateforme conteneurisée interne pour vingt-cinq équipes : trois clusters, développement, recette et production, hébergeant environ quatre cents services. Les communications entre services passent par un maillage qui exige des certificats mutuels, aujourd'hui émis par une autorité interne artisanale dont personne ne connaît plus la procédure de renouvellement. Les secrets applicatifs sont pour l'essentiel des objets natifs du cluster, créés à la main et jamais tournés.
Contraintes¶
Les équipes déploient elles-mêmes, sans intervention de la plateforme. Les trois clusters ont des cycles de vie indépendants et sont régulièrement reconstruits. Une partie des applications sont des progiciels que les équipes ne peuvent pas modifier. Et la plateforme veut éviter d'imposer un outil de plus à apprendre.
Risques principaux¶
La multiplication des points de confiance : trois clusters signifient trois plans de contrôle auxquels Vault devra faire confiance pour attester des identités.
La copie des secrets dans les objets natifs, dont le chapitre 38 a montré qu'elle sort les valeurs de la barrière.
La reconstruction régulière des clusters, qui invalide les configurations liées à leurs autorités.
Et le maillage sans PKI gouvernée, qui est une panne annoncée le jour où un certificat d'autorité expirera.
Architecture proposée¶
Vault reste en dehors des clusters, sur des machines dédiées, pour les raisons de frontière de confiance du chapitre 38 : les administrateurs de la plateforme ne doivent pas devenir de fait administrateurs des secrets de vingt-cinq équipes, et la reprise ne doit pas dépendre du cluster qu'elle sert.
Une méthode d'authentification par cluster, montée sur des chemins distincts, chacune configurée avec l'autorité et l'émetteur de son cluster. C'est le point le plus important du cas : la confiance s'accorde à un plan de contrôle, et monter une méthode unique pour trois clusters reviendrait à accepter qu'une compromission du cluster de développement atteste des identités de production. Les rôles lient compte de service et namespace, avec l'audience exigée.
La consommation suit une règle d'aiguillage publiée : injecteur avec gabarits par défaut, pour tout ce qui est credential dynamique, certificat ou clé ; opérateur de synchronisation autorisé sur un périmètre écrit, pour les progiciels non modifiables et les valeurs de configuration peu sensibles, avec chiffrement du magasin activé et revue trimestrielle.
La PKI du maillage devient une intermédiaire dédiée, distincte de celle des services externes, avec un rôle par namespace contraignant les noms émis. Les certificats sont courts et renouvelés par l'injecteur : ce que le chapitre 17 appelait la vraie défense, les durées plutôt que la révocation.
Choix techniques argumentés¶
Une méthode par cluster coûte trois configurations au lieu d'une et supprime une classe entière d'attaques par rebond entre environnements. Le surcoût est marginal, l'automatisation le rend invisible, et la reconstruction d'un cluster ne touche alors qu'une seule configuration.
L'aiguillage publié, plutôt qu'un mode unique imposé, répond à la contrainte des progiciels. Refuser toute copie dans le cluster rendrait le dispositif inapplicable pour une partie des services et pousserait leurs équipes à créer des objets natifs à la main, ce qui est strictement pire. Autoriser la copie sous conditions écrites préserve la règle là où elle compte.
La PKI dédiée au maillage isole un usage à très fort volume : ses rythmes d'émission, ses purges et ses éventuels incidents ne touchent pas les certificats des services exposés.
Alternatives écartées¶
Vault dans le cluster de production : rejeté sur la frontière de confiance et la circularité de reprise. Un Vault par cluster : trois installations pour un besoin qui n'exige pas l'isolement de destin, et une gouvernance fragmentée. L'opérateur de synchronisation généralisé : simple, confortable, et il sortirait de la barrière l'intégralité des secrets de quatre cents services. Le maillage avec sa propre autorité : c'est l'existant, dont l'absence de gouvernance est le problème à résoudre.
Compromis assumés¶
Le périmètre de synchronisation est une brèche assumée dans le modèle : les valeurs concernées vivent hors barrière, et la révocation n'y reprend rien. Le compromis est écrit, borné à une liste de services, et revu chaque trimestre avec la question explicite de savoir si chaque entrée s'y trouve encore à bon droit.
Second compromis : Vault devient une dépendance de démarrage pour quatre cents services, ce qui élève l'exigence de disponibilité. Le cluster passe à cinq nœuds et la supervision hérite d'un tableau de bord dédié.
Stratégie de récupération¶
Vault hors cluster simplifie la reprise : les clusters se reconstruisent depuis leur propre outillage, et il suffit de reconfigurer la méthode d'authentification correspondante avec la nouvelle autorité. Une opération d'une dizaine de minutes, à condition qu'elle figure dans la procédure de reconstruction du cluster, ce que Norvent avait oublié de prévoir et qui constitue l'apport principal de l'étude.
Questions de discussion¶
- La plateforme propose de monter une méthode unique pour les trois clusters, en arguant que le cluster de développement n'héberge rien de sensible. Rédigez votre objection en trois phrases, avec le scénario d'attaque correspondant.
- Comment décideriez-vous qu'un service a le droit de figurer dans le périmètre de synchronisation ? Proposez trois critères vérifiables et le processus de révision.
- Un cluster est reconstruit un vendredi soir et personne ne reconfigure la méthode d'authentification. Décrivez ce que voient les équipes, dans quel ordre, et ce que la supervision aurait dû montrer.