Comment Zendesk a automatisé la rotation de ses CA racines

À la recherche d’un usage pas commun des chemins de certification ? Demandez à Zendesk.

L’usage en question a consisté à inclure, dans lesdits chemins, plusieurs autorités racines de certification mTLS. Le contexte : un projet destiné à automatiser la rotation de ces dernières dans un environnement Kafka.

mTLS est implémenté sur cet environnement depuis environ trois ans. Zendesk y exploite, pour l’authentification sur des data stores, un outil interne nommé Temp Auth. Celui-ci comprend un conteneur init qui fournit des authentifiants aux pods selon les ressources personnalisées associées aux projets. Divers opérateurs Kubernetes provisionnent les data stores, configurent l’accès et peuplent les authentifiants dans le gestionnaire de secrets Vault.
Le conteneur init récupère les authentifiants dans le gestionnaire en fonction des data stores que déclare le projet, puis les communique aux conteneurs d’applications. Il gère aussi, lorsque l’expiration des authentifiants approche, leur renouvellement ou l’éviction des pods.

Dans la config de Zendesk, les certificats client et broker proviennent d’une même autorité interne, créée par l’intermédiaire du moteur PKI de Vault. Vu les délais de propagation, on ne pouvait imaginer une rotation instantanée. La démarche mise en place implique donc un basculement progressif, fondé sur une autorité principale (émettrice des certificats) et des secondaires.

Un usage ad hoc des chemins de certification

Gérer le processus de rotation exige un état partagé : tous les systèmes doivent avoir connaissance de l’autorité principale et, le cas échéant, savoir à quelle(s) autorité(s) secondaire(s) faire confiance. Pour cela, Zendesk utilise une entrée Consul de type clé-valeur (kafka-pki/root). Elle contient les chemins Vault des autorités primaire et secondaire(s).

Sur cette base, on peut construire un « Keystore » et un « Truststore » Kafka. Le premier contient le certificat client (et la clé privée). Le second contient tous les émetteurs (principal et secondaire)… et permet ainsi de communiquer avec tout broker, peu importe si son certificat provient de l’une ou l’autre autorité.

Depuis sa version 1.11, sortie mi-2022, Vault permet d’associer de multiples autorités à un même moteur PKI. Une API permet de définir l’émetteur par défaut. À partir de là, comment faire connaître le second ? Les clients pourraient interroger ladite API pour récupérer une liste, sauf que Temp Auth ne comprend pas la logique multiémetteur.

Face à cet obstacle, Zendesk s’est tourné vers les chemins de certification qu’émet Vault. Initialement, il fut question d’exploiter une autorité de certification intermédiaire qui aurait elle-même deux autorités parentes. De cette façon, peu importe l’autorité parente à laquelle on fait confiance, on fait aussi confiance à l’autorité intermédiaire.

Finalement, on a délaissé le principe de la chaîne… pour intégrer les deux autorités racines directement dans le chemin de certification, utilisé en tant que Truststore. Cela fonctionne parce que clients et brokers s’appuient sur le même émetteur. Temp Auth, lui, ne perçoit pas ce qui se joue : il génère simplement des certificats TLS standards.

Un process d’abord semi-automatisé

Dans l’implémentation mTLS d’origine, la rotation des autorités racines était semi-automatique (un ingé intervenait sur Terraform). Un choix assumé de par la relative rareté du processus. Des bugs dans le provider Terraform pour Vault ont toutefois poussé à l’automatisation. Une tâche s’exécute périodiquement pour :

– Lister toutes les autorités émettrices dans /kafka-pki en plaçant les plus anciens d’abord, puis garder les trois premiers

– S’il en existe moins de trois, en créer un et reprendre le processus à l’étape 1

– Assigner les trois autorités aux variables previous, current et next

– Si next est plus ancien que la variable ROTATION_TIME, créer un nouvel élément et réarranger les autres (le nouvel élément devient next, l’ancien next devient current, etc.)

– Définir le chemin de certification des trois émetteurs à [previous, current, next]

– Dans Vault, désigner current comme l’émetteur primaire (si ce n’est pas déjà le cas)

– Supprimer les émetteurs qui ne figurent pas dans [previous, current, next]

En cas de crash, peu importe l’étape, le processus peut reprendre, souligne Zendesk. Et à aucun moment, il ne laisse Vault dans un état indésirable.

Pour effectuer la migration, Zendesk a introduit le nouvel endpoint multiémetteur en tant qu’émetteur secondaire (secondary_issuer) dans son système Consul. Il a modifié le conteneur init afin qu’il fasse confiance à toutes les entrées des chemin de certification. Les clients feraient ainsi eux-mêmes confiance à toutes les autorités émettrices (l’ancienne et les trois nouvelles). Une fois l’endpoint promu émetteur principal (primary_issuer) et la propagation effectuée, les clients font tous confiance aux mêmes autorités racines, qu’importe le conteneur init utilisé.

Illustration principale © Настя Шевчук – Adobe Stock