Hashicorp dévoile sa vision d’une architecture zero-trust

Zero-trust : un nouveau segment pour Hashicorp

L’éditeur a très bien compris qu’il pouvait se positionner sur la notion d’architecture zero-trust. Pour cela, il compte sur des « piliers », selon les dires d’Armon Dadgar, cofondateur et CTO d’Hashicorp, lors de l’événement Hashiconf Europe 2022.

Il faut dire que le CTO observe beaucoup de confusion sur le marché autour de ce concept.

« Nous entendons beaucoup de monde parler de zero-trust, mais le problème c’est que la plupart des gens ne savent pas ce que c’est réellement », déclare-t-il. « Quand nous leur demandons de définir la notion, certains nous répondent : “nous ne savons pas, mais nous l’adoptons”… Il faut donc expliquer ce que c’est concrètement », indique-t-il.

En 2021, dans le cadre d’un partenariat, Microsoft et Hashicorp exposaient leur définition commune de l’approche zero-trust. « Le modèle zero-trust… signifie que tous les points de contact d’un système – identités, appareils et services – sont vérifiés avant d’être considérés comme dignes de confiance », évoquaient les porte-parole des deux entreprises auprès de SearchITOperations [Propriété de Techtarget, également propriétaire du MagIT].

Les deux entreprises discutaient là du lien entre le gestionnaire d’accès Boundary et l’IDP Azure AD. En clair, la vision se limitait à une portion de l’architecture.

Au cours de sa conférence Hashiconf Europe, l’éditeur a revu sa copie d’une telle architecture sans confiance. Il entend désormais coupler Vault, Consul, et Boundary dans le but de couvrir toute la chaîne excepté la gestion du SSO, dominée par quelques acteurs, dont Okta et Microsoft Azure.

« En matière d’authentification unique, il y a différentes approches et produits disponibles », indique Armon Dadgar. « Au cœur de tout cela, il s’agit d’avoir un répertoire de tous les utilisateurs, d’avoir la possibilité de lier un usager à un groupe et certains protocoles de chiffrement pour vérifier son identité, comme SAML, Kerberos, OIDC, etc. », ajoute-t-il.

 En revanche, il y a un problème « moins bien compris », selon le CTO. « Comment bien gérer l’identité des machines et des applications ? », s’interroge Armon Dadgar.

Vault s’adapte à la gestion dynamique de clés et de certificats

C’est là qu’intervient Vault, selon lui. L’outil peut gérer les secrets statiques, qui restent au fond d’un coffre-fort d’un KMS et d’un HSM, mais aussi générer des clés de manière dynamique pour accéder à différentes applications et services cloud.

Hashicorp est allé un cran plus loin en permettant de gérer depuis Vault les opérations de chiffrement associées à certains services. C’est ce que l’éditeur a fait pour Kubernetes et Snowflake dans Vault 1.11.

Pour assurer la confiance entre les microservices, l’éditeur a décidé de supporter le protocole OIDC (OpenID Connect).

« On nous a beaucoup réclamé la possibilité d’utiliser un jeton OIDC entre différents services », commente Armon Dadgar. « Vault peut donc agir en tant que serveur OIDC. Il produit des informations d’identification et permet d’effectuer des appels entre différents services que nous pouvons ensuite authentifier de manière sécurisée ».

« Vault peut donc agir en tant que serveur OIDC. Il produit des informations d’identification et permet d’effectuer des appels entre différents services que nous pouvons ensuite authentifier de manière sécurisée ».

Dans la même veine, Hashicorp a amélioré le moteur de gestion de certificats de son coffre-fort. « Il y a eu beaucoup de demandes pour que nous améliorions la manière de gérer les certificats, de les générer, de les renouveler », explique le CTO. Enfin, l’éditeur a rendu possible l’utilisation de son système MFA, pour se connecter non seulement à HCP Vault, mais également à Vault Open Source.

Hashicorp entend également renforcer l’intégration entre Vault et Consul, son service mesh. « Consul est idéal pour la gestion des connexions de machine à machine », avance Armon Dadgar.

« Nous voulons améliorer l’intégration par deux moyens », poursuit-il. « Le premier consiste à bâtir un moteur dédié à la gestion des secrets qui nous permet de gérer les authentifications dynamiques dans Consul depuis Vault. Le deuxième vise à faire de Vault l’autorité racine pour Consul ». Par exemple, avec Consul 1.12, l’éditeur a introduit une meilleure rotation des certificats TLS dans Consul sur Kubernetes et la possibilité de gérer les tokens ACL grâce à Vault.

Un nouveau modèle de fédération de clusters pour Consul

Surtout, Hashicorp entend modifier le modèle de fédération de clusters dans la version 1.13 de Consul, disponible « plus tard cette année ».

