Nous avons déjà présenté sur ce blog l’outil Vault de Hashicorp, son fonctionnement en mode PKI, son intégration avec AWS ou avec Kubernetes.

Cette fois-ci nous allons nous intéresser à une autre fonction de Vault : Le contrôle des accès SSH aux serveurs de votre infrastructure.

Cette fonctionnalité, et toutes ses déclinaisons, est fournie par le Secret Engine SSH.

Version utilisée : 1.0.0

Préambule : Comment on fait sans Vault déjà ?

Le problème de la gestion des accès à une infra Linux s’est posé bien avant que Vault n’existe (au moins une bonne dizaine d’années avant même). La solution classique et peu coûteuse qu’on pourrait proposer de nos jours serait composée des éléments suivants :

• Un utilisateur disposant sur son poste de clés SSH qui lui permettent d’accéder à l’infrastructure

• Un point d’entrée contrôlé et sécurisé au réseau interne, le plus souvent un bastion SSH ou un point d’accès VPN

• Depuis ce point d’entrée, un accès direct (avec quelques traversées de firewalls éventuelles) aux serveurs de l’infrastructure

• Sur les serveurs :
  • un service OpenSSH bien configuré, sécurisé et audité
  • des droits par clé d’utilisateur, gérés à travers des fichiers authorized_keys
  • un outil d’Infrastructure as Code tel qu’Ansible en mode pull ou Puppet chargé de maintenir les fichiers authorized_keys à jour

Ce qui nous donnerait l’organisation suivante :

Cette organisation présente un certain nombre d’avantages :

• elle utilise des composants qui sont déjà utiles en eux-mêmes dans votre infra :
  • le bastion est un excellent pattern pour accéder à votre infrastructure
  • la gestion de la configuration de vos serveurs est très utile au delà de la gestion des authorized keys et vitale passé certaines échelles

• elle ne nécessite pas d’expertise supplémentaire, c’est une conséquence du point précédent

• l’utilisation d’authorized keys offre un contrôle assez fin sur ce que peut faire l’utilisateur une fois connecté

• un serveur OpenSSH bien configuré et auditable grâce à l’envoie des logs de connexion hors de la machine, fournit déjà un niveau de sécurisation satisfaisant pour beaucoup d’usages

Malheureusement une telle organisation peut devenir complexe à maintenir quand il faut gérer les accès d’un grand nombre de personnes sur un grand nombre de serveurs :

• une logique de regroupement des machines par groupes et des différents accès sous forme de rôles qu’on peut attribuer aux utilisateurs devient nécessaire

• cette logique doit alors être implémentée et maintenue dans le code d’infrastructure

• de plus les modifications du code d’infrastructure doivent être contrôlées avec beaucoup de finesse (pour autoriser les utilisateurs à attribuer certains rôles et pas d’autres par exemple)

Certaines solutions plus élaborées existent alors pour adresser cette complexité, on peut par exemple citer la solution open-source Teleport de Gravitational qui apporte aussi une réponse intéressante à la question de l’auditabilité.

On peut toutefois aller plus loin tout en continuant à utiliser les fonctionnalités standard d’OpenSSH et en limitant le nombre de composants de l’infrastructure grâce aux fonctionnalités offertes par Vault !

Vault comme passage obligé de votre authentification

Vault va s’insérer dans notre infrastructure comme un passage obligé. Le client devra nécessairement obtenir auprès de l’API du serveur Vault des accès qui lui permettront ensuite d’accéder au reste des serveurs de l’infrastructure, s’il y est autorisé par Vault.

L’organisation devient donc la suivante :

Pour obtenir ces accès le client va interagir avec l’API du Secret Engine SSH de Vault dont la logique de fonctionnement respecte la “philosophie” de Vault :

• fournir des accès limités en termes de périmètre

• fournir des accès limités dans le temps

Ce seront donc des accès générés à la demande et temporaires qui seront fournis à l’utilisateur, la question qui se pose est donc la suivante : Comment faire en sorte que les accès fournis par Vault au client soient acceptés par les serveurs ?

Excellente question, la réponse est très simple : ça dépend !

Il y a en fait deux types d’accès que peut fournir Vault, qui ont chacun leur mode de validation côté serveurs :

• Les accès de type One Time Password (OTP)

• Les accès de type certificat SSH

(et un troisième type déprécié dont on ne parlera pas)

