Déployer un bastion d'administration avec Teleport open source

Selon l’ANSSI, plus de 70 % des incidents critiques impliquent un compte à privilèges compromis. Face à ce constat, les cadres réglementaires NIS2, RGPD et ISO 27001 imposent une traçabilité complète des accès sensibles – et l’ANSSI recommande explicitement l’usage de solutions de rebond pour sécuriser les systèmes critiques. Si votre infrastructure expose encore des ports SSH directement accessibles, ou si vos accès administrateurs transitent par un VPN partagé sans journalisation des sessions, vous n’avez pas de bastion : vous avez un périmètre qui attend d’être franchi.

Sommaire

Ce que Teleport fait concrètement

Teleport est une passerelle d’accès open source qui centralise SSH, Kubernetes et les applications HTTPS derrière un point d’entrée unique, authentifié et audité. Il applique un modèle Zero Trust : aucune confiance implicite accordée au réseau, chaque connexion est vérifiée, chaque session est enregistrée.

En pratique, Teleport remplace plusieurs briques à la fois. Plus besoin d’un VPN pour joindre les serveurs internes : le Proxy Teleport expose une surface d’entrée unique, accessible depuis internet ou depuis un réseau privé selon votre architecture. Les clés SSH statiques distribuées sur les machines disparaissent au profit de certificats éphémères émis par l’Auth Server. Et chaque commande exécutée dans une session peut être rejouée depuis l’interface d’administration.

Trois composants structurent le service :

Auth Server : l’autorité de certification interne, qui émet les certificats et stocke les politiques d’accès et les logs d’audit.
Proxy Server : le point d’entrée réseau, celui que les utilisateurs contactent avec le client tsh.
Node (agent Teleport) : le démon installé sur chaque serveur à protéger, qui remplace ou complète le démon SSH natif.

Dans un déploiement simple, Auth Server et Proxy Server tournent sur la même machine. C’est le cas de figure décrit ici.

Architecture cible et prérequis réseau

Le serveur Teleport doit être joignable par les utilisateurs et par les nœuds à enrôler. Dans un contexte cloud ou hybride, une VM exposée sur un IP public avec un DNS stable est le choix le plus direct. En environnement on-premise, le Proxy peut être placé en DMZ ou derrière un load balancer selon votre topologie.

Les flux réseau à ouvrir dépendent des protocoles activés. Le Proxy écoute sur le port HTTPS standard pour l’interface web et l’API, sur un port dédié pour les connexions SSH via tsh, et sur un port spécifique pour le protocole Kubernetes si vous activez cette fonctionnalité. Les numéros de ports exacts sont définis dans votre fichier de configuration et dans la documentation officielle Teleport, qui précise les valeurs par défaut pour chaque service. Les nœuds agents n’ont pas besoin d’être accessibles depuis l’extérieur : ils se connectent vers le Proxy (connexion sortante), ce qui simplifie les règles de pare-feu.

Prérequis à vérifier avant de commencer :

Un nom de domaine résolvable pointant vers le Proxy (obligatoire pour les certificats TLS)
Un certificat TLS valide – Teleport s’intègre avec Let’s Encrypt en mode automatique
Un accès root ou sudo sur le serveur hôte
Une distribution Linux récente sur le serveur Teleport et sur les nœuds à enrôler
Pour un périmètre réduit : le backend SQLite embarqué suffit ; au-delà d’un certain volume de nœuds ou pour de la haute disponibilité, un backend externe (PostgreSQL, DynamoDB) devient nécessaire

Installation du serveur Teleport (Auth + Proxy)

La méthode recommandée pour installer Teleport sur Linux passe par le dépôt officiel. Les commandes exactes varient selon la distribution et la version cible ; la documentation officielle fournit un script d’installation paramétrable. Dans les grandes lignes, l’installation ajoute le dépôt Teleport, installe le paquet teleport via le gestionnaire de paquets système, puis active le service.

Une fois le paquet installé, générez un fichier de configuration initial avec :

teleport configure -o /etc/teleport.yaml \
  --cluster-name=mon-cluster.exemple.com \
  --public-addr=mon-cluster.exemple.com:443 \
  --acme --acme-email=admin@exemple.com

Ce fichier définit les paramètres essentiels. Les sections importantes à comprendre :

cluster_name : l’identifiant immuable du cluster – choisissez-le bien, il ne peut pas changer sans réinstallation.
public_addr : l’adresse que les clients et les nœuds utilisent pour joindre le Proxy.
acme : active la gestion automatique des certificats via Let’s Encrypt. Requiert que le port 80 soit accessible pour la validation.
storage : par défaut SQLite, stocké localement. Suffisant pour démarrer.

Activez et démarrez le service :

systemctl enable teleport
systemctl start teleport

Vérifiez que tous les sous-services sont actifs avec systemctl status teleport et consultez les logs avec journalctl -u teleport -f si quelque chose ne démarre pas.

Premier compte administrateur et enrôlement d’un nœud

Créez le premier utilisateur administrateur directement sur le serveur :

tctl users add admin --roles=editor,access --logins=root,ubuntu

Cette commande génère un lien d’invitation unique. Ouvrez-le dans un navigateur pour définir le mot de passe et configurer un second facteur (TOTP ou clé de sécurité). L’interface web est disponible à l’adresse définie dans public_addr.

Pour enrôler un premier serveur SSH, installez le paquet Teleport sur ce serveur (même procédure que le serveur principal), puis générez un token d’invitation depuis le serveur Auth :

tctl tokens add --type=node --ttl=1h

Sur le nœud à enrôler, lancez la commande de jonction avec le token obtenu :

teleport start \
  --roles=node \
  --token=<TOKEN> \
  --auth-server=mon-cluster.exemple.com:443

