Cas 2. Tessella : la plateforme de livraison à l'échelle
Contexte¶
Tessella est un éditeur de cent vingt personnes, organisé en quatorze équipes produit autonomes. Chaque équipe possède ses dépôts, ses pipelines et ses environnements ; la plateforme interne fournit l'outillage commun. Environ soixante-dix pipelines s'exécutent quotidiennement, déployant vers deux fournisseurs cloud et une infrastructure interne. Les secrets sont aujourd'hui stockés dans les variables protégées de la forge, dupliqués d'un projet à l'autre, et personne ne sait combien il y en a.
La demande vient de l'équipe plateforme : supprimer les secrets statiques de la chaîne de livraison, sans devenir le goulet d'étranglement de quatorze équipes.
Contraintes¶
L'autonomie des équipes est un principe organisationnel, pas une tolérance : une architecture qui exigerait un ticket pour chaque nouveau secret sera contournée en une semaine. Les rythmes de livraison sont élevés. Les compétences en sécurité sont inégales selon les équipes. Et la plateforme compte quatre personnes : tout ce qui n'est pas automatisé ne sera pas fait.
Risques principaux¶
La prolifération des policies est le risque numéro un : quatorze équipes qui demandent chacune leurs droits produisent en un an deux cents policies dont plus personne ne connaît la portée.
Vient ensuite le risque de la chaîne de livraison elle-même, qui devient le chemin le plus court vers la production : qui contrôle un fichier de flux de travail contrôle ce que le pipeline obtient.
Enfin, l'état des outils d'infrastructure accumule les secrets manipulés, souvent depuis des années.
Architecture proposée¶
Un Vault central unique, exploité par la plateforme, avec un cloisonnement par équipe. Le choix du mécanisme de cloisonnement est l'arbitrage principal du cas.
Les namespaces de l'édition Enterprise permettent une administration déléguée, chaque équipe créant ses rôles et ses policies sans passer par la plateforme. L'édition Community impose au contraire que la plateforme reste l'unique administratrice, avec des montages et des préfixes par équipe. La recommandation dépend du chiffre que la direction seule peut poser : le coût de la licence contre le coût d'un goulet d'étranglement de quatre personnes pour quatorze équipes. Un point de méthode conditionne ce chiffrage : la facturation de l'édition Enterprise repose sur un comptage de clients, les identités distinctes qui s'authentifient sur une période, et non sur le nombre de nœuds ou de requêtes. Une plateforme à quatre cents services conteneurisés compte donc autrement qu'une installation à quinze applications, et l'ordre de grandeur se relève dans les métriques avant d'entrer en négociation.
Dans les deux cas, la même colonne vertébrale.
L'authentification : identité fédérée pour les humains, adossée au fournisseur d'identité de l'entreprise, avec des groupes externes qui portent les droits ; une méthode par plateforme de CI, avec des rôles liés au dépôt et à la référence ; les identités de plateforme pour les charges déployées.
La structure en code : montages, rôles et policies décrits dans un dépôt, revus par pairs, appliqués par un pipeline dédié. La structure, jamais les valeurs.
Le catalogue : la plateforme ne traite pas des demandes, elle publie des rôles types, application avec base de données, application avec chiffrement, pipeline de préproduction, pipeline de production, qu'une équipe instancie par une demande de fusion.
Le templating d'identité, enfin, qui permet à une policy unique de servir toutes les équipes en résolvant le nom de l'entité ou de son groupe dans les chemins.
Choix techniques argumentés¶
Le catalogue de rôles est le cœur de la réponse à la contrainte d'autonomie : il transforme une demande de droits en contribution à un dépôt, revue en quelques minutes plutôt qu'arbitrée en réunion. Les équipes gagnent l'autonomie, la plateforme garde le contrôle du catalogue, et la sécurité gagne l'uniformité : quatorze applications configurées de la même manière se revoient et se corrigent ensemble.
Le templating d'identité réduit le nombre de policies d'un ordre de grandeur. Une règle unique remplace quatorze règles quasi identiques, et les nouveaux arrivants héritent des droits par leur appartenance dans le fournisseur d'identité, sans qu'aucun objet Vault ne soit créé.
La séparation des rôles de CI par référence, branche principale pour la préproduction et étiquette signée pour la production, donne à la chaîne de livraison une frontière que les protections du dépôt suffisent à défendre.
Alternatives écartées¶
Un Vault par équipe : quatorze installations à exploiter, sauvegarder, mettre à jour et auditer, pour un besoin de cloisonnement qui ne va pas jusqu'à l'isolement de destin. Le coût est prohibitif et la sécurité globale baisse, faute de moyens pour tenir chaque instance à niveau.
Les secrets dans les variables protégées de la forge : c'est l'état existant, dont la duplication et l'absence d'inventaire sont le problème.
Une administration entièrement centralisée sans catalogue : la plateforme devient le goulet, les équipes contournent, et la sécurité se dégrade par un chemin détourné.
Compromis assumés¶
En édition Community, la plateforme reste administratrice de tout : les équipes proposent, la plateforme applique. Compromis acceptable tant que le délai de traitement d'une demande reste de l'ordre de l'heure, et intenable au-delà.
Le templating rend les policies plus difficiles à lire pour un non-initié, ce qui se compense par des tests automatisés vérifiant, pour chaque rôle type, ce qui est accordé et ce qui est refusé.
Enfin, la migration des soixante-dix pipelines s'étale sur plusieurs mois, période pendant laquelle deux modèles coexistent.
Stratégie de récupération¶
Un cluster de trois nœuds, sauvegardes automatisées, RPO d'une heure et RTO de deux heures, standard pour cette taille.
La spécificité du cas tient à la reprise des équipes : une restauration ramène l'état des rôles et des policies au dernier snapshot, mais le dépôt de description en code fait autorité. La procédure inclut donc une réapplication du code après restauration, qui réaligne l'instance sur l'intention plutôt que sur un instantané.
Questions de discussion¶
- Chiffrez, avec vos propres hypothèses, le coût d'un goulet d'étranglement de quatre personnes pour quatorze équipes, et comparez-le au coût d'une licence permettant la délégation. Quelles données demanderiez-vous à la direction pour trancher ?
- Une équipe demande un droit qui n'existe pas au catalogue. Décrivez le processus, de la demande à la mise en production, et le critère qui décide entre exception et nouvelle entrée au catalogue.
- Le templating d'identité fait dépendre les droits de l'appartenance dans le fournisseur d'identité. Quels nouveaux risques cela crée-t-il, et quels contrôles ajouteriez-vous ?