Dans les exemples que nous donnerons par la suite, nous partirons du principe que nous communiquons avec un serveur Vault qui a été préalablement unsealed avec un token d’accès qui a suffisamment de droit pour faire les actions. Il peut par exemple s’agir d’un token d’administration qui dispose de droits de modification suffisamment  large sur notre Secret Engine, pour tester chez vous le root token fera l’affaire (mais c’est une très mauvaise pratique de l’utiliser en production !).

Nous considérerons également que le Secret Engine SSH a été activé sur le path /ssh de l’API (son path par défaut).

En plus des liens vers la documentation Vault, vous pouvez trouver des informations sur ces concepts dans l’article “La PKI Vault sur le grill”.

Note pour la suite : un des objectifs de l’utilisation de Vault dans cet article est d’éliminer le besoin de répercuter sur les machines les changements dans le référentiel des utilisateurs et de leurs accès à l’infra. Pour que cela soit possible nous considérons donc que les comptes sont non nominatifs sur les serveurs (par exemple : admin, web, readonly, …).

C’est un choix technique qui n’est pas anodin, car ce qu’on gagne en facilité de configuration des serveurs on risque de le perdre en termes de traçabilité de l’utilisation de l’infrastructure. En effet il devient bien plus difficile et coûteux en terme d’outillage d’identifier quelle personne est à l’origine de chaque action effectuée avec un compte technique non nominatif.

Une solution pour continuer à utiliser des comptes nominatifs serait d’utiliser un annuaire LDAP comme référentiel d’utilisateurs. Les serveurs Linux disposent en effet d’une intégration native qui leur permet d’utiliser un annuaire LDAP comme base de comptes utilisateurs.

1ère solution : Les accès de type One Time Password

Dans ce mode, Vault va générer un mot de passe à usage unique avec lequel l’utilisateur pourra se connecter au serveur pour lequel il a demandé l’accès. Lorsqu’il tentera de se connecter au serveur, ce dernier ira interroger Vault pour vérifier la validité de ce mot de passe.

Configuration d’un accès en mode OTP

Une fois le Secret Engine SSH activé c’est assez simple de mettre en place un accès en mode OTP.

Nous allons créer ce qu’on s’appelle un role dans le Secret Engine, ce role défini un ensemble de droits d’accès qu’une personne pourra demander.

Un role de type OTP peut se créer de la façon suivante :

$ vault write ssh/roles/otp_web - <<'EOH'
{
   "key_type": "otp",
   "default_user": "web",
   "allowed_users": "web",
   "cidr_list": "10.1.42.0/24"
}
EOH

Ici nous avons créé un role “otp_web” qui permettra aux personnes y ayant accès d’obtenir un mot de passe à usage unique ("key_type": "otp"), pour se connecter aux machines du subnet “10.1.42.0/24” ("cidr_list": "10.1.42.0/24") et uniquement avec l’utilisateur “web” ("default_user": "web" et "allowed_users": "web").

Une fois ce role créé, l’utilisateur pourra par exemple demander un mot de passe pour le serveur 10.1.42.123 (qui fait donc partie du subnet 10.1.42.0/24) avec l’appel d’API suivant :

$ vault write ssh/creds/otp_web ip='10.1.42.123'

Dans le Secret Engine SSH, toute création dans l’API d’une ressource role de type OTP sur le chemin “ssh/roles/[nom du role]” rendra disponible le chemin “ssh/creds/[nom du role]” sur lequel l’utilisateur pourra obtenir des mots de passe de connexion à usage unique (dans la limite de ce que la configuration du role lui permet).

La vérification du mot de passe côté serveur

Maintenant que Vault est capable de générer des mots de passes à usage unique, il ne reste plus qu’à faire en sorte que les serveurs soient capables de vérifier la validité des mots de passe qui leur sont présentés.

On peut pour cela utiliser le petit utilitaire vault-ssh-helper.

L’outil se présente sous la forme d’un binaire Go autoportant qui peut être téléchargé ici. Ce binaire va ensuite être appelé à travers le mécanisme d’authentification PAM pour vérifier le mot de passe des utilisateurs qui tentent de se connecter. Une fois appelé il va aller vérifier le mot de passe auprès de Vault qui lui confirmera qu’il est bien valide. Si par la suite le même mot de passe est soumis à Vault pour vérification, Vault le refusera, garantissant ainsi que chaque mot de passe n’est utilisé qu’une fois.