Ou configurez /etc/teleport.yaml sur le nœud avec ces paramètres, puis activez le service. Le nœud apparaît dans l’interface web sous « Servers » dès la connexion établie.

Depuis un poste client, installez le client tsh (disponible pour Linux, macOS, Windows), authentifiez-vous :

tsh login --proxy=mon-cluster.exemple.com --user=admin

Puis connectez-vous au nœud enrôlé :

tsh ssh root@nom-du-noeud

Si la session s’ouvre, la chaîne de confiance fonctionne : le certificat a été émis par l’Auth Server, le Proxy a relayé la connexion, et le nœud l’a acceptée.

Gestion des rôles et principe du moindre privilège

Teleport utilise un système de rôles YAML pour définir qui peut accéder à quoi. Un rôle précise les nœuds autorisés (via des labels), les logins SSH permis, et les durées maximales de session ou de certificat. C’est ce mécanisme qui transforme Teleport en bastion Zero Trust plutôt qu’en simple jump host.

Exemple de rôle restrictif pour un développeur qui n’a accès qu’aux serveurs de staging :

kind: role
version: v6
metadata:
  name: dev-staging
spec:
  allow:
    logins: [deployer]
    node_labels:
      env: staging
    session_ttl: 8h
  deny:
    logins: [root]

Appliquez ce rôle avec tctl create -f role-dev-staging.yaml, puis assignez-le à un utilisateur :

tctl users update alice --set-roles=dev-staging

Alice peut désormais se connecter uniquement sur les serveurs portant le label env: staging, avec le login deployer, jamais en root. Les labels sont posés sur les nœuds dans leur fichier teleport.yaml sous la clé ssh_service.labels.

L’intégration avec un fournisseur d’identité externe (Active Directory, Okta, GitHub) est possible en version open source pour GitHub OAuth et certains connecteurs OIDC basiques. Les protocoles SAML et les connecteurs LDAP/AD avancés sont réservés à l’édition Enterprise.

Audit et rejeu de sessions

Chaque session SSH est enregistrée automatiquement par l’Auth Server. Les données capturées incluent les frappes clavier, la sortie terminal, les métadonnées de connexion (utilisateur, nœud, horodatage, adresse source) et les éventuels transferts de fichiers via SCP/SFTP.

Les sessions sont accessibles depuis l’interface web sous l’onglet « Audit Log », ou via la CLI :

tctl audit log --type=session.start,session.end

Pour rejouer une session enregistrée :

tsh play <session-id>

La lecture se fait dans le terminal, avec reconstitution temporelle des interactions. C’est ce que vous présentez lors d’un audit : une preuve d’accès non répudiable, horodatée, liée à un utilisateur identifié avec un second facteur.

Les logs sont exportables au format JSON, ce qui permet leur ingestion dans un SIEM (Elasticsearch, Splunk, etc.) pour corrélation et alertes. La configuration de l’export se fait dans la section audit_events_uri du fichier teleport.yaml.

Limites de l’édition open source

La version open source couvre l’essentiel d’un bastion opérationnel : SSH, Kubernetes, applications web, enregistrement des sessions, rôles et accès conditionnel. Les fonctionnalités absentes qui peuvent bloquer certains contextes :

SSO via SAML (Okta, Azure AD, ADFS) et connecteurs LDAP avancés – obligatoire si votre annuaire d’entreprise ne parle pas OIDC ni GitHub OAuth
Rapports de conformité automatisés (tableaux de bord ISO 27001, SOC 2) intégrés dans l’interface
Support des secrets de base de données et de certains protocoles applicatifs spécifiques
Support technique officiel garanti

Si votre organisation utilise Active Directory comme seul annuaire et que les utilisateurs ne peuvent pas avoir de compte local Teleport, l’édition Enterprise devient nécessaire. Pour un déploiement avec des infrastructures orientées open source et une gestion des identités indépendante de Microsoft, la version gratuite tient la route pour la majorité des PME.

Un déploiement single-node avec SQLite reste un point de défaillance unique. Si Teleport tombe, les accès administrateurs tombent avec lui – ce qui peut devenir critique selon votre organisation. La haute disponibilité avec backend externe est documentée officiellement et reste accessible techniquement, mais elle sort du périmètre d’un premier déploiement.

Checklist de déploiement

À valider dans l’ordre pour confirmer que chaque couche fonctionne avant de passer à la suivante :

[ ] DNS configuré et résolvable pour le nom de domaine du Proxy
[ ] Ports réseau ouverts (HTTPS, SSH Proxy, et les ports Teleport spécifiques selon la documentation)
[ ] Paquet Teleport installé sur le serveur Auth+Proxy, service actif
[ ] Certificat TLS valide (Let’s Encrypt ou certificat apporté)
[ ] Premier compte administrateur créé, MFA configuré, connexion web validée
[ ] Premier nœud SSH enrôlé et visible dans l’interface
[ ] Connexion tsh ssh validée depuis un poste client
[ ] Rôle restrictif créé et assigné à un utilisateur de test
[ ] Session enregistrée visible dans l’Audit Log, rejeu fonctionnel
[ ] Export des logs vers SIEM configuré (si applicable)

La gestion des flux réseau entrants est souvent le premier point de friction lors d’un déploiement Proxy exposé sur internet : vérifiez que les règles de pare-feu distinguent bien les ports Teleport des ports standards et que le NAT ne casse pas les connexions persistantes des agents nœuds. Une fois ce point réglé, le reste du déploiement suit une logique prévisible.

Pour les organisations qui gèrent également leur infrastructure physique en baie de brassage, Teleport ne remplace pas la segmentation réseau physique – il s’y superpose en couche logique d’authentification et d’audit.