Au lieu d’un modèle de fédération WAN où les clusters sont maintenus par les mêmes opérateurs, Hashicorp veut donner un moyen de partitionner et d’isoler la gestion des clés, des politiques et des mises à jour.

Avant de poser un problème de sécurité, cette centralisation complique le travail des équipes qui peuvent être dans des frontières réseau différentes, selon l’éditeur.

Avec l’appairage de clusters (cluster peering en VO), chaque cluster est voué à devenir autonome grâce à un modèle actif/actif. Ce sont les administrateurs des clusters Consul qui doivent explicitement décider quel cluster peut se connecter en mTLS à tel autre cluster, peu importe les frontières réseau impliquées.  

Pour cela, il faut générer des jetons d’appairage à partager entre clusters, établir les connexions, puis rendre disponibles les services chapeautés par chaque cluster.

Idéalement, cette approche permet de maîtriser le routage du trafic entre services qui animent une application.

Cela ne règle pas les problématiques d’administration qui apparaissent quand le nombre de maillages de services se multiplie. Consul 1,11 a introduit des partitions d’administration. Ces partitions sont des tenants isolés dans un plan de contrôle commun à plusieurs clusters Consul. En clair, il est possible d’accorder aux équipes applicatives de conserver la propriété des ressources sous-jacentes (VM ou clusters Kubernetes) utilisées pour exécuter leurs services.

Consul 1,13 étendra cette capacité à plusieurs datacenters. Cela tombe bien, la version managée du service mesh HCP Consul, jusqu’alors accessible depuis AWS, entrera en disponibilité générale sur Azure le 15 juillet prochain.

« Quand nous observons les patterns de déploiement des équipes de développement, nous remarquons que beaucoup d’entre elles gèrent leurs propres clusters Kubernetes », affirme Armon Dadgar. « Ces équipes veulent pouvoir contrôler les communications entre les applications, le fonctionnement du routage, les règles de leur gateway API, etc. L’on ne veut pas nécessairement qu’une équipe réseau centralisée définisse et administre tous ces points ».

« Avec le peering de clusters, chaque équipe peut gérer son propre cluster. Elles n’ont pas forcément à se faire confiance, mais elles peuvent obtenir un appairage lâche et partager certains sous-ensembles de leurs services ».

Une fois combinés, le peering de clusters et les partitions d’administration doivent faciliter l’application d’une approche sans confiance. « Avec le peering de clusters, chaque équipe peut gérer son propre cluster. Elles n’ont pas forcément à se faire confiance, mais elles peuvent obtenir un appairage lâche et partager certains sous-ensembles de leurs services », remarque Armon Dadgar.

Voilà donc la solution proposée par l’éditeur pour améliorer la connexion et la sécurisation des « communications entre machines ». Il reste ce que le CTO d’Hashicorp nomme « la connexion des humains aux machines ».

Boundary abstrait la gestion des accès

En ce sens, l’éditeur a annoncé la disponibilité de la bêta publique de HCP Boundary, la version managée du projet open source éponyme.

Ce proxy doit éviter l’utilisation d’authentifiants statiques (SSH, mot de passe VPN, etc.) pour se connecter à des applications et des middlewares résidant derrière les VPC ou dans les data centers privés des entreprises. Selon l’éditeur, le gestionnaire d’accès est conçu pour supporter la nature changeante du cloud. Pour cela, Boundary base les autorisations sur le rôle et des services logiques en masquant la gestion des adresses IP, des connexions et des mots de passe en arrière-plan.

Sous le capot, un plan de contrôle gère les utilisateurs, les cibles (les applications) et les politiques d’accès à l’aide de Terraform. Quand un usager veut se connecter à un service, ce control plane assigne des nœuds de travail, des proxys stateless afin d’établir la connexion au réseau et au service en question.

« Il s’agit de proposer une feuille de route claire pour implémenter une architecture sans confiance ».

Boundary peut s’intégrer à Vault afin de générer des identifiants valables le temps d’une session. Toutes les sessions sont également répertoriées dans la console d’administration du gestionnaire d’accès. Depuis peu, Hashicorp a amélioré l’observabilité afin de suivre la santé du service et assurer l’auditabilité du service.

Toutefois, cette combinaison d’un IDP du marché avec Vault, Consul et Boundary (ou leur version managée) repose sur des fonctionnalités en développement ou disponibles en bêta.

Ce n’est pour l’instant qu’une vision, selon les dires d’Armon Dadgar. Hashicorp anticipe l’adoption future de l’approche zero-trust tout en essayant de plier les barrières à l’adoption.

« Il s’agit de proposer une feuille de route claire pour implémenter une architecture sans confiance », estime le CTO. « Je pense que c’est un grand changement de paradigme pour la sécurité, mais beaucoup de gens ont du mal à le définir et à le mettre en place ».