Le fichier README.md du projet GitHub donne toutes les informations nécessaires pour mettre en place l’outil, il décrit la configuration (très simple) de l’outil, comment configurer PAM pour appeler vault-ssh-helper lors de la vérification des mots de passe pour les connexions SSH entrantes et comment configurer le serveur SSH pour s’assurer qu’il fasse bien appel à PAM pour vérifier les mots de passe qu’ils reçoit pour ses connexions entrantes.

Premières impressions

Cette option est intéressante par bien des aspects :

• Elle permet de contrôler très finement les utilisateurs et les serveurs sur lesquels une connexion est possible (à travers les paramètres allowed_users et cidr_list)

• Elle permet de s’assurer que les accès fournis par Vault ne sont utilisés qu’une seule et unique fois

• Elle offre une très bonne auditabilité des accès aux serveurs, car chaque requête de vérification faite par un serveur sera enregistré dans le système d’audit de Vault

Elle présente néanmoins un inconvénient important qui est même indiqué dans la documentation : elle nécessite un appel à Vault pour chaque vérification de mot de passe. Ce qui présente un risque de spoofing du serveur Vault qui pourrait permettre des accès non-autorisés aux serveurs.   En plus de cet inconvénient notable, on peut en citer quelques-uns plus mineurs :

• le besoin d’utiliser un outil tiers à insérer dans le processus d’authentification PAM ajoute de la complexité au socle logiciel de base que doivent avoir tous les serveurs de l’infrastructure

• l’utilisation de mots de passe plutôt que des clés SSH pour se connecter rend ce système un peu plus difficilement compatible avec certains accès SSH automatisés

• l’incapacité de contrôler avec Vault ce que l’utilisateur peut faire une fois connecté (l’autorisation de faire des redirections de port par exemple)

2ème solution : Les accès de type certificat SSH

Dans ce mode, Vault va signer la clé SSH publique de l’utilisateur avec sa clé privée, cette signature intégrera une durée de validité courte de l’ordre de quelques dizaines de minutes maximum. Lorsque cet utilisateur va présenter sa clé signée au serveur SSH, ce dernier va vérifier que la signature correspond à la clé publique de Vault qui a été préalablement installée et indiquée comme étant une CA (Certificate Authority) de confiance.

Vous voulez dire “certificat TLS”, non ?

Eh bien non, il s’agit bien d’un certificat SSH, en effet le système de clé asymétrique de SSH est basé sur la même primitive cryptographique que TLS : le chiffrement RSA, d’autres systèmes commencent à se démocratiser (que ce soit côté SSH ou TLS) mais RSA reste la référence. C’est aussi le seul chiffrement supporté par le Secret Engine SSH…   Notez bien : la notion de certificats TLS est un petit abus de langage, il s’agit de certificats X.509 qui sont utilisés dans le contexte du protocole TLS.   L’utilisation de ces certificats est aussi sensiblement la même qu’en TLS :

• la clé publique d’un serveur SSH peut être remplacée par un certificat signé par une CA en qui les utilisateurs qui se connectent ont confiance. Ce qui permet de faire confiance à un serveur sur lequel on se connecte pour la première fois, exactement comme ce qu’il se passe sur Internet avec HTTPS (c’est à dire HTTP dans TLS). Ce mécanisme remplace alors celui traditionnel de Trust On First Use de SSH basé sur une confiance accordée au serveur à la première connexion, avec son habituel message anxiogène “The authenticity of host ‘…’ can’t be established”.

• la clé publique d’un client SSH peut être remplacée par un certificat signé par une CA en qui les serveurs SSH ont confiance. Ainsi, en fournissant ce certificat et en prouvant qu’il dispose de la clé privée associée à sa clé publique, le client peut montrer au serveur qu’il a bien été autorisé à se connecter, ce mécanisme de certificat client existe aussi pour HTTPS, c’est par exemple un des moyens d’authentification possible sur l’API Vault (décrit ici). Ce mécanisme remplace dans le cas de SSH le besoin côté serveur d’une connaissance a priori de la clé publique du client par le biais du fichier authorized_keys.

La différence majeure entre certificats TLS et SSH est le système de chaîne de certification qui est absent en SSH.

Pour plus de détails sur les certificats SSH, cette page décrit le format, en résumé, ce format doit contenir une période de validité pour le certificat et des principals pour lequel il est valide (noms d’utilisateurs en mode certificat client et nom d’hôte en mode certificat serveur). En plus de ces éléments obligatoire il existe un système de champs optionnels qui permettent de restreindre l’usage du certificat (les critical options) ou au contraire d’en augmenter les autorisations (les extensions), ces deux types de champs supplémentaires sont décrits à la fin du document dans une section du même nom.

