Teleport : accès zero-trust par certificats courts

Teleport est une plateforme d'accès basée sur l'identité qui remplace à elle seule les bastions SSH, les VPN d'accès et les clés SSH permanentes. Chaque connexion à un serveur, un cluster Kubernetes, une base de données ou une application passe par un proxy unique, est autorisée par un certificat à courte durée de vie (quelques heures), scopée par RBAC et entièrement auditée. Ce guide déploie un cluster Teleport 18.9.1 en conteneur, enrôle un node, configure le contrôle d'accès et montre l'enregistrement des sessions. Pour administrateurs et DevSecOps. Toutes les sorties proviennent d'un lab Docker réel.

Ce que vous allez apprendre

• Comprendre le modèle certificats courts plutôt que clés SSH permanentes
• Déployer un cluster Teleport (Auth + Proxy) et enrôler un node
• Donner un accès SSH scopé par RBAC et labels
• Accorder un accès just-in-time (Access Requests) et activer la MFA
• Enregistrer et rejouer les sessions pour l'audit

Prérequis

Docker et Docker Compose, un accès root sur la machine de lab. Pour un déploiement de production, prévoyez en plus un vrai domaine et un certificat TLS valide (Let's Encrypt). Le lab utilise un certificat auto-signé, suffisant pour apprendre.

Pourquoi des certificats courts plutôt que des clés SSH

Une clé publique dans ~/.ssh/authorized_keys est un secret permanent. Si elle fuite, l'accès reste valide indéfiniment, et la révocation doit se faire serveur par serveur. Rien ne relie cette clé à une identité forte ni à un second facteur. C'est le talon d'Achille de l'accès SSH traditionnel.

Teleport inverse le modèle. À la connexion, l'utilisateur s'authentifie via SSO et MFA, puis l'Auth Service émet un certificat SSH valable quelques heures. Le certificat expire seul : plus de rotation manuelle, plus de clé orpheline. La révocation est centralisée et immédiate, et chaque accès est attribué à une identité, pas à une adresse IP.

L'architecture en trois composants

Teleport repose sur trois services, portés par le même binaire teleport.

• L'Auth Service est le cerveau : il héberge les autorités de certification (CA SSH et CA TLS), applique le RBAC, signe les certificats et écrit l'audit log. C'est la seule source de vérité.
• Le Proxy Service est le point d'entrée unique, exposé sur le port web (3080 ou 443). Il termine les connexions clientes et route vers les agents.
• Les agents (nodes) tournent sur chaque ressource. Point clé pour la sécurité : un node derrière un NAT n'ouvre aucun port entrant, il établit un tunnel inverse sortant vers le Proxy. C'est ce qui rend Teleport sûr sans exposer les serveurs.

Trois binaires accompagnent ces services : tctl (administration locale sur l'Auth), tsh (client utilisateur) et tbot (Machine ID, pour l'accès machine).

Déployer un cluster Teleport en conteneur

On épingle la version 18.9.1 (image distroless officielle, registre public AWS ECR). La configuration minimale active l'Auth, le Proxy et le service SSH sur l'hôte.

docker-compose.yml

services:
  teleport:
    image: public.ecr.aws/gravitational/teleport-distroless:18.9.1
    command: serve
    restart: unless-stopped
    volumes:
      - ./config/teleport.yaml:/etc/teleport/teleport.yaml:ro
      - ./data:/var/lib/teleport

config/teleport.yaml

version: v3
teleport:
  nodename: teleport
  data_dir: /var/lib/teleport
auth_service:
  enabled: "yes"
  listen_addr: 0.0.0.0:3025
  cluster_name: teleport.lab
proxy_service:
  enabled: "yes"
  web_listen_addr: 0.0.0.0:3080
ssh_service:
  enabled: "yes"
  labels:
    env: lab

On démarre le cluster et on vérifie son état avec tctl status :

docker compose up -d
docker compose exec teleport tctl status

Cluster: teleport.lab
Version: 18.9.1
CA pins: sha256:134c994efe3f7fb0fb181082a54c3b92699a79b4eec37388adc60e86c4c2e82c

Le CA pin est l'empreinte de l'autorité de certification. Les nodes l'utilisent au moment du join pour vérifier qu'ils parlent au bon cluster, ce qui empêche une attaque de l'intermédiaire.

Créer le premier administrateur

L'utilisateur admin reçoit les rôles intégrés editor (administration) et access (accès aux ressources), avec les logins OS qu'il pourra emprunter :

docker compose exec teleport tctl users add admin --roles=access,editor --logins=root

User "admin" has been created but requires a password. Share this URL with the user
to complete user setup, link is valid for 1h:
https://teleport:3080/web/invite/6de5c52684b3cecd7da679142b0eff25

L'URL d'invitation sert à définir le mot de passe et enrôler un second facteur (OTP ou passkey) dans le navigateur. C'est la première manifestation du principe : aucun accès sans identité ni MFA.

Enrôler un node

Un node rejoint le cluster avec un token de join à durée limitée. On le génère côté Auth, puis on lance l'agent.

1. Générer le token (valable 30 minutes) :

   docker compose exec teleport tctl tokens add --type=node --ttl=30m --format=text

2. Lancer l'agent sur la machine à enrôler, en lui passant le token et l'adresse du cluster :

   teleport start --roles=node \
     --token=<token> \
     --auth-server=teleport:3025 \
     --nodename=node1 --labels=env=demo

3. Vérifier que le node a rejoint le cluster :

   docker compose exec teleport tctl nodes ls

   Host     Public Address  Labels   Version
   node1    172.22.0.3:3022 env=demo 18.9.1
   teleport 127.0.0.1:3022  env=lab  18.9.1

Lab : certificat auto-signé et entrypoint

Deux points propres au lab Docker. D'abord, l'image distroless a pour entrypoint teleport start -c /etc/teleport/teleport.yaml : pour lancer un node avec d'autres arguments, surchargez l'entrypoint (--entrypoint=/usr/local/bin/teleport). Ensuite, le certificat auto-signé du proxy ne couvre pas le nom du cluster : en lab, le node rejoint donc l'Auth directement sur le port 3025 avec l'option --insecure. En production, on utilise un vrai domaine avec public_addr et un certificat Let's Encrypt (directive acme), et le node rejoint par le Proxy (443).

Se connecter en SSH avec tsh

Le client tsh récupère un certificat court après authentification, puis ouvre les sessions :

tsh login --proxy=teleport.example.com:443 --user=admin
tsh ls                    # nodes accessibles, filtrés par RBAC + labels
tsh ssh root@node1        # session SSH (le login doit être autorisé)
tsh status                # certificats actifs et TTL restant

La connexion exige un login interactif (SSO ou mot de passe plus MFA via le navigateur). Pour un accès non interactif (CI, services), on ne réutilise pas un certificat humain : on emploie Machine ID (tbot), décrit plus bas.

Contrôler l'accès avec le RBAC

Le RBAC de Teleport est deny-by-default : sans règle explicite, aucun accès. Un rôle déclare les logins OS autorisés et les labels des nodes joignables.

kind: role
version: v8
metadata:
  name: dev-staging
spec:
  allow:
    logins: [root]
    node_labels:
      env: [demo]
  deny: {}

docker compose exec teleport tctl create -f dev-staging.yaml

role "dev-staging" has been created

Un porteur de ce rôle ne voit que les nodes labellisés env=demo et ne peut s'y connecter qu'en root. Les règles deny sont évaluées en premier et l'emportent toujours, ce qui rend le modèle prévisible.

Accorder un accès just-in-time

Plutôt que de donner un rôle puissant en permanence, les Access Requests l'accordent temporairement, sur justification auditée. C'est le moindre privilège appliqué dans le temps.

# L'utilisateur demande le rôle dba
tsh request create --roles=dba --reason="incident #4521"

# L'admin approuve (Community Edition : via tctl)
tctl request ls
tctl request approve <request-id>

L'accès devient additif et limité dans le temps. En Community Edition, l'approbation passe par tctl ; le workflow de revue self-service est une fonction Enterprise.

Renforcer avec MFA et SSO

La MFA s'exige au login, mais aussi par session (require_session_mfa: true dans un rôle) : même si un certificat sur disque est volé, l'ouverture d'une session redemande une vérification. Côté identité, la Community Edition prend en charge le SSO GitHub ; OIDC et SAML relèvent de l'édition Enterprise.

kind: github
version: v3
metadata:
  name: github
spec:
  client_id: <id>
  client_secret: <secret>
  redirect_url: https://teleport.example.com:443/v1/webapi/github/callback
  teams_to_roles:
    - organization: mon-org
      team: devops
      roles: [access, editor]

Accès machine-to-machine avec Machine ID

Pour qu'un pipeline CI/CD ou un service accède à l'infrastructure sans secret longue durée, tbot émet et renouvelle automatiquement des certificats courts. Les machines bénéficient ainsi de la même sécurité que les humains.

tbot start -c tbot.yaml   # renouvelle les certificats (par défaut toutes les 20 min)

Enregistrer et auditer les sessions

Teleport capture intégralement les sessions interactives et les rend rejouables, en plus d'un audit log structuré.

tsh recordings ls         # lister les sessions enregistrées
tsh play <session-id>     # rejouer une session SSH

Chaque événement (login, commande, transfert de fichier, demande d'accès) est attribué à une identité. En production, les enregistrements partent sur un stockage objet avec une politique de rétention. C'est précisément ce que réclament SOC 2, ISO 27001 et PCI-DSS.

Teleport ou Tailscale : deux couches complémentaires

La question revient souvent. Tailscale est un VPN mesh WireGuard : il fournit de la connectivité réseau avec des ACL par IP. Teleport est une plateforme d'accès par identité : RBAC fin, accès just-in-time, session recording, audit multi-protocole. Ils n'opèrent pas à la même couche et se combinent très bien : Tailscale pour relier les machines, Teleport pour l'accès audité aux ressources sensibles. Pour le détail du mesh, voir le guide Tailscale : VPN mesh WireGuard.

Pièges courants

Symptôme	Cause probable	Solution
certificate not yet valid	horloge décalée entre node et Auth	activer NTP (chronyd/timedatectl) partout
Le node ne joint pas via le proxy	certificat auto-signé / public_addr absente	vrai domaine + TLS, ou join direct Auth :3025 en lab
tsh casse après upgrade	client trop récent face au serveur	le client doit rester au plus une majeure sous l'Auth
Passkeys refusées	origine TLS non valide	un vrai certificat est requis pour WebAuthn
Disque qui se remplit	enregistrements de session accumulés	stockage objet + rétention en production

Glissez pour voir

À retenir

• Teleport est une plateforme d'accès par identité : un proxy unique pour SSH, Kubernetes, bases et applications, avec audit.
• Les certificats courts remplacent les clés SSH permanentes : expiration automatique, révocation centralisée, accès lié à une identité.
• Les nodes rejoignent par tunnel inverse, sans port entrant ; le CA pin sécurise le join.
• Le RBAC est deny-by-default (logins plus labels) ; les Access Requests donnent un accès just-in-time.
• MFA au login et par session, SSO GitHub en Community, OIDC/SAML en Enterprise.
• Session recording et audit attribués par identité, alignés SOC 2 / ISO 27001 / PCI-DSS.
• Épingler la version (18.9.1) : une majeure par an, support 24 mois, v17 en fin de vie en août 2026.

FAQ : questions fréquentes sur Teleport

Qu'est-ce que Teleport et à quoi sert-il ?

Teleport est une plateforme d'accès basée sur l'identité. Elle remplace bastions, VPN et clés SSH statiques par un proxy unique donnant accès aux serveurs SSH, clusters Kubernetes, bases de données et applications via des certificats courts, avec RBAC et audit complet.

Pourquoi les certificats courts de Teleport sont-ils plus sûrs que les clés SSH ?

Une clé SSH dans authorized_keys est un secret permanent : si elle fuite, l'accès reste valide jusqu'à révocation manuelle sur chaque serveur. Le certificat Teleport expire seul (quelques heures), est lié à une identité SSO + MFA et n'est jamais réutilisable, ce qui supprime la gestion des clés.

Comment Teleport fonctionne-t-il derrière un NAT sans ouvrir de port ?

Les agents Teleport n'ouvrent aucun port entrant. Ils établissent un tunnel inverse (reverse tunnel) sortant vers le Proxy Service. Toutes les connexions clientes passent par ce proxy, qui route vers les agents via le tunnel. C'est ce qui rend Teleport sûr derrière un NAT ou un pare-feu strict.

Quelle est la différence entre Teleport et Tailscale ?

Tailscale est un VPN mesh WireGuard : connectivité réseau avec ACL par IP. Teleport est une plateforme d'accès par identité : RBAC fin, accès just-in-time, certificats courts, session recording et audit multi-protocole. Ils opèrent à des couches différentes et sont complémentaires.

Qu'est-ce que le RBAC dans Teleport ?

Le RBAC de Teleport définit qui accède à quoi via des rôles. Un rôle déclare les logins OS autorisés, les labels des nodes accessibles et les permissions. Le modèle est deny-by-default : sans règle explicite l'accès est refusé, et les règles deny priment.

Qu'est-ce qu'un Access Request (accès just-in-time) dans Teleport ?

Un Access Request permet de demander temporairement un rôle plus privilégié (ex : dba) avec justification. Une fois approuvé, le rôle est accordé de façon additive et limitée dans le temps. En Community Edition l'approbation se fait via tctl ; le workflow de revue self-service est Enterprise.

La Community Edition de Teleport est-elle suffisante ?

La Community Edition couvre SSH, Kubernetes, bases, applications, RBAC, session recording, audit et MFA. Ses limites : seul GitHub pour le SSO (pas OIDC/SAML), et Access Requests via tctl sans workflow de revue. OIDC, SAML, Device Trust avancé et review workflow sont réservés à Enterprise.

Comment Teleport enregistre-t-il les sessions pour l'audit ?

Teleport enregistre intégralement les sessions interactives (rejouables via tsh play) et produit un audit log attribuant chaque action à une identité, pas à une IP. Le recording se configure en mode node, node-sync, proxy ou proxy-sync. Conforme SOC2, ISO 27001 et PCI-DSS.

Prochaines étapes

Sécuriser les accès à l'infrastructure Le hub : bastions, ZTNA, VPN et proxies d'identité.

Tailscale : VPN mesh WireGuard La couche réseau complémentaire, avec Headscale souverain.

Comprendre Pomerium Proxy d'identité pour un accès contextuel aux applications.

×

📖 Voir la documentation →