Cela faisait longtemps que je zieutais les solutions de bastion / proxy autant dans une optique de veille technologique sur nos accès fournisseurs divers que pour certains besoins internes de sécurisation. Assez récemment, et après pas mal de pérégrinations diverses zé variées (notamment avec SSHportal ou Guacamole), je suis finalement tombé en milieu d’année dernière sur la solution Teleport, que j’ai finalement pris le temps d’expérimenter … Et c’est génial ! Il faut que je vous en parle !

Teleport ? Energie, Scotty !

Dès qu’on a un besoin d’accès distant à des ressources d’infrastructure, se pose toujours la question du risque « d’ouvrir » un minimum nos barrières périmétriques et donc potentiellement d’augmenter notre surface d’attaque. Même avec un système de service VPN bien durci, il y a toujours un risque de s’exposer et accroitre mécaniquement notre vulnérabilité à toute sorte de tentatives de pénétration, préméditées ou non.

Teleport – comme certains autres bastion d’ailleurs, (Systancia Gate anciennement IPdiva ou Wallix Bastion, en france) – part du principe que pour ne rien exposer, il « suffit » de ne rien ouvrir. C’est une idée assez ancienne bien entendu, mais ses concepteurs sont partis d’un socle encore plus novateur et robuste à mon goût, une approche centrée sur l’Open Source et très orientée vers les métiers DevOps.

Teleport est donc un bastion, dans la plus pure tradition : vous créez des utilisateurs ayant des accès spécifiques à certaines ressources, mais n’ayant aucun besoin de connaitre les credentials réels (accès administrateurs ou exploitant) des ressources que vous allez leur présenter. Il sont authentifiés nécessairement en double facteur (impossible de se connecter à Teleport avec un seul facteur, vous le verrez) doivent uniquement leurs accès grâce à l’utilisation de mécanismes basés sur les échanges des traditionnels certificats (et clef privées/publiques associées).

Lors de leurs utilisation de la solution, toutes les sessions sont logguées, mais également, pour les plus interactives (SSH, RDP), enregistrées et rejouables à la demande (via un lecteur video ad-hoc). Teleport utilise aussi sa capacité à s’intégrer à des PKI externes pour générer tout ce qu’il faut pour garantir la sécurité globale du système (c’est notamment le cas lorsque vous souhaitez vous connecter à des postes de travail intégrés à votre Active Directory via RDP). Accesoirement il est également possible de mettre en place un partage de sessions à plusieurs, chacun se connectant au même client et pouvant interagir ensemble.

Bref, sur le papier c’est une vrai solution d’accès distant sécurisé, très complet et relativement facile à déployer aujourd’hui. Il existe deux formules différentes, dont les objectifs sont forcément différents : le mode Community, totalement Open Source et fourni gratuitement avec quasiment toutes les fonctions disponibles ; le mode Enterprise, toujours basé sur le même socle de sources et disponible en SAAS ou toujours en OnPremise pour la partie bastion proprement dite (à vous de choisir).

Teleport Community Edition

Je vous présente ici les quelques exemples que j’au pu déployer chez moi, directement (je n’utilise plus que cela désormais ^^), avec la solution Community. Si vous êtes pressé, il est possible aussi de tester la version Enterprise grâce à une solution SaaS (la partie Bastion du moins) disponible en trial pour 15 jours ; essayez-là, elle est à mon avis suffisante pour en tester le potentiel complet.

Pour simplifier à l’extrême, le bastion est la seule partie critique qui doit être accessible sur Internet, via son portail web. Ensuite, chaque noeud serveur ou client vien établir une connexion montante vers le bastion, grâce à un agent, et maintient ce lien tant que nécessaire. Cet agent assure tous les échanges in/out nécessaires à son accès à distance. Aucune règles particulière n’est nécessaire, en dehors du bastion lui même si vous choissez de le positionner en coupure interne/externe.

De mon coté, j’ai opté pour un bastion hébergé via une instance (VPS) chez Scaleway. Donc techniquement je n’ai aucun port ouvert chez moi depuis l’extérieur.

Au sujet de l’installation, la documentation disponible est relativement claire, cependant la courbe d’apprentissage reste assez longue pour bien comprendre la complexité intrinsèque du produit. Cela dépend vraiment de votre maturité vis à vis des nombreux principes de la philosophie DevOps (Kubernetes et autre Ansible sont vos amis ^^). Disons qu’un développeur rompu à l’exercice de manipulation de json, yaml, certificats etc, ne devrait pas rencontrer de problème. Pour votre info, il a fallu que je lise calmement et complètement la documentation, additionnée de quelques videos sur Youtube pour maîtriser à peu près la bête et cela m’a pris quelques jours. Bon, oui, on est d’accord, RTFM au final hein ? Oui, mais là c’est particulièrement vrai 🙂

Il faut signaler aussi que j’ai du jouer du Let’s Encrypt car ce bastion doit absolument être parfait en terme de certification publique, si vous comptez l’utiliser au quotidien. C’est un point d’accès critique, donc on déconne pas avec ça (sinon, vous risquez de galérer). A cette occasion j’ai découvert que OVH (et quelques autres hébergeurs sans doute) fournissent un jeux d’API très bien adaptée à la génération et renouvelement des certificats SSL sur un domaine hébergé chez eux. Je vous en parlerai sans doute bientôt car je n’utilise que cela désormais (encore une découverte récente). En attendant, vous trouverez des liens vers des sites qui en parlent et expliquent cette nouvelle méthode uniquement basé sur les DNS d’OVH, bien plus efficace et pratique, que l’utilisation plus classique de certbot, en fin de billet.

Et ce n’est qu’un avant goût !

Je ne viens que d’éffleurer le potentiel de Teleport, ici. Je n’ai pas parlé de la prise de main RDP sur potentiellement tous les postes déclarés dans un AD. Il existe, je l’ai dit, aussi des fonctions pour ouvrir des connexions sécurisées vers des Base de données, des clusters Kubernetes, voir plus avec les application « TCP ».

D’une manière générale, la logique de Teleport reste toujours la même. Ce bastion Open Source reste une petite pépite particulièrement puissante et sécurisée (justement car elle est Open Source), qui correspond vraiment à des besoins de plus en plus importants dans les entreprises. Son potentiel est quasiment illimité quand vous avez compris son mécanisme. La seule chose qu’il vous reste, c’est de l’essayer et de partager votre propre expérience avec moi bien sûr, mais aussi avec tous les autres adminsys et autres responsables sécurité !

Références :
Teleport, évidemment : ici.
Teleport, comment ça marche : ici
Teleport sur Youtube : ici.
Comment utiliser les API d’OVH pour générer des certificat SSL via Let’s Encrypt : ici.
Les limitations de Teleport sur Mac Apple Silicon actuellement : ici.