Les restrictions optionnelles qui sont disponible pour l’instant sont les suivantes :

• exécution forcée d’une commande, ce qui permet de fournir un certificat permettant seulement l’exécution d’une commande bien spécifique sur le serveur visé

• restriction des IP sources autorisées à se connecter, on pourra par exemple restreindre les certificats pour qu’ils ne soient utilisables que depuis le bastion

Les droits supplémentaires qui sont disponible pour l’instant (et donc désactivés par défaut) sont les suivants :

• l’autorisation du forwarding
  • de port
  • d’agent SSH
  • de X11 (pour la visualisation d’applications graphiques à distance)

• l’exécution du fichier “~/.ssh/rc” du compte de connexion

• l’allocation d’un PTY (c’est à dire la possibilité d’avoir un shell interactif)

Ajouter l’extension “permit-pty“ sera ainsi nécessaire pour permettre à l’utilisateur d’utiliser un shell interactif sur les serveurs.

Ces champs optionnels correspondent grosso-modo aux options qui sont disponibles dans les fichiers authorized_keys (décrits ici), avec néanmoins quelques options manquantes comme, par exemple, la capacité de contrôler finements quels ports peuvent faire l’objet d’une redirection.

Configuration d’un accès avec le mode Certificate Authority

Cette fois ci nous allons devoir mettre en place un role de type CA. Mais avant de pouvoir faire ça, il faut initialiser cette CA, c’est à dire créer sa paire de clés SSH. La clé publique pourra être récupérée et installé sur le serveur et la clé privée restera dans Vault sans aucun moyen de l’extraire.

$ vault write ssh/config/ca generate_signing_key=true

Une fois cette commande lancée, Vault disposera d’une clé privée de signature qu’il ne divulguera jamais et d’une clé publique qui peut être récupérée sans authentification, par exemple avec la commande cURL suivante :

$ curl 'https://vault.internal:8200/v1/ssh/public_key'

Maintenant que notre CA est initialisée nous pouvons créer nos rôles et commencer à les utiliser pour signer nos clés.   Un role de type CA peut se créer de la façon suivante :

$ vault write ssh/roles/ca_web - <<'EOH'
{
    "key_type": "ca",
    "allow_user_certificates": true,
    "default_user": "web",
    "allowed_users": "web",
    "ttl": "5m",
    "max_ttl": "5m"
}
EOH

Ici nous avons créé un role “ca_web” qui permettra aux personnes y ayant accès de faire signer leur clé publique SSH ("key_type": "ca") pour obtenir un certificat client ("allow_user_certificates": true) d’une durée de vie par défault et maximum de 5 minutes ("ttl": "5m" et "max_ttl": "5m"), qui permettra de se connecter avec l’utilisateur “web” uniquement ("default_user": "web" et "allowed_users": "web") à toutes les machines faisant confiance à la CA de ce Secret Engine SSH.

Nous avons ici restreint la durée de vie du certificat et l’utilisateur autorisé (qui sera indiqué dans les principals valides du certificat).

En revanche notre role tel quel laisse encore une liberté complète à l’utilisateur concernant les extensions qu’il peut demander dans son certificat. On peut mieux verrouiller notre role en ajoutant des paramètres supplémentaires, d’abord on ajoute une contrainte sur l’IP source (l’IP de notre bastion, 10.0.0.1) :

$ vault write ssh/roles/ca_web - <<'EOH'
{
    "key_type": "ca",
    "allow_user_certificates": true,
    "default_user": "web",
    "allowed_users": "web",
    "ttl": "5m",
    "max_ttl": "5m",
    "allowed_critical_options": " ",
    "default_critical_options": {
        "source-address": "10.0.0.1"
    }
}
EOH

Ces paramètres supplémentaires indiquent à Vault de ne pas permettre aux utilisateurs de gérer les critical options de leur certificat ("allowed_critical_options": " ") et de systématiquement insérer une critical options qui oblige à se connecter depuis le bastion ("source-address": "10.0.0.1").

On va ensuite ajouter des paramètres qui permettent à l’utilisateur d’obtenir un PTY, mais rien d’autre, pas de redirection de port notamment :

$ vault write ssh/roles/ca_web - <<'EOH'
{
    "key_type": "ca",
    "allow_user_certificates": true,
    "default_user": "web",
    "allowed_users": "web",
    "ttl": "5m",
    "max_ttl": "5m",
    "allowed_critical_options": " ",
    "default_critical_options": {
        "source-address": "10.0.0.1"
    }
    "allowed_extensions": "permit-pty",
    "default_extensions": {
        "permit-pty": ""
    }
}
EOH

Ces paramètres supplémentaires indiquent à Vault de ne pas permettre aux utilisateurs de demander d’autres extensions que permit-pty, celle qui les autorise allouer un PTY, ("allowed_extensions": "permit-pty") et d’insérer par défaut cette extension permit-pty ("permit-pty": "").

Une fois le role mis en place, un chemin “ssh/sign/[nom du role]” devient disponible sur l’API. Ce chemin permet alors de faire signer sa clé publique par Vault, dans la limite de ce que permet la configuration du role, par exemple :

$ vault write ssh/sign/ca_web [email protected]"$HOME/.ssh/id_rsa.pub"

La réponse contiendra un champs “signed_key” correspondant au fichier de certificat SSH et qui sera stocké dans un fichier “id_rsa-signed.pub” pour la suite des exemples.

Ce fichier de certificat peut être inspecté avec la commande ssh-keygen suivante :

$ ssh-keygen -L -f id_rsa-signed.pub

Dans cette commande, l’option -L indique à ssh-keygen que nous voulons inspecter un certificat SSH et l’option -f indique le fichier à inspecter.   Qui nous donnera en sortie quelque chose comme ça :

id_rsa-signed.pub:
        Type: [email protected] user certificate
        Public key: RSA-CERT SHA256:7yCwFqI21OEANvCtlAiZNyDMsSv2lV1EEaSnbQF4BD0
        Signing CA: RSA SHA256:HitN+Wc0hSKFBIQ0+Heczw4OFkBlrTLheuL7FVOCRn4
        Key ID: "vault-root-ef20b016a2..."
        Serial: 10734498250688175174
        Valid: from 2018-12-12T22:12:06 to 2018-12-12T22:17:36
        Principals:
                web
        Critical Options:
                source-address 10.0.0.1
        Extensions:
                permit-pty

On peut ainsi constater que tous les paramètres de certificat par défaut sont bien présents :

• durée de vie de 5 minutes (avec un sursis de 30 secondes visiblement)

• “web” utilisateur de connexion autorisé (seul valeur dans “Principals”)

• adresse source imposée à 10.0.0.1

• allocation de PTY autorisée

La mise en place côté serveur

Il ne reste maintenant plus qu’à faire la mise en place qui permettra au serveur de vérifier que le certificat qui lui sera fourni vient bien de Vault.

Côté serveur il faut simplement reconfigurer le service OpenSSH afin qu’il fasse confiance à la clé publique de la CA de Vault et accessoirement on peut aussi désactiver toute autre forme d’authentification, c’est à dire les mots de passe et les authorized keys.

Si on considère que la clé publique de notre CA Vault se trouve dans un fichier “/etc/ssh/user_ca.pub” il suffit d’ajouter la ligne suivante dans la configuration du serveur SSH (le fichier “/etc/ssh/sshd_config” le plus souvent) :

TrustedUserCAKeys /etc/ssh/user_ca.pub

On peut ensuite désactiver l’authentification par mot de passe :

PasswordAuthentication no
ChallengeResponseAuthentication no

et même les authorized keys :

AuthorizedKeysFile /dev/null

Après un redémarrage du service, notre serveur sera prêt à accepter tout certificat émis par notre CA.

Se connecter avec un certificat

Pour utiliser ce certificat lors de notre connexion, il faudra simplement l’ajouter dans une paramètre “-i” de notre client SSH :

$ ssh -i id_rsa-signed.pub -i ~/.ssh/id_rsa [email protected]

Ou avec l’élément suivant dans sa configuration SSH (~/.ssh/config) :

CertificateFile id_rsa-signed.pub

Premières impressions

Ce mode de fonctionnement a lui aussi des avantages :

• il ne nécessite aucun échange entre notre serveur et Vault, uniquement entre le bastion et Vault. Ce qui réduit la surface d’attaque sur ce dernier

• il permet de contrôler assez finement ce que l’utilisateur peut faire ou ne pas faire une fois connecté grâce au système des critical options et des extensions

• il utilise sur le client et sur le serveur les fonctionnalités d’OpenSSH déjà existantes

En revanche, malgré son élégance, cette solution a quelques inconvénients, durant la période de validité du certificat, celui-ci peut être utilisé sur un nombre arbitraire de serveurs qui font confiance à la CA SSH de Vault autant de fois que l’utilisateur le souhaite. Et ces connexions ne donne lieu à aucun log en dehors des logs du système lui-même, qu’il devient donc important de conserver et centraliser en dehors des serveurs.

Pour mitiger le très grand nombre de machines qui peuvent être accédées avec un certificat, il conviendra de mettre en place des mitigations, on peut en citer deux :

• Mettre en place des CA différentes pour des ensembles de serveurs différents. Cela se fait en activant le Secret Engine SSH plusieurs fois sur des chemins différents qui auront donc des clés de CA distinctes

• Mettre en place des noms d’utilisateurs distincts pour chaque machine ou groupe de machines. Ainsi si un role ne permet de se connecter qu’avec l’utilisateur “web.webserver” qui n’existe que sur les serveurs web, il n’aura alors accès qu’aux serveurs web.

Des policies pour faire le lien entre utilisateur et role

Pour mettre en place la dernière étape de notre contrôle d’accès, il ne reste plus qu’à associer à chacun des utilisateurs de notre Vault les droits d’accès dont il dispose au sein de l’infrastructure.

Comme on l’a vu, un role permet de définir un ensemble de droits sur les serveurs de l’infrastructure que l’utilisateur pourra demander à Vault sous la forme d’un mot de passe ou d’un certificat SSH. Ainsi donner des droits d’accès sur l’infrastructure à un utilisateur consiste à lui donner accès à des roles particulier dans le Secret Engine SSH.

Ce contrôle d’accès aux différents roles se fait en créant des policies, qui seront ensuite attribuées à nos différents utilisateurs lorsqu’ils s’authentifient auprès de l’API Vault. Le principe d’une policy dans Vault est de restreindre les ressources de l’API auquel l’utilisateur peut accéder et les interactions qu’il peut avoir avec ces ressources.

Par exemple la policy “web_access” créée par la commande suivante :

$ vault policy write web_access - <<'EOH'

path "ssh/sign/ca_web" {
capabilities = ["update"]
}

path "ssh/creds/otp_web" {
capabilities = ["update"]
}
EOH

Autorise l’utilisateur à qui elle est associée à faire appel au role de type OTP “otp_web” et au role de type CA “ca_web”. Mais pour accéder aux autres ressources de l’API Vault il lui faudra des policies supplémentaires.

Take Away

Au cours de cet article, on a pu voir comment confier à Vault la charge de contrôler les connexions SSH à notre infrastructure. Ce mode de gestion des accès permet :

• de n’avoir à faire qu’une configuration initiale de chaque serveur, réduisant la charge de maintenance sur le code d’infrastructure

• de contrôler les utilisateurs et leurs droits sur l’infrastructure de façon centralisée et sécurisée à travers l’API Vault

• de profiter des possibilités offertes par l’API Vault en termes d’interconnexion avec des référentiels d’utilisateurs existants (les différentes Auth Methods) et de gestion fines des permissions

Le tout en nécessitant simplement l’installation d’un binaire et une reconfiguration de PAM dans le mode de fonctionnement OTP ou une reconfiguration du serveur OpenSSH dans le mode de fonctionnement CA. Ce qui nous évite de nous séparer des outils habituels d’accès aux serveurs : SSH et son implémentation de référence OpenSSH.

Rappel des avantages et inconvénients des deux modes de fonctionnement du Secret Engine SSH :

L’essentiel du coût de ce mode de fonctionnement réside donc dans l’ajout d’un serveur Vault dans l’infrastructure et tout ce que ce nouveau composant entraîne en termes de besoin de sécurisation, mise en haute-disponibilité, d’audit et de contrôle d’accès. C’est un coût qui n’est pas anodin car votre serveur Vault deviendra une cible de choix au sein de votre infrastructure, mais qui aura au moins le mérite d’utiliser une logiciel conçu pour la sécurité.

De plus certaines limitations d’OpenSSH persistent, comme l’impossibilité de limiter la durée de vie d’une connexion SSH active. C’est à dire qu’on peut, par exemple, rester connecté avec un certificat SSH expiré tant que l’authentification initiale a eu lieu pendant qu’il était valide.