Teleport : Accès Zero Trust SSH et Kubernetes

Guide expert Teleport : accès unifié Zero Trust pour SSH, Kubernetes, bases de données et apps web. Certificats éphémères, RBAC, session recording, audit.

Teleport, développé par Gravitational (désormais Teleport Inc.), s'est imposé comme l'une des solutions les plus abouties pour le zero trust access plane, unifiant l'accès sécurisé aux serveurs SSH, aux clusters Kubernetes, aux bases de données, aux applications web et aux postes Windows dans une plateforme unique. Dans un paysage de cybersécurité où le périmètre réseau traditionnel s'effrite au profit d'architectures distribuées, cloud-native et multi-cloud, Teleport répond à un besoin fondamental : fournir un accès basé sur l'identité plutôt que sur la topologie réseau, tout en maintenant une traçabilité complète de chaque session. L'architecture de Teleport repose sur un système de certificats éphémères qui remplace les clés SSH statiques et les mots de passe par des certificats X.509 et SSH à durée de vie courte, émis dynamiquement après une authentification forte. Cette approche élimine les vecteurs d'attaque liés à la compromission de clés persistantes et aux accès résiduels non révoqués. Ce guide technique expert couvre l'ensemble de l'écosystème Teleport : architecture interne, services Auth et Proxy, gestion des certificats, RBAC granulaire, enregistrement de sessions, intégration SSO, audit logging, et stratégies de déploiement. Que vous soyez ingénieur plateforme, administrateur sécurité ou consultant en cybersécurité d'entreprise, ce guide vous fournira les connaissances nécessaires pour évaluer, déployer et exploiter Teleport dans votre organisation.

Points clés de cet article :

Teleport est un access plane Zero Trust unifiant SSH, Kubernetes, bases de données, applications web et Windows
L'architecture repose sur des certificats éphémères (courte durée de vie) émis dynamiquement, éliminant les clés statiques
Le Auth Service gère l'authentification, la délivrance de certificats et les politiques RBAC
L'enregistrement intégral des sessions SSH et Kubernetes fournit un audit trail complet et rejouable
L'intégration SSO (OIDC, SAML, GitHub, Active Directory) centralise la gestion des identités
Teleport est disponible en self-hosted (Community et Enterprise) et en SaaS (Teleport Cloud)

Qu'est-ce que Teleport et quel problème résout-il ?

Teleport est une plateforme d'accès sécurisé qui implémente les principes du Zero Trust pour l'accès aux infrastructures. Contrairement aux approches traditionnelles qui s'appuient sur des réseaux privés virtuels (VPN) pour créer un périmètre de confiance, Teleport part du principe qu'aucun réseau n'est intrinsèquement sûr et que chaque accès doit être authentifié, autorisé et audité indépendamment. Le projet a été créé par Gravitational en 2016, initialement comme une solution de gestion d'accès SSH pour les environnements cloud, avant de s'étendre progressivement pour couvrir Kubernetes, les bases de données (PostgreSQL, MySQL, MongoDB, Redis, CockroachDB, Elasticsearch, Microsoft SQL Server), les applications web internes, les postes Windows (RDP) et même les serveurs de bureau à distance.

Le problème fondamental que Teleport résout est la gestion des accès privilégiés dans les infrastructures modernes. Dans une organisation typique, les ingénieurs doivent accéder à des dizaines, voire des centaines de serveurs, clusters et bases de données, souvent répartis sur plusieurs fournisseurs cloud et régions géographiques. La gestion traditionnelle de ces accès — distribution de clés SSH, configuration de fichiers authorized_keys, gestion de mots de passe de bases de données, configuration de kubeconfigs — crée une complexité opérationnelle considérable et une surface d'attaque étendue. Les clés SSH peuvent être compromises, les mots de passe peuvent fuiter, les accès ne sont pas systématiquement révoqués lors du départ d'un collaborateur, et la traçabilité des actions effectuées est souvent insuffisante pour répondre aux exigences de conformité. Teleport adresse chacun de ces problèmes en centralisant l'authentification, en remplaçant les credentials statiques par des certificats éphémères, en imposant un RBAC granulaire et en enregistrant l'intégralité des sessions pour l'audit.

L'adoption de Teleport se justifie particulièrement dans les contextes suivants : les organisations soumises à des réglementations strictes (SOC 2, PCI-DSS, HIPAA, RGPD) nécessitant un audit trail complet des accès aux données sensibles ; les équipes DevOps et SRE gérant des infrastructures cloud-native distribuées où la gestion manuelle des accès devient ingérable ; les entreprises engagées dans une démarche Zero Trust cherchant à éliminer les VPN traditionnels ; et les environnements multi-cloud où l'unification de l'accès à travers AWS, GCP, Azure et on-premises est critique. Teleport est disponible en version open source (Community Edition), en version commerciale (Enterprise) et en mode SaaS (Teleport Cloud), offrant une flexibilité de déploiement adaptée à différentes contraintes organisationnelles et budgétaires.

Architecture de Teleport

L'architecture de Teleport est conçue autour de services modulaires qui peuvent être déployés ensemble sur une même machine ou distribués sur plusieurs nœuds pour la haute disponibilité et la scalabilité. La compréhension de cette architecture est essentielle pour planifier un déploiement adapté aux besoins de l'organisation et pour diagnostiquer les problèmes en exploitation.

Auth Service : le coeur de Teleport

Le Auth Service est le composant central de Teleport, fonctionnant comme une autorité de certification (CA) interne et un serveur d'authentification. Il est responsable de l'émission des certificats SSH et X.509 utilisés pour l'authentification mutuelle entre les composants, de l'application des politiques RBAC (Role-Based Access Control), du stockage de l'audit log et de la gestion des sessions. Le Auth Service maintient deux autorités de certification distinctes : une CA SSH qui émet des certificats pour l'authentification des utilisateurs auprès des serveurs SSH et des certificats hôte pour l'authentification des serveurs, et une CA TLS qui émet des certificats X.509 pour l'authentification mutuelle entre les services Teleport et pour l'accès aux bases de données et applications web. Les clés de ces CA sont stockées de manière sécurisée dans le backend de données configuré (etcd, DynamoDB, PostgreSQL, SQLite pour les déploiements légers).

Lorsqu'un utilisateur s'authentifie auprès de Teleport (via SSO, mot de passe local avec MFA, ou WebAuthn), le Auth Service vérifie son identité, évalue les rôles RBAC associés, et émet un certificat éphémère contenant les métadonnées d'autorisation (rôles, permissions, contraintes de session). La durée de vie de ce certificat est configurable, avec une valeur par défaut de 12 heures — une durée suffisamment longue pour une journée de travail mais suffisamment courte pour limiter l'impact d'une compromission. Cette approche est fondamentalement différente de la gestion traditionnelle des clés SSH, où une clé privée compromise donne un accès indéfini jusqu'à sa révocation manuelle dans tous les fichiers authorized_keys de l'infrastructure.

Proxy Service : le point d'entrée unifié

Le Proxy Service est le composant orienté vers l'extérieur, servant de point d'entrée unique pour tous les types d'accès. Il expose une interface web (le Teleport Web UI) pour la gestion et l'accès via navigateur, et agit comme un proxy pour les connexions SSH, Kubernetes, bases de données et applications. Le Proxy Service ne stocke aucune donnée d'état (stateless) et peut être déployé en plusieurs instances derrière un load balancer pour la haute disponibilité et la distribution géographique. Les connexions entre les utilisateurs et le Proxy Service sont protégées par TLS, tandis que les connexions entre le Proxy Service et les nœuds cibles sont authentifiées par certificats mutuels émis par le Auth Service. Cette architecture permet de concentrer la surface d'attaque externe sur un nombre limité de points d'entrée, tout en maintenant une connectivité complète vers l'ensemble des ressources internes.

Node Agents : SSH, Kubernetes, Database, App

Les agents Teleport sont des processus légers déployés à proximité des ressources à protéger. Chaque type de ressource dispose d'un agent spécialisé : le Node agent pour les serveurs SSH, le Kubernetes agent pour les clusters K8s, le Database agent pour les bases de données, et l'App agent pour les applications web internes. Ces agents s'enregistrent auprès du Auth Service lors de leur démarrage, obtiennent un certificat d'identité, et maintiennent une connexion reverse tunnel vers le Proxy Service. Ce modèle de connexion sortante est particulièrement avantageux car il permet aux agents de fonctionner derrière un NAT ou un pare-feu restrictif sans nécessiter l'ouverture de ports entrants — un avantage opérationnel majeur dans les environnements cloud et hybrides.

Authentification par certificats éphémères

Le système de certificats éphémères de Teleport représente une rupture fondamentale avec la gestion traditionnelle des accès SSH et base de données. Comprendre son fonctionnement est essentiel pour apprécier les avantages de sécurité qu'il apporte et pour configurer correctement les durées de vie et les politiques de renouvellement.

Le flux d'authentification de Teleport commence lorsqu'un utilisateur exécute la commande tsh login ou accède à l'interface web. L'utilisateur est redirigé vers le fournisseur d'identité configuré (Okta, Azure AD, Google Workspace, GitHub, ou le système d'authentification local de Teleport avec MFA). Après une authentification réussie, le Auth Service génère une paire de clés temporaire côté serveur, crée un certificat SSH et un certificat X.509 contenant l'identité de l'utilisateur et ses autorisations, les signe avec la CA interne, et les renvoie à l'utilisateur. Le client tsh stocke ces certificats localement (dans ~/.tsh/) et les utilise automatiquement pour les connexions ultérieures pendant leur durée de validité. Lorsque le certificat expire, l'utilisateur doit se réauthentifier pour en obtenir un nouveau — il n'y a pas de renouvellement silencieux, garantissant que l'accès est réévalué périodiquement.

Les avantages de sécurité de cette approche sont multiples. Premièrement, la compromission d'un certificat a un impact limité dans le temps : même si un attaquant obtient un certificat, celui-ci expirera dans quelques heures, contrairement à une clé SSH qui resterait valide indéfiniment. Deuxièmement, la révocation des accès est immédiate et centralisée : verrouiller un compte utilisateur dans Teleport empêche l'émission de nouveaux certificats sans nécessiter de modifier les configurations sur chaque serveur. Troisièmement, les métadonnées d'autorisation encodées dans le certificat (rôles, permissions, contraintes) sont vérifiées par chaque nœud lors de la connexion, garantissant que les politiques RBAC sont appliquées de manière cohérente sur l'ensemble de l'infrastructure.

RBAC : contrôle d'accès basé sur les rôles

Le système RBAC de Teleport est l'un de ses composants les plus puissants, permettant de définir des politiques d'accès granulaires qui contrôlent précisément quels utilisateurs peuvent accéder à quelles ressources, avec quels privilèges et sous quelles conditions. Les rôles sont définis au format YAML et peuvent être gérés via la CLI tctl, l'API ou l'interface web.

# role-devops.yaml — Rôle pour les ingénieurs DevOps
kind: role
version: v7
metadata:
  name: devops
spec:
  allow:
    # Accès SSH
    node_labels:
      env: ["staging", "production"]
      team: ["platform"]
    logins: ["deploy", "app"]

    # Accès Kubernetes
    kubernetes_labels:
      env: ["staging"]
    kubernetes_groups: ["developers"]
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "*"
        verbs: ["get", "list", "watch", "exec"]
      - kind: deployment
        namespace: "app-*"
        name: "*"
        verbs: ["get", "list"]

    # Accès bases de données
    db_labels:
      env: ["staging"]
    db_names: ["app_staging", "analytics"]
    db_users: ["readonly", "app_user"]

    # Accès applications web
    app_labels:
      team: ["platform"]

    # Règles de session
    rules:
      - resources: [session]
        verbs: [list, read]

  deny:
    # Interdire l'accès aux nœuds de production en SSH root
    node_labels:
      env: ["production"]
    logins: ["root"]

  options:
    # Durée de session maximale
    max_session_ttl: 8h
    # Forcer MFA par session
    require_session_mfa: true
    # Enregistrement des sessions
    enhanced_recording:
      - command
      - network
    # Mode de forwarding SSH
    forward_agent: false
    # Port forwarding
    port_forwarding: false
    # Clipboard en RDP
    desktop_clipboard: false

# role-dba.yaml — Rôle pour les administrateurs de bases de données
kind: role
version: v7
metadata:
  name: dba
spec:
  allow:
    db_labels:
      env: ["staging", "production"]
      type: ["postgresql", "mysql"]
    db_names: ["*"]
    db_users: ["admin", "replication", "monitoring"]

    # Accès SSH limité aux serveurs de base de données
    node_labels:
      role: ["database"]
    logins: ["postgres", "mysql"]

  options:
    max_session_ttl: 4h
    require_session_mfa: true
    enhanced_recording:
      - command
      - network
      - disk

Le système RBAC de Teleport supporte plusieurs mécanismes avancés qui permettent une gestion fine des accès. Les labels dynamiques permettent de matcher les ressources en fonction de métadonnées qui peuvent évoluer dans le temps (par exemple, un label maintenance: true ajouté temporairement à un serveur). Les deny rules prennent toujours priorité sur les allow rules, permettant de créer des garde-fous impossibles à contourner même par accumulation de rôles permissifs. Les access requests permettent à un utilisateur de demander temporairement l'élévation de ses privilèges (par exemple, accès root en production pour un incident), avec un workflow d'approbation configurable via Slack, PagerDuty ou l'API. Cette fonctionnalité implémente le principe du Just-In-Time (JIT) access, considéré comme une best practice en matière de gestion des accès privilégiés.

Enregistrement et replay de sessions

L'enregistrement des sessions est l'une des fonctionnalités les plus différenciantes de Teleport, offrant un audit trail complet et rejouable de toutes les actions effectuées sur l'infrastructure. Contrairement à la simple journalisation des commandes (comme script ou auditd), Teleport enregistre l'intégralité de la session terminal — incluant les sorties, les timestamps, les redimensionnements de fenêtre et les métadonnées de connexion — dans un format qui peut être rejoué exactement comme la session originale. Pour les sessions Windows (RDP), Teleport capture les flux vidéo de bureau à distance. Pour les sessions Kubernetes, les commandes kubectl exec sont enregistrées avec le même niveau de détail.

# Replay d'une session SSH enregistrée
tsh play --proxy=teleport.example.com session-id-abc123

# Export d'une session au format asciicast (compatible asciinema)
tsh play --format=json session-id-abc123 > session.json

# Recherche dans les sessions enregistrées
tsh recordings ls --from=2026-04-01 --to=2026-04-29

# Filtrage par utilisateur et noeud
tsh recordings ls --user=alice --hostname=prod-web-01

Les sessions enregistrées sont stockées dans le backend de données configuré pour le Auth Service, avec la possibilité de configurer un stockage externe (Amazon S3, Google Cloud Storage, Azure Blob Storage) pour les déploiements à grande échelle. La durée de rétention des enregistrements est configurable et doit être alignée avec les exigences réglementaires de l'organisation. Pour les environnements soumis à PCI-DSS, par exemple, la conservation pendant au moins un an est requise. L'enhanced session recording, activé par les rôles RBAC, utilise des technologies de tracing noyau (BPF/eBPF) pour capturer des informations supplémentaires au-delà de la session terminal : les commandes exécutées (même celles lancées par des scripts), les connexions réseau établies, et les accès au système de fichiers. Ces données enrichissent considérablement les capacités d'investigation forensique, complémentant les approches de réponse rapide aux incidents.

Intégration SSO et fournisseurs d'identité

L'intégration avec les fournisseurs d'identité existants est un prérequis pour le déploiement de Teleport en entreprise. Teleport supporte les protocoles OIDC (OpenID Connect), SAML 2.0 et l'authentification GitHub pour l'édition Community. Cette intégration permet de centraliser la gestion des identités dans le système existant de l'organisation (Okta, Azure AD, Google Workspace, Keycloak, Auth0, OneLogin, PingFederate) et d'appliquer les politiques d'authentification déjà en place (MFA, accès conditionnel, gestion du cycle de vie des comptes).

# Configuration OIDC avec Okta
# teleport.yaml — section auth_service
auth_service:
  authentication:
    type: oidc
    second_factor: webauthn
    webauthn:
      rp_id: teleport.example.com

---
# connecteur-okta.yaml
kind: oidc
version: v3
metadata:
  name: okta
spec:
  issuer_url: "https://company.okta.com"
  client_id: "0oa1b2c3d4e5f6g7h8i9"
  client_secret: "SECRET_FROM_OKTA"
  redirect_url: "https://teleport.example.com:443/v1/webapi/oidc/callback"
  display: "Connexion Okta"
  scope: ["openid", "email", "profile", "groups"]
  claims_to_roles:
    - claim: "groups"
      value: "DevOps"
      roles: ["devops"]
    - claim: "groups"
      value: "DBA"
      roles: ["dba"]
    - claim: "groups"
      value: "Security"
      roles: ["security-auditor"]
    - claim: "groups"
      value: "Admins"
      roles: ["admin"]

# Configuration SAML avec Azure AD
kind: saml
version: v2
metadata:
  name: azure-ad
spec:
  display: "Connexion Azure AD"
  acs: "https://teleport.example.com/v1/webapi/saml/acs"
  entity_descriptor_url: "https://login.microsoftonline.com/TENANT_ID/federationmetadata/2007-06/federationmetadata.xml"
  attributes_to_roles:
    - name: "http://schemas.microsoft.com/ws/2008/06/identity/claims/groups"
      value: "OBJECT_ID_DEVOPS_GROUP"
      roles: ["devops"]
    - name: "http://schemas.microsoft.com/ws/2008/06/identity/claims/groups"
      value: "OBJECT_ID_ADMIN_GROUP"
      roles: ["admin"]

Le mapping entre les groupes du fournisseur d'identité et les rôles Teleport est un aspect crucial de la configuration SSO. Un mapping bien conçu garantit que les changements de groupe dans l'IdP (ajout ou retrait d'un employé d'une équipe) se répercutent automatiquement sur les accès Teleport, sans intervention manuelle. Il est recommandé de définir des groupes granulaires dans l'IdP plutôt que de mapper des groupes larges vers des rôles permissifs dans Teleport. Par exemple, plutôt qu'un groupe « Ingénieurs » mappé vers un rôle avec accès à tout, il est préférable de créer des groupes spécifiques (« Ingénieurs-Staging », « Ingénieurs-Production-Readonly ») mappés vers des rôles Teleport correspondants.

Déploiement self-hosted de Teleport

Le déploiement self-hosted de Teleport offre un contrôle total sur l'infrastructure d'accès, adapté aux organisations qui ne peuvent ou ne souhaitent pas utiliser un service SaaS pour la gestion de leurs accès privilégiés. Le déploiement peut s'effectuer sur des machines virtuelles, des instances cloud ou des conteneurs Kubernetes.

Installation sur Linux

# Installation via le dépôt APT officiel (Ubuntu/Debian)
curl https://deb.releases.teleport.dev/teleport-pubkey.asc | sudo apt-key add -
echo "deb https://apt.releases.teleport.dev/ubuntu $(lsb_release -cs) stable/v16" | \
  sudo tee /etc/apt/sources.list.d/teleport.list
sudo apt update
sudo apt install teleport

# Vérification de la version
teleport version

# Génération de la configuration initiale
sudo teleport configure --cluster-name=teleport.example.com \
  --public-addr=teleport.example.com:443 \
  --cert-file=/etc/letsencrypt/live/teleport.example.com/fullchain.pem \
  --key-file=/etc/letsencrypt/live/teleport.example.com/privkey.pem \
  --output-file=/etc/teleport.yaml

Configuration teleport.yaml

# /etc/teleport.yaml — Configuration complète
version: v3
teleport:
  nodename: teleport-auth-01
  data_dir: /var/lib/teleport
  log:
    output: stderr
    severity: INFO
    format:
      output: json

  # Backend de stockage
  storage:
    type: postgresql
    conn_string: "postgres://teleport:password@db.internal:5432/teleport?sslmode=verify-full"
    # Audit events storage
    audit_events_uri:
      - "postgresql://teleport:password@db.internal:5432/teleport_audit?sslmode=verify-full"
    # Session recordings storage
    audit_sessions_uri: "s3://teleport-sessions-bucket/recordings?region=eu-west-1"

auth_service:
  enabled: true
  listen_addr: 0.0.0.0:3025
  cluster_name: teleport.example.com
  authentication:
    type: oidc
    second_factor: webauthn
    webauthn:
      rp_id: teleport.example.com
    locking_mode: best_effort

  # Session recording mode
  session_recording:
    mode: node  # node, proxy, or off
    proxy_checks_host_keys: true

  # Token pour l'enregistrement des agents
  tokens:
    - "node:TOKEN_FOR_SSH_NODES"
    - "kube:TOKEN_FOR_K8S_AGENTS"
    - "db:TOKEN_FOR_DB_AGENTS"
    - "app:TOKEN_FOR_APP_AGENTS"

proxy_service:
  enabled: true
  listen_addr: 0.0.0.0:3023
  web_listen_addr: 0.0.0.0:443
  tunnel_listen_addr: 0.0.0.0:3024
  public_addr: teleport.example.com:443
  https_cert_file: /etc/letsencrypt/live/teleport.example.com/fullchain.pem
  https_key_file: /etc/letsencrypt/live/teleport.example.com/privkey.pem
  acme:
    enabled: false  # Utilisation de certificats Let's Encrypt gérés manuellement

ssh_service:
  enabled: false  # Désactivé sur le serveur Auth/Proxy

Déploiement sur Kubernetes via Helm

# Ajout du dépôt Helm Teleport
helm repo add teleport https://charts.releases.teleport.dev
helm repo update

# Installation du cluster Teleport
helm install teleport-cluster teleport/teleport-cluster \
  --namespace teleport \
  --create-namespace \
  --set clusterName=teleport.example.com \
  --set acme=true \
  --set acmeEmail=admin@example.com \
  --set enterprise=false \
  --set highAvailability.replicaCount=2 \
  --set highAvailability.certManager.enabled=true \
  --values values.yaml

# values.yaml
chartMode: standalone
clusterName: teleport.example.com
proxyListenerMode: multiplex
persistence:
  enabled: true
  storageClassName: gp3
  volumeSize: 50Gi
authentication:
  type: oidc
  secondFactor: webauthn
resources:
  requests:
    cpu: 500m
    memory: 1Gi
  limits:
    cpu: 2000m
    memory: 4Gi

Enregistrement d'un agent SSH

# Sur le serveur cible
sudo apt install teleport

# Configuration de l'agent
sudo teleport node configure \
  --token=TOKEN_FOR_SSH_NODES \
  --auth-server=teleport.example.com:443 \
  --node-name=prod-web-01 \
  --labels="env=production,role=web,team=platform" \
  --output-file=/etc/teleport.yaml

# Démarrage du service
sudo systemctl enable teleport
sudo systemctl start teleport

# Vérification de l'enregistrement
tctl nodes ls

Architecture de déploiement recommandée :

Séparer le Auth Service et le Proxy Service sur des machines distinctes pour la sécurité et la scalabilité
Déployer au minimum 2 instances Proxy Service derrière un load balancer pour la haute disponibilité
Utiliser un backend de stockage distribué (etcd, DynamoDB, PostgreSQL) pour le Auth Service en production
Stocker les enregistrements de sessions sur un stockage objet externe (S3, GCS) pour la durabilité et la conformité
Utiliser des certificats TLS émis par une CA publique (Let's Encrypt) pour le Proxy Service
Configurer des tokens d'enregistrement distincts pour chaque type d'agent avec une rotation régulière

Utilisation quotidienne avec tsh et tctl

L'interaction quotidienne avec Teleport s'effectue principalement via deux outils en ligne de commande : tsh (Teleport Shell) pour les utilisateurs finaux et tctl (Teleport Control) pour les administrateurs. La maîtrise de ces outils est essentielle pour une utilisation efficace de la plateforme.

Commandes tsh essentielles

# Authentification
tsh login --proxy=teleport.example.com
tsh login --proxy=teleport.example.com --auth=okta  # SSO spécifique

# Statut de la session
tsh status

# Liste des nœuds SSH accessibles
tsh ls
tsh ls --labels="env=production"
tsh ls --search="web"

# Connexion SSH
tsh ssh user@prod-web-01
tsh ssh --labels="env=staging,role=web" user@  # Connexion par labels

# SCP (transfert de fichiers)
tsh scp local-file.txt user@prod-web-01:/tmp/
tsh scp user@prod-web-01:/var/log/app.log ./

# Port forwarding (si autorisé par le rôle)
tsh ssh -L 5432:localhost:5432 user@db-server

# Accès Kubernetes
tsh kube ls                          # Liste des clusters K8s
tsh kube login staging-cluster       # Switch de contexte K8s
kubectl get pods -n app              # kubectl fonctionne normalement

# Accès bases de données
tsh db ls                            # Liste des bases accessibles
tsh db login --db-user=readonly --db-name=analytics staging-postgres
tsh db connect staging-postgres      # Connexion interactive

# Accès applications web
tsh apps ls
tsh apps login grafana-internal
# Ouvre automatiquement le navigateur avec auth proxy

# Accès Windows Desktop
tsh desktop ls
tsh desktop login --window-desktop=win-server-01 --user=admin

# Demande d'accès élevé (JIT)
tsh request create --roles=prod-admin --reason="Incident INC-2026-0429"
tsh request ls
tsh login --request-id=request-abc123

Commandes tctl administratives

# Gestion des nœuds
tctl nodes ls
tctl nodes add --roles=node --token=TOKEN

# Gestion des rôles
tctl create -f role-devops.yaml
tctl get roles
tctl get role/devops -o yaml

# Gestion des utilisateurs
tctl users ls
tctl users add alice --roles=devops,dba --logins=deploy,app
tctl users reset alice  # Réinitialiser MFA

# Gestion des tokens d'enregistrement
tctl tokens add --type=node --ttl=1h
tctl tokens ls

# Gestion des connecteurs SSO
tctl create -f connector-okta.yaml
tctl get oidc

# Gestion des locks (verrouillage d'accès d'urgence)
tctl lock --user=alice --message="Compte compromis" --ttl=24h
tctl lock --node=prod-web-01 --message="Maintenance" --ttl=4h

# Audit
tctl get events --from=2026-04-28 --to=2026-04-29 --type=session.start

# Configuration du cluster
tctl get cluster_networking_config
tctl get session_recording_config

Audit logging et conformité

Le système d'audit de Teleport génère des événements structurés pour chaque action significative : authentifications, accès aux ressources, commandes exécutées, modifications de configuration, et erreurs d'autorisation. Ces événements sont stockés dans le backend de données du Auth Service et peuvent être exportés vers des systèmes SIEM externes (Splunk, Elastic, Datadog, Sumo Logic) pour une corrélation avec d'autres sources de données de sécurité.

# Exemple d'événement d'audit (JSON)
{
  "event": "session.start",
  "code": "T2000I",
  "time": "2026-04-29T10:15:23.456Z",
  "uid": "event-uuid-123",
  "user": "alice@example.com",
  "login": "deploy",
  "server_id": "node-uuid-456",
  "server_hostname": "prod-web-01",
  "server_labels": {
    "env": "production",
    "role": "web"
  },
  "session_id": "session-uuid-789",
  "server_addr": "10.0.1.50:3022",
  "client_addr": "192.168.1.100:54321",
  "cluster_name": "teleport.example.com",
  "mfa_device": {
    "name": "yubikey-alice",
    "type": "webauthn"
  },
  "access_requests": ["request-abc123"]
}

Les types d'événements d'audit couvrent l'ensemble du cycle de vie des accès : user.login (authentification réussie ou échouée), session.start / session.end (début et fin de session), session.command (commande exécutée en mode enhanced recording), session.network (connexion réseau établie depuis une session), db.session.start (connexion à une base de données), kube.request (requête API Kubernetes), access_request.create / access_request.approve (workflow d'élévation de privilèges), et user.create / role.create (modifications de configuration). La richesse de ces événements permet de répondre aux questions d'audit les plus courantes : qui a accédé à quoi, quand, depuis où, avec quels privilèges, et quelles actions ont été effectuées. Cette granularité est un atout majeur pour la conformité SOC 2, PCI-DSS, HIPAA et RGPD.

Access Requests : élévation de privilèges Just-In-Time

Le système d'Access Requests de Teleport implémente le principe du Just-In-Time (JIT) access, permettant aux utilisateurs de demander temporairement des privilèges élevés avec un workflow d'approbation configurable. Cette fonctionnalité est fondamentale pour les environnements de production où l'accès permanent à des rôles privilégiés est contraire aux bonnes pratiques de sécurité.

# Configuration des Access Requests dans un rôle
kind: role
version: v7
metadata:
  name: devops-with-escalation
spec:
  allow:
    # ... permissions normales ...
    request:
      roles: ["prod-admin", "prod-dba"]
      max_duration: 4h
      # Suggestions de raisons prédéfinies
      suggested_reviewers: ["security-team"]
      thresholds:
        - approve: 1  # Un seul approbateur suffit
          deny: 1
      annotations:
        teleport.dev/teams: ["security-oncall"]

---
# Rôle pour les approbateurs
kind: role
version: v7
metadata:
  name: access-approver
spec:
  allow:
    review_requests:
      roles: ["prod-admin", "prod-dba"]
      where: 'contains(request.suggested_reviewers, "security-team")'

L'intégration avec Slack est particulièrement populaire pour les workflows d'Access Request, permettant aux approbateurs de recevoir une notification avec les détails de la demande et d'approuver ou refuser directement depuis l'interface Slack via des boutons interactifs. Cette intégration réduit considérablement le temps de réponse pour les demandes d'accès d'urgence lors d'incidents de production, tout en maintenant un audit trail complet de chaque décision d'approbation.

Teleport pour Kubernetes

L'accès Kubernetes via Teleport offre plusieurs avantages par rapport à l'utilisation directe de kubeconfig et de tokens Kubernetes : l'authentification centralisée via SSO, le RBAC unifié avec les autres types de ressources, l'enregistrement des sessions kubectl exec, et l'élimination de la distribution de kubeconfigs statiques. L'agent Kubernetes de Teleport s'installe dans le cluster cible et s'enregistre auprès du Auth Service, permettant l'accès via le Proxy Service sans exposition directe de l'API server Kubernetes.

# Déploiement de l'agent Kubernetes
helm install teleport-kube-agent teleport/teleport-kube-agent \
  --namespace teleport \
  --create-namespace \
  --set proxyAddr=teleport.example.com:443 \
  --set authToken=TOKEN_FOR_K8S_AGENTS \
  --set kubeClusterName=production-cluster \
  --set labels.env=production \
  --set labels.region=eu-west-1

# Utilisation via tsh
tsh kube ls                                    # Liste des clusters
tsh kube login production-cluster              # Sélection du cluster
kubectl get pods -n app                        # Commandes kubectl normales
kubectl exec -it pod-name -n app -- /bin/bash  # Session enregistrée
tsh kube sessions                              # Sessions actives

Un aspect technique important est que Teleport ne remplace pas le RBAC natif de Kubernetes mais s'y superpose. Les rôles Teleport définissent quels groups et users Kubernetes sont simulés dans le certificat présenté à l'API server, et le RBAC Kubernetes natif (ClusterRoles, RoleBindings) s'applique ensuite normalement. Cette superposition permet une granularité maximale : Teleport contrôle qui peut accéder au cluster, et le RBAC Kubernetes contrôle ce que l'utilisateur peut faire dans le cluster.

Teleport pour les bases de données

L'accès aux bases de données via Teleport élimine la nécessité de distribuer des mots de passe ou des chaînes de connexion aux utilisateurs. L'agent de base de données de Teleport agit comme un proxy qui authentifie les utilisateurs via leurs certificats Teleport et établit la connexion à la base de données en utilisant des credentials gérés côté serveur. Les bases de données supportées incluent PostgreSQL, MySQL/MariaDB, MongoDB, Redis, Microsoft SQL Server, CockroachDB, Elasticsearch, Cassandra, DynamoDB et Snowflake.

# Configuration de l'agent de base de données
# /etc/teleport.yaml sur le serveur d'agent DB
db_service:
  enabled: true
  databases:
    - name: "production-postgres"
      protocol: "postgres"
      uri: "db-prod.internal:5432"
      labels:
        env: "production"
        type: "postgresql"
      static_labels:
        department: "engineering"
      tls:
        mode: verify-full
        ca_cert_file: /etc/teleport/db-ca.pem

    - name: "staging-mysql"
      protocol: "mysql"
      uri: "db-staging.internal:3306"
      labels:
        env: "staging"
        type: "mysql"

    - name: "analytics-mongodb"
      protocol: "mongodb"
      uri: "mongodb://mongo-analytics.internal:27017"
      labels:
        env: "production"
        type: "mongodb"

# Connexion via tsh
tsh db ls
tsh db login --db-user=readonly --db-name=analytics production-postgres
tsh db connect production-postgres  # Lance psql avec auth par certificat

# Utilisation avec des outils GUI (DBeaver, pgAdmin...)
tsh proxy db --port=15432 production-postgres
# Puis connecter l'outil GUI à localhost:15432

L'audit des sessions de base de données capture les requêtes SQL exécutées, permettant une traçabilité complète des accès aux données. Pour les environnements soumis à PCI-DSS ou RGPD, cette fonctionnalité est particulièrement précieuse car elle permet de démontrer qui a accédé à quelles données, quand et avec quels privilèges. Les requêtes SQL sont loguées dans l'audit trail avec les métadonnées de la session (utilisateur, base de données, horodatage), fournissant un historique complet exploitable pour les investigations de sécurité et les audits de conformité.

Teleport Cloud vs Self-Hosted : quel modèle choisir ?

Critère	Teleport Community (OSS)	Teleport Enterprise	Teleport Cloud
Hébergement	Self-hosted	Self-hosted	SaaS (Teleport géré)
Coût	Gratuit	Licence commerciale	Par utilisateur/mois
SSO / OIDC / SAML	GitHub uniquement	Complet	Complet
Access Requests	Basique	Complet (Slack, PagerDuty)	Complet
FedRAMP / FIPS	Non	Oui	Oui (FedRAMP Moderate)
HSM Support	Non	Oui	Oui (managed)
Support	Communauté	SLA commercial	SLA commercial
Maintenance infra	À votre charge	À votre charge	Gérée par Teleport
HA / Scalabilité	Manuel	Manuel avec support	Automatique
Device Trust	Non	Oui	Oui

Le choix entre les trois modèles dépend principalement de la taille de l'organisation, des exigences réglementaires et des ressources opérationnelles disponibles. Teleport Community est adapté aux petites équipes et aux projets personnels, offrant les fonctionnalités de base (SSH, K8s, DB, apps) avec l'authentification GitHub pour le SSO. Teleport Enterprise s'adresse aux organisations qui ont besoin d'intégrations SSO complètes (OIDC/SAML), de workflows d'Access Request avancés, de conformité FedRAMP/FIPS, et d'un support commercial avec SLA. Teleport Cloud élimine la charge opérationnelle de gestion de l'infrastructure Teleport elle-même, permettant à l'équipe de se concentrer sur la configuration des politiques d'accès plutôt que sur la maintenance des serveurs Auth et Proxy.

Hardening et bonnes pratiques de sécurité

Le déploiement de Teleport en production nécessite l'application de mesures de durcissement spécifiques pour maximiser la posture de sécurité de la plateforme.

Checklist de hardening Teleport :

MFA obligatoire : activer second_factor: webauthn pour tous les utilisateurs, idéalement avec des clés matérielles (YubiKey)
TTL de certificats courts : réduire max_session_ttl à 4-8h pour les rôles standard et à 1-2h pour les rôles privilégiés
Per-session MFA : activer require_session_mfa: true pour les rôles accédant à des ressources sensibles
Locks d'urgence : documenter la procédure de lock d'un utilisateur ou d'un nœud compromis via tctl lock
Enhanced recording : activer l'enregistrement BPF/eBPF pour capturer les commandes, réseau et accès fichiers
Rotation des CA : planifier la rotation des autorités de certification Teleport (procédure tctl auth rotate)
Isolation réseau : le Auth Service ne doit jamais être exposé directement sur Internet — seul le Proxy Service est public
Chiffrement du backend : utiliser le chiffrement au repos pour la base de données backend et le stockage S3 des sessions
Audit log monitoring : configurer des alertes SIEM sur les événements d'authentification échouée et les accès anormaux

# Rotation de la CA Teleport
# Étape 1: Initier la rotation (mode graceful)
tctl auth rotate --phase=init --type=user --grace-period=48h

# Étape 2: Mettre à jour les agents (les deux CA sont valides pendant la grace period)
tctl auth rotate --phase=update_clients --type=user

# Étape 3: Mettre à jour les serveurs
tctl auth rotate --phase=update_servers --type=user

# Étape 4: Finaliser (l'ancienne CA est révoquée)
tctl auth rotate --phase=standby --type=user

# Vérification
tctl auth export --type=user  # Exporte la CA publique actuelle

Teleport vs solutions concurrentes

Teleport se positionne dans un écosystème qui inclut plusieurs solutions d'accès sécurisé, chacune avec ses forces et ses faiblesses spécifiques. Les alternatives les plus couramment comparées sont HashiCorp Boundary, StrongDM, CyberArk, BeyondTrust et les solutions SSH basiques (OpenSSH + bastion hosts).

Critère	Teleport	HashiCorp Boundary	StrongDM	Bastion SSH traditionnel
Open source	Oui (Community)	Oui (Community)	Non	Oui
SSH + K8s + DB + Apps	Tout intégré	SSH + DB (apps limité)	Tout intégré	SSH uniquement
Session recording	Complet + replay	Non natif	Complet	Script/auditd
Certificats éphémères	Oui (natif)	Non (délégué à Vault)	Oui	Non
Access Requests JIT	Oui	Non natif	Oui	Non
Complexité	Moyenne	Moyenne-haute	Faible (SaaS)	Faible
Agent required	Oui	Non (agentless)	Oui	Non

La principale force de Teleport par rapport à Boundary est l'intégration native de l'enregistrement de sessions, des certificats éphémères et du support étendu des types de ressources. Boundary adopte une approche plus modulaire, s'appuyant sur HashiCorp Vault pour la gestion des secrets et des credentials dynamiques, ce qui offre plus de flexibilité mais nécessite le déploiement et la maintenance de composants supplémentaires. StrongDM est le concurrent SaaS le plus direct, offrant des fonctionnalités similaires dans un modèle entièrement géré, mais sans option self-hosted ni version open source. Pour les organisations qui privilégient la souveraineté et le contrôle total sur leur infrastructure d'accès, Teleport offre le meilleur compromis entre fonctionnalités et contrôle.

Cas d'usage avancés

Multi-cluster et Trusted Clusters

Pour les organisations disposant de plusieurs clusters Teleport (par région, par environnement ou par filiale), la fonctionnalité de Trusted Clusters permet d'établir des relations de confiance entre clusters, permettant aux utilisateurs d'un cluster d'accéder aux ressources d'un autre sans nouvelle authentification. Cette fonctionnalité est particulièrement utile dans les architectures multi-régions où un cluster Teleport est déployé dans chaque zone géographique pour minimiser la latence, tout en maintenant une gouvernance centralisée des accès.

Machine ID : identités pour les services

Machine ID est une fonctionnalité de Teleport qui étend le modèle de certificats éphémères aux services et aux machines, remplaçant les tokens statiques et les API keys par des certificats à durée de vie courte. Les CI/CD pipelines, les scripts d'automatisation, les outils de monitoring et les services internes peuvent obtenir des certificats Teleport pour accéder aux ressources de manière sécurisée et auditée, sans nécessiter de credentials statiques. Cette approche s'aligne avec les pratiques de sécurisation des clés API dans les pipelines, en éliminant le risque de fuite de secrets statiques.

# Configuration Machine ID (tbot)
# /etc/tbot.yaml
version: v2
proxy_server: teleport.example.com:443
onboarding:
  join_method: token
  token: machine-id-token
storage:
  type: directory
  path: /var/lib/tbot
outputs:
  - type: identity
    destination:
      type: directory
      path: /opt/machine-id/identity
  - type: ssh_host
    destination:
      type: directory
      path: /opt/machine-id/ssh
  - type: database
    destination:
      type: directory
      path: /opt/machine-id/db
    service: production-postgres
    database: app_db
    username: ci_user

Device Trust

Le Device Trust (Enterprise et Cloud uniquement) ajoute une vérification de l'identité du dispositif en complément de l'identité de l'utilisateur. Avant d'émettre un certificat, Teleport vérifie que le dispositif de l'utilisateur est enregistré et conforme aux politiques de l'organisation (OS à jour, disque chiffré, TPM présent). Cette fonctionnalité implémente le principe « ne jamais faire confiance à un dispositif non vérifié » et est particulièrement pertinente dans les environnements BYOD ou pour les collaborateurs distants accédant à des ressources sensibles.

Questions fréquentes sur Teleport

Teleport peut-il remplacer un VPN pour l'accès distant ?

Teleport peut remplacer un VPN pour l'accès aux serveurs SSH, aux clusters Kubernetes, aux bases de données et aux applications web internes. Cependant, il ne remplace pas un VPN pour l'accès réseau complet (partage de fichiers SMB, applications non-web, protocoles non supportés). Dans la plupart des environnements modernes, Teleport couvre la majorité des cas d'usage d'accès distant pour les ingénieurs et les administrateurs, et sa sécurité supérieure (certificats éphémères, MFA par session, audit complet) en fait un remplacement préférable au VPN pour ces cas d'usage. Pour les cas d'usage restants, un VPN complémentaire peut être maintenu avec une couverture réduite.

Comment fonctionne l'enregistrement des sessions sans impact sur les performances ?

L'enregistrement des sessions Teleport utilise un mécanisme de buffering asynchrone qui minimise l'impact sur la latence des sessions. Les données de session sont d'abord écrites dans un buffer local sur le nœud où la session est exécutée, puis transmises de manière asynchrone au Auth Service pour le stockage persistant. Ce mécanisme garantit que l'enregistrement n'introduit pas de latence perceptible dans la session interactive. Pour l'enhanced session recording (BPF/eBPF), l'overhead est de l'ordre de 1 à 3% d'utilisation CPU, ce qui est généralement négligeable sur les serveurs de production modernes.

Quelle est la taille maximale d'un déploiement Teleport ?

Teleport est conçu pour s'adapter à des déploiements de toute taille, de quelques serveurs à des dizaines de milliers de nœuds. Les plus grands déploiements publiquement documentés gèrent plus de 10 000 nœuds avec des milliers d'utilisateurs simultanés. La scalabilité est assurée par le déploiement horizontal des Proxy Services et par l'utilisation de backends de stockage distribués (etcd en cluster, DynamoDB, PostgreSQL avec réplication). Le Auth Service est le composant le plus critique en termes de performance, et il est recommandé de le dimensionner en fonction du nombre de certificats émis par minute (typiquement 1 vCPU et 2 Go de RAM pour jusqu'à 100 émissions par minute).

Teleport est-il compatible avec les outils existants (Ansible, Terraform, kubectl) ?

Teleport est conçu pour être transparent vis-à-vis des outils existants. Après un tsh login, les certificats sont stockés dans le répertoire ~/.tsh/ et le client SSH standard (ssh) est automatiquement configuré via un ssh_config généré par Teleport. Ansible, Terraform, scp, rsync et tout outil utilisant SSH fonctionnent sans modification. Pour Kubernetes, tsh kube login configure le contexte kubectl de manière transparente. Pour les bases de données, tsh proxy db crée un proxy local auquel les outils GUI (DBeaver, pgAdmin, DataGrip) peuvent se connecter normalement.

Comment gérer la haute disponibilité du Auth Service ?

La haute disponibilité du Auth Service s'obtient en déployant plusieurs instances partageant le même backend de stockage distribué. En mode etcd, les instances Auth forment un cluster raft avec un leader et des followers, assurant une cohérence forte et un basculement automatique en cas de défaillance du leader. En mode DynamoDB ou PostgreSQL, les instances sont stateless (la cohérence est déléguée au backend) et peuvent être déployées derrière un load balancer interne. Il est recommandé de déployer au minimum trois instances Auth en production pour tolérer la perte d'une instance sans interruption de service.

Quel est l'impact de Teleport sur la latence des connexions SSH ?

Teleport ajoute une latence marginale aux connexions SSH, principalement due au routage via le Proxy Service et à la vérification des certificats par le Auth Service lors de l'établissement de la connexion. En pratique, cette latence supplémentaire est de l'ordre de 10 à 50 millisecondes pour l'établissement de la connexion initiale, et négligeable une fois la session établie (le trafic est routé directement via le reverse tunnel sans traitement applicatif). Pour les cas d'usage sensibles à la latence (transferts de fichiers volumineux, sessions interactives à haut débit), le mode d'enregistrement « proxy » (qui enregistre au niveau du Proxy plutôt qu'au niveau du nœud) peut être préférable car il élimine le buffer d'enregistrement côté nœud.

Comment migrer depuis un bastion SSH traditionnel vers Teleport ?

La migration depuis un bastion SSH traditionnel vers Teleport peut être réalisée de manière progressive, sans interruption de service. La première étape consiste à déployer le cluster Teleport (Auth + Proxy) et à configurer l'authentification SSO. Ensuite, les agents Teleport sont déployés sur les serveurs cibles en parallèle des configurations SSH existantes — les deux moyens d'accès coexistent pendant la phase de transition. Les utilisateurs sont formés à l'utilisation de tsh et les politiques RBAC sont affinées. Une fois que tous les utilisateurs et les outils d'automatisation utilisent Teleport, les clés SSH statiques et le bastion traditionnel sont décommissionnés. Cette approche progressive minimise les risques et permet un retour arrière si nécessaire.

Teleport supporte-t-il l'accès aux serveurs Windows ?

Oui, Teleport supporte l'accès aux Windows Desktop via le protocole RDP, sans nécessiter l'installation d'un client RDP côté utilisateur. L'accès s'effectue directement via le navigateur web, avec l'authentification Teleport standard (SSO + MFA). L'intégration avec Active Directory permet de mapper les groupes AD vers les rôles Teleport et d'utiliser les comptes AD existants pour l'accès aux bureaux Windows. Les sessions Windows sont enregistrées au format vidéo et peuvent être rejouées via l'interface web Teleport, offrant le même niveau d'audit que les sessions SSH. Cette fonctionnalité élimine la nécessité de solutions RDP gateway dédiées et centralise l'accès à tous les types de ressources dans une seule plateforme.

Conclusion et recommandations

Teleport s'est imposé comme l'une des solutions les plus complètes et les plus matures pour l'implémentation d'un access plane Zero Trust unifié. En remplaçant les credentials statiques par des certificats éphémères, en centralisant l'authentification via SSO, en imposant un RBAC granulaire et en enregistrant l'intégralité des sessions pour l'audit, Teleport adresse les lacunes fondamentales des approches traditionnelles de gestion des accès. La plateforme excelle particulièrement dans les environnements cloud-native et distribués, où la gestion manuelle des clés SSH, des kubeconfigs et des mots de passe de bases de données devient rapidement ingérable et constitue un risque de sécurité majeur. Pour les organisations engagées dans une démarche Zero Trust ou soumises à des exigences de conformité strictes (SOC 2, PCI-DSS, HIPAA), Teleport offre une solution qui réduit simultanément la surface d'attaque et la charge opérationnelle de gestion des accès. La disponibilité d'une version open source permet une évaluation approfondie avant un engagement commercial, et l'option Teleport Cloud élimine la charge de maintenance pour les équipes aux ressources limitées. En complément des stratégies de protection contre les ransomwares et de scanning de vulnérabilités, Teleport constitue une brique essentielle d'une infrastructure de sécurité moderne.

Architecture réseau et connectivité de Teleport

La compréhension détaillée de l'architecture réseau de Teleport est fondamentale pour planifier un déploiement réussi, optimiser les performances et diagnostiquer les problèmes de connectivité. Teleport utilise un modèle de connectivité basé sur des reverse tunnels : les agents (nœuds SSH, agents Kubernetes, agents base de données) initient des connexions sortantes vers le Proxy Service, et ces connexions persistantes servent de canaux bidirectionnels pour le trafic utilisateur. Ce modèle élimine la nécessité d'ouvrir des ports entrants sur les machines protégées par Teleport, ce qui est un avantage opérationnel et sécuritaire majeur, particulièrement dans les environnements cloud et hybrides où les machines sont souvent derrière des NAT, des pare-feu restrictifs ou des groupes de sécurité cloud.

Le Proxy Service expose un nombre limité de ports sur Internet : le port 443 pour l'interface web et les connexions HTTPS (incluant les connexions WebSocket pour le terminal web), le port 3023 pour les connexions SSH directes via tsh ssh, le port 3024 pour les reverse tunnels des agents, et le port 3026 pour les connexions MySQL/PostgreSQL directes. En mode multiplex (recommandé pour les déploiements modernes), tous ces services peuvent être multiplexés sur un seul port (443), utilisant le protocole ALPN (Application-Layer Protocol Negotiation) pour distinguer les types de connexion. Ce mode simplifie considérablement la configuration réseau car un seul port doit être ouvert et un seul certificat TLS est nécessaire.

# Configuration multiplex (un seul port pour tout)
proxy_service:
  enabled: true
  web_listen_addr: 0.0.0.0:443
  public_addr: teleport.example.com:443
  tunnel_listen_addr: 0.0.0.0:443
  mysql_listen_addr: 0.0.0.0:443
  postgres_listen_addr: 0.0.0.0:443

# Configuration du load balancer (HAProxy) en mode multiplex
# haproxy.cfg
frontend teleport
    bind *:443
    mode tcp
    option tcplog
    default_backend teleport_proxy

backend teleport_proxy
    mode tcp
    balance roundrobin
    option tcp-check
    server proxy1 10.0.1.10:443 check
    server proxy2 10.0.1.11:443 check

La latence réseau entre les composants Teleport affecte directement l'expérience utilisateur et doit être prise en compte lors du placement des services. Le Auth Service et le Proxy Service doivent idéalement être déployés dans la même région cloud ou le même centre de données pour minimiser la latence d'émission des certificats (qui se produit à chaque authentification). Les agents sur les nœuds cibles se connectent au Proxy Service via Internet, et la latence de cette connexion détermine la latence initiale de connexion SSH ou base de données. Pour les agents situés dans des régions géographiquement distantes du Proxy Service, le déploiement de Proxy Services régionaux connectés au même Auth Service central permet de réduire la latence perçue par les utilisateurs locaux.

Gestion avancée des labels et de la découverte de ressources

Le système de labels de Teleport est le mécanisme principal pour organiser les ressources et appliquer des politiques d'accès granulaires. Les labels peuvent être statiques (définis dans la configuration de l'agent et constants) ou dynamiques (calculés périodiquement par des commandes système). Les labels dynamiques sont particulièrement puissants car ils permettent d'adapter automatiquement les politiques d'accès en fonction de l'état réel des ressources.

# Configuration d'un nœud SSH avec labels statiques et dynamiques
ssh_service:
  enabled: true
  labels:
    # Labels statiques
    env: production
    role: web
    team: platform
    region: eu-west-1
    os: ubuntu-22.04

  commands:
    # Labels dynamiques — recalculés périodiquement
    - name: kernel
      command: ["/bin/uname", "-r"]
      period: 24h

    - name: uptime_days
      command: ["/bin/bash", "-c", "echo $(( $(cat /proc/uptime | cut -d. -f1) / 86400 ))"]
      period: 1h

    - name: disk_usage_percent
      command: ["/bin/bash", "-c", "df / | tail -1 | awk '{print $5}' | tr -d '%'"]
      period: 5m

    - name: patch_status
      command: ["/bin/bash", "-c", "if [ -f /var/run/reboot-required ]; then echo needs-reboot; else echo up-to-date; fi"]
      period: 30m

    - name: security_updates
      command: ["/bin/bash", "-c", "apt list --upgradable 2>/dev/null | grep -c security || echo 0"]
      period: 6h

Les labels dynamiques ouvrent des possibilités intéressantes pour la sécurité : un rôle RBAC peut être configuré pour refuser l'accès aux serveurs dont le label patch_status est needs-reboot, forçant l'application des correctifs avant que les ingénieurs puissent accéder à la machine. De même, un label disk_usage_percent supérieur à 90 peut déclencher une alerte et une restriction d'accès préventive. Cette approche « policy as code » permet d'automatiser l'application de règles de sécurité qui seraient autrement gérées manuellement.

La découverte automatique de ressources est une fonctionnalité complémentaire aux labels, disponible dans Teleport Enterprise et Cloud. Le Discovery Service de Teleport peut scanner automatiquement les comptes AWS, GCP et Azure pour détecter les instances EC2, les clusters EKS/GKE/AKS, les instances RDS/Aurora et d'autres ressources cloud, et les enregistrer automatiquement dans Teleport avec des labels correspondant à leurs tags cloud. Cette découverte automatique élimine le besoin de déployer manuellement un agent sur chaque nouvelle ressource et garantit que la base de données Teleport reflète toujours l'état réel de l'infrastructure cloud.

Teleport et la conformité réglementaire

Teleport est conçu pour faciliter la conformité avec les principaux frameworks réglementaires et standards de sécurité. L'audit trail complet, l'enregistrement des sessions, le RBAC granulaire et l'authentification forte constituent les fondations sur lesquelles s'appuient les contrôles de conformité. Voici une correspondance détaillée entre les fonctionnalités de Teleport et les exigences des principaux standards.

Standard	Exigence	Fonctionnalité Teleport
SOC 2	Contrôle d'accès logique	RBAC avec deny rules, certificats éphémères
SOC 2	Journalisation des accès	Audit log structuré, enregistrement de sessions
SOC 2	Revue des accès	tctl pour la revue des rôles et des accès actifs
PCI-DSS	Req. 7 : Moindre privilège	RBAC granulaire, Access Requests JIT
PCI-DSS	Req. 8 : Auth forte	MFA obligatoire, certificats éphémères, SSO
PCI-DSS	Req. 10 : Audit des accès données	Session recording DB, audit SQL queries
HIPAA	Contrôle d'accès (164.312a)	RBAC, certificats éphémères, revue périodique
HIPAA	Audit (164.312b)	Audit log avec rétention configurable, S3 archiving
RGPD	Minimisation des accès	Moindre privilège via RBAC, JIT access
RGPD	Traçabilité des traitements	Audit log complet avec identité, timestamp, action
FedRAMP	FIPS 140-2 crypto	Teleport Enterprise avec module FIPS

Pour les organisations soumises à des audits réguliers, Teleport fournit des outils d'export des données d'audit dans des formats compatibles avec les outils d'analyse de conformité. Les événements d'audit peuvent être exportés en JSON ou en CSV, filtrés par période, utilisateur, type d'événement ou ressource. L'intégration avec les systèmes SIEM permet une surveillance continue et la génération automatique de rapports de conformité. L'architecture de Teleport elle-même peut être documentée comme un contrôle technique dans les dossiers de conformité, démontrant l'implémentation des principes de moindre privilège, d'authentification forte et de traçabilité des accès.

Intégration avec les outils CI/CD et l'automatisation

L'intégration de Teleport avec les pipelines CI/CD est un cas d'usage majeur qui permet d'automatiser les déploiements tout en maintenant un audit trail complet et un contrôle d'accès granulaire. La fonctionnalité Machine ID (tbot) génère des certificats éphémères pour les services et les machines, remplaçant les tokens statiques, les clés SSH privées et les mots de passe de base de données stockés dans les secrets CI/CD.

# Intégration avec GitHub Actions via Machine ID
# .github/workflows/deploy.yml
name: Deploy to Production
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write  # Requis pour la join method JWT

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Install Teleport
        uses: teleport-actions/setup@v1
        with:
          version: 16.0.0

      - name: Authenticate with Teleport
        uses: teleport-actions/auth@v2
        with:
          proxy: teleport.example.com:443
          token: github-ci-token
          certificate-ttl: 15m

      - name: Deploy via SSH
        run: |
          tsh ssh deploy@prod-web-01 "cd /app && git pull && systemctl restart app"

      - name: Run database migrations
        run: |
          tsh db connect production-postgres -- \
            psql -f migrations/latest.sql

# Configuration du bot Teleport pour GitHub Actions
# tctl create -f github-bot.yaml
kind: bot
version: v1
metadata:
  name: github-ci
spec:
  roles: ["ci-deploy"]
  token:
    name: github-ci-token
    join_method: github
    github:
      allow:
        - repository: "org/repo"
          ref: "refs/heads/main"

L'utilisation de la join method GitHub est particulièrement élégante car elle élimine la nécessité de stocker des tokens Teleport dans les secrets GitHub Actions. Le runner CI s'authentifie auprès de Teleport en présentant un JWT émis par GitHub, que Teleport vérifie en consultant la clé publique de GitHub. Ce mécanisme est analogue à l'IRSA (IAM Roles for Service Accounts) d'AWS ou au Workload Identity de GCP, appliqué à l'accès infrastructure. Les certificats émis pour le CI ont une durée de vie très courte (15 minutes typiquement), minimisant l'impact d'une compromission éventuelle du runner CI.

Pour les outils d'automatisation comme Ansible, Terraform et Puppet, Teleport s'intègre de manière transparente. Après un tsh login ou l'activation d'un bot Machine ID, les certificats Teleport sont utilisés par les outils SSH standard sans modification. Ansible peut cibler les nœuds Teleport par leurs labels plutôt que par leurs adresses IP, en utilisant un inventaire dynamique qui interroge l'API Teleport pour lister les nœuds correspondant à des critères spécifiques. Terraform peut interagir avec l'API Teleport pour gérer les rôles, les utilisateurs et les tokens de manière déclarative, intégrant la configuration d'accès Teleport dans le workflow Infrastructure as Code global de l'organisation.

Performance et dimensionnement

Le dimensionnement correct d'un déploiement Teleport dépend de plusieurs facteurs : le nombre de nœuds enregistrés, le nombre d'utilisateurs simultanés, le volume de sessions actives, et le volume d'événements d'audit générés. Le Auth Service est le composant le plus sollicité car il gère l'émission de certificats, l'évaluation RBAC et le stockage de l'audit log. Le Proxy Service est le plus sensible à la bande passante car il route l'ensemble du trafic utilisateur.

Taille du déploiement	Nœuds	Utilisateurs	Auth Service	Proxy Service	Backend
Petit	< 100	< 50	2 vCPU / 4 Go	2 vCPU / 4 Go	SQLite
Moyen	100-1000	50-500	4 vCPU / 8 Go x2	4 vCPU / 8 Go x2	PostgreSQL
Grand	1000-10000	500-5000	8 vCPU / 16 Go x3	8 vCPU / 16 Go x3+	PostgreSQL HA
Très grand	> 10000	> 5000	16 vCPU / 32 Go x3	16 vCPU / 32 Go x5+	etcd cluster / DynamoDB

Pour les déploiements de grande taille, le backend de stockage est souvent le facteur limitant. etcd offre les meilleures performances pour les opérations de lecture/écriture fréquentes (émission de certificats, mise à jour des heartbeats des nœuds) mais nécessite un cluster de 3 ou 5 nœuds pour la haute disponibilité. DynamoDB est le choix recommandé pour les déploiements AWS car il offre une scalabilité automatique et une latence prévisible. PostgreSQL est le choix polyvalent qui convient à la majorité des déploiements, avec la possibilité d'utiliser des services managés (RDS, Cloud SQL, Azure Database) pour réduire la charge opérationnelle. Le stockage des enregistrements de sessions doit être externalisé vers un stockage objet (S3, GCS) dès que le volume dépasse quelques centaines de sessions par jour, car les enregistrements peuvent occuper plusieurs mégaoctets chacun.

Troubleshooting avancé

Le diagnostic des problèmes dans un déploiement Teleport nécessite une connaissance approfondie des interactions entre les composants et des outils de diagnostic disponibles. Les problèmes les plus fréquemment rencontrés concernent la connectivité des agents, l'émission de certificats, l'évaluation RBAC et les performances de l'enregistrement de sessions.

# Diagnostic de la connectivité d'un agent
# Depuis l'agent
teleport status                           # État du service
journalctl -u teleport -f --no-pager     # Logs en temps réel
teleport configure --test                  # Validation de la config

# Depuis le cluster
tctl nodes ls --verbose                   # Liste détaillée des nœuds
tctl get nodes/NODE_ID                    # Détails d'un nœud spécifique

# Diagnostic des certificats
tctl auth export --type=user              # Exporte la CA utilisateur
tctl auth export --type=host              # Exporte la CA hôte
tsh status                                # Vérifie le certificat local
tsh certs ls                              # Liste les certificats en cache

# Diagnostic RBAC
tctl access-request ls                    # Demandes d'accès en attente
tctl get roles                            # Liste tous les rôles
# Test d'accès hypothétique
tctl auth sign --user=alice --format=openssh --out=test-cert --ttl=1m
ssh-keygen -L -f test-cert-cert.pub      # Inspecter le certificat généré

# Diagnostic réseau
tctl get proxies                          # Proxy Services enregistrés
tctl get tunnels                          # Tunnels actifs

# Diagnostic de performance
tctl top                                  # Métriques en temps réel
curl -s https://teleport.example.com/readyz  # Health check
curl -s https://teleport.example.com/metrics # Métriques Prometheus

Un problème courant est l'échec de connexion d'un agent au cluster avec l'erreur « certificate signed by unknown authority ». Cela se produit lorsque l'agent n'a pas confiance dans le certificat TLS du Proxy Service (pour les certificats auto-signés) ou lorsque la CA Teleport a été renouvelée sans que l'agent ne mette à jour sa copie locale. La solution consiste à vérifier que le certificat du Proxy Service est valide et reconnu par le système d'exploitation de l'agent (ajout de la CA dans /etc/ssl/certs/ si nécessaire), ou à réenregistrer l'agent auprès du cluster avec un nouveau token. Un autre problème fréquent est le ralentissement des sessions SSH lorsque l'enregistrement amélioré (eBPF) est activé sur un noyau Linux trop ancien ou sans les capabilities requises. La vérification de la version du noyau (4.18+ requis pour eBPF) et des capabilities du conteneur (CAP_SYS_ADMIN pour eBPF) résout généralement ce problème.

Sécurisation de la CA Teleport

La sécurité de l'autorité de certification (CA) interne de Teleport est critique car la compromission de la clé privée de la CA permettrait à un attaquant d'émettre des certificats valides pour n'importe quel utilisateur ou nœud, contournant l'ensemble du système d'authentification. Plusieurs mesures protègent la CA de Teleport. Le stockage de la clé privée de la CA est réalisé dans le backend de données du Auth Service (etcd, DynamoDB, PostgreSQL), qui doit être chiffré au repos. Pour les environnements à haute sécurité, Teleport Enterprise supporte le stockage des clés de CA dans un HSM (Hardware Security Module) — AWS CloudHSM, GCP Cloud HSM, ou tout HSM compatible PKCS#11 — garantissant que la clé privée ne quitte jamais le module matériel sécurisé. La rotation de la CA doit être planifiée et exécutée régulièrement (annuellement pour les déploiements standard, semestriellement pour les environnements à haute sécurité) selon la procédure tctl auth rotate qui assure une transition en douceur sans interruption de service. L'accès au Auth Service doit être strictement limité : seuls les administrateurs de sécurité doivent pouvoir exécuter les commandes tctl qui interagissent avec la CA, et ces actions doivent être auditées et révisées. L'approche de sécurité de la CA Teleport complète les stratégies de protection des infrastructures Active Directory en fournissant un mécanisme d'authentification centralisé et auditable.

Sécurité de la CA Teleport — checklist :

Chiffrer le backend de stockage au repos (encryption at rest pour etcd, DynamoDB, PostgreSQL)
Utiliser un HSM pour le stockage des clés de CA en environnement hautement sensible
Planifier et exécuter la rotation de la CA annuellement
Restreindre l'accès tctl aux seuls administrateurs de sécurité via un rôle dédié
Auditer toutes les opérations sur la CA (export, rotation, émission de certificats administratifs)
Sauvegarder les clés de CA de manière sécurisée (stockage chiffré, accès restreint, test de restauration)
Surveiller les émissions de certificats anormales (volume inhabituel, durées de vie longues, rôles privilégiés)

Teleport Connect : le client desktop

Teleport Connect est l'application desktop de Teleport disponible pour macOS, Windows et Linux, qui offre une interface graphique pour la gestion des connexions SSH, Kubernetes, bases de données et applications web. Contrairement à l'interface en ligne de commande tsh qui s'adresse aux utilisateurs techniques, Teleport Connect rend l'accès aux ressources sécurisées accessible à un public plus large, incluant les équipes support, les analystes de données et les managers techniques qui n'ont pas nécessairement l'habitude des outils CLI. L'application affiche la liste des ressources accessibles (filtrées par les rôles RBAC de l'utilisateur), permet de lancer des sessions SSH dans un terminal intégré, de se connecter aux bases de données via un proxy local compatible avec les outils GUI, et d'accéder aux applications web internes via le navigateur par défaut.

L'authentification dans Teleport Connect s'effectue via le navigateur système, permettant l'utilisation du SSO existant (Okta, Azure AD, Google Workspace) et la vérification MFA (WebAuthn, clés matérielles). Une fois authentifié, l'utilisateur dispose d'une vue unifiée de toutes les ressources auxquelles il a accès, avec la possibilité de filtrer par type (serveur, cluster K8s, base de données, application), par label (environnement, équipe, région) et par terme de recherche. L'interface propose également un historique des connexions récentes pour un accès rapide aux ressources fréquemment utilisées. Teleport Connect stocke les certificats éphémères localement et les utilise automatiquement pour les connexions, offrant une expérience fluide sans réauthentification pendant la durée de vie du certificat. Pour les organisations qui déploient Teleport et souhaitent maximiser l'adoption par les utilisateurs non techniques, Teleport Connect constitue un complément indispensable à la CLI tsh.

Networking avancé : tunnels inversés et peering

L'architecture de tunnels inversés de Teleport est un élément distinctif qui le différencie des solutions d'accès basées sur des agents avec exposition de ports. Dans un déploiement Teleport, les agents (nœuds SSH, agents K8s, agents DB) n'ouvrent aucun port entrant. Au lieu de cela, chaque agent établit une connexion WebSocket persistante vers le Proxy Service (port 3024 ou port multiplexé 443). Cette connexion, une fois établie, sert de canal bidirectionnel : le Proxy Service peut envoyer des demandes de connexion à l'agent via ce tunnel inversé, et l'agent peut transmettre le trafic des sessions via le même canal. Ce modèle est fondamentalement plus sécurisé que l'exposition directe d'un port SSH (22) ou d'un port de base de données (5432, 3306) car la surface d'attaque sur les machines protégées est réduite à zéro port entrant.

Le mécanisme de tunnel inversé gère automatiquement la reconnexion en cas de perte de connectivité réseau. Si la connexion WebSocket est interrompue (redémarrage du Proxy Service, problème réseau transitoire, basculement de load balancer), l'agent rétablit automatiquement le tunnel avec un backoff exponentiel et un jitter aléatoire pour éviter les « thundering herd » lors d'une reconnexion massive d'agents après une panne du Proxy Service. La santé du tunnel est maintenue par des keepalive bidirectionnels qui détectent les connexions mortes et déclenchent une reconnexion rapide. Pour les environnements avec des pare-feu de niveau applicatif (proxy HTTP), les tunnels peuvent être configurés pour utiliser le transport HTTP CONNECT, garantissant la traversée de la quasi-totalité des configurations réseau d'entreprise.

Le peering de clusters via les Trusted Clusters étend le modèle de tunnel inversé à l'échelle inter-clusters. Lorsqu'un cluster secondaire est lié à un cluster principal via une relation de confiance, le cluster secondaire établit un tunnel inversé vers le Proxy Service du cluster principal. Les utilisateurs authentifiés sur le cluster principal peuvent ensuite accéder aux ressources du cluster secondaire via ce tunnel, sans nécessiter d'authentification supplémentaire. Le RBAC est appliqué à la frontière entre les clusters, permettant de limiter précisément quels rôles du cluster principal ont accès à quelles ressources du cluster secondaire. Cette architecture est particulièrement adaptée aux organisations multi-filiales ou multi-régions qui souhaitent centraliser la gestion des identités tout en maintenant une isolation opérationnelle entre les entités.

Stratégies de monitoring et d'observabilité Teleport

L'observabilité d'un déploiement Teleport repose sur trois piliers : les métriques de performance exposées au format Prometheus, les événements d'audit structurés et les traces de session enregistrées. La corrélation de ces trois sources de données fournit une vue complète de l'état du système, des modèles d'utilisation et des événements de sécurité.

# Alertes Prometheus recommandées pour Teleport
# alerts.yml

groups:
  - name: teleport-critical
    rules:
      # Auth Service inaccessible
      - alert: TeleportAuthDown
        expr: up{job="teleport-auth"} == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Auth Service inaccessible"

      # Taux élevé d'authentifications échouées
      - alert: TeleportAuthFailures
        expr: rate(teleport_auth_login_failure_total[5m]) > 10
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Pic d'authentifications échouées — possible brute force"

      # Certificat CA expirant
      - alert: TeleportCAExpiring
        expr: teleport_ca_expiry_seconds < 2592000  # 30 jours
        labels:
          severity: warning
        annotations:
          summary: "CA Teleport expire dans moins de 30 jours"

      # Sessions actives élevées
      - alert: TeleportHighSessions
        expr: teleport_active_sessions > 500
        for: 10m
        labels:
          severity: info
        annotations:
          summary: "Nombre élevé de sessions actives"

      # Tunnels inversés déconnectés
      - alert: TeleportTunnelsDown
        expr: teleport_reverse_tunnels_connected < teleport_reverse_tunnels_expected * 0.9
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Plus de 10% des tunnels inversés sont déconnectés"

L'export des événements d'audit vers un SIEM externe est recommandé pour les déploiements de production. Teleport supporte l'export vers Elasticsearch, Datadog, Splunk et tout système compatible avec Fluentd ou les webhooks HTTP. L'intégration SIEM permet de corréler les événements d'accès Teleport avec d'autres sources de données de sécurité (logs de pare-feu, événements EDR, alertes IDS) pour une détection de menaces multicouche. Les cas d'usage typiques incluent la détection d'accès anormaux (connexion depuis une géolocalisation inhabituelle, accès en dehors des heures de travail), l'identification de mouvements latéraux (session SSH vers un serveur suivi d'un accès base de données non habituel), et la génération automatique de rapports de conformité (liste des accès aux données sensibles sur une période donnée). La mise en place de ces intégrations de monitoring est une pratique complémentaire aux stratégies de surveillance du darkweb pour une couverture de sécurité complète.

Cas d'usage : Teleport pour les équipes SRE et d'astreinte

L'un des cas d'usage les plus impactants de Teleport concerne les équipes SRE (Site Reliability Engineering) et les ingénieurs d'astreinte qui doivent accéder rapidement aux systèmes de production lors d'incidents. Le workflow traditionnel d'incident implique souvent une perte de temps significative : connexion au VPN, localisation du serveur concerné, authentification SSH avec la bonne clé, escalade des privilèges si nécessaire. Teleport rationalise ce workflow en offrant un accès immédiat via tsh ou Teleport Connect, une recherche de serveurs par labels (trouver rapidement tous les serveurs d'un service défaillant), une élévation de privilèges JIT via les Access Requests (approuvable en quelques secondes via Slack par le security-oncall), et un enregistrement automatique de toutes les actions effectuées pendant l'incident, fournissant un post-mortem détaillé sans effort supplémentaire.

L'intégration de Teleport avec les outils d'incident management (PagerDuty, Opsgenie, Incident.io) automatise davantage le workflow. Lorsqu'un incident est déclenché, un Access Request peut être automatiquement créé pour l'ingénieur d'astreinte avec les rôles nécessaires pour accéder aux systèmes concernés. L'approbation peut être automatique pour les incidents de haute sévérité (avec notification au management pour audit), ou nécessiter une approbation manuelle pour les incidents de sévérité moindre. Cette automatisation réduit le MTTR (Mean Time To Recovery) en éliminant les délais d'accès, tout en maintenant un audit trail complet pour l'analyse post-incident et la conformité réglementaire.

Teleport pour les bases de données cloud managées

L'accès aux bases de données cloud managées (Amazon RDS, Aurora, Google Cloud SQL, Azure Database) via Teleport présente des particularités techniques importantes. Contrairement aux bases de données auto-hébergées où l'agent Teleport s'installe sur la même machine que la base de données, les services cloud managés ne permettent pas l'installation d'agents sur les instances de base de données. Teleport résout ce problème en déployant un Database agent sur une machine dédiée (instance EC2, pod Kubernetes) qui a accès réseau à la base de données cloud et établit un tunnel inverse vers le Proxy Service. L'agent se connecte à la base de données en utilisant les mécanismes d'authentification natifs du fournisseur cloud : IAM Authentication pour AWS RDS, Cloud SQL IAM pour GCP, et Azure AD Authentication pour Azure Database.

# Configuration de l'agent pour Amazon RDS avec IAM Auth
db_service:
  enabled: true
  databases:
    - name: "production-rds"
      protocol: "postgres"
      uri: "prod-db.cluster-xxxx.eu-west-1.rds.amazonaws.com:5432"
      aws:
        region: "eu-west-1"
        account_id: "123456789012"
      labels:
        env: "production"
        engine: "aurora-postgresql"
        cloud: "aws"
      tls:
        mode: verify-full

    - name: "analytics-redshift"
      protocol: "postgres"
      uri: "analytics.xxxx.eu-west-1.redshift.amazonaws.com:5439"
      aws:
        region: "eu-west-1"
        redshift:
          cluster_id: "analytics-cluster"
      labels:
        env: "production"
        engine: "redshift"

# Pour Google Cloud SQL
    - name: "gcp-postgres"
      protocol: "postgres"
      uri: "project-id:europe-west1:instance-name"
      gcp:
        project_id: "my-project"
        instance_id: "my-instance"
      labels:
        env: "production"
        cloud: "gcp"

L'avantage principal de cette configuration est que les credentials de base de données (mots de passe, tokens IAM) ne sont jamais exposés aux utilisateurs finaux. Le Database agent gère l'authentification auprès de la base de données cloud de manière transparente, et l'utilisateur se connecte uniquement via son certificat Teleport. Les requêtes SQL sont auditées et enregistrées, fournissant un historique complet des accès aux données pour les exigences de conformité. Pour les bases de données contenant des données sensibles (données personnelles, données financières), cette traçabilité est un avantage majeur par rapport à la distribution directe de mots de passe de base de données, qui ne fournit aucune visibilité sur les requêtes exécutées.

Gestion des incidents avec Teleport

Teleport s'intègre dans le processus de gestion des incidents de sécurité à plusieurs niveaux. Lors de la détection d'un incident, les fonctionnalités de lock permettent de verrouiller instantanément un utilisateur compromis, un nœud compromis ou un rôle entier, empêchant tout accès pendant l'investigation. L'audit log fournit une timeline précise des actions effectuées avant et pendant l'incident, incluant les sessions SSH (rejouables), les requêtes SQL (enregistrées), et les commandes Kubernetes (auditées). Pour les incidents nécessitant un accès d'urgence à des systèmes normalement restreints, les Access Requests fournissent un mécanisme d'escalade contrôlé et audité, évitant le recours à des « break glass » accounts non traçables.

# Réponse à incident — verrouillage d'urgence

# Verrouiller un utilisateur compromis
tctl lock --user=compromised-user --message="Compte compromis — Investigation INC-2026-0429" --ttl=72h

# Verrouiller un nœud compromis
tctl lock --node=prod-web-03 --message="Malware détecté — Isolation" --ttl=0  # Verrouillage permanent

# Verrouiller un rôle entier (prévention de mouvement latéral)
tctl lock --role=prod-admin --message="Escalade de privilèges suspecte" --ttl=24h

# Vérifier les locks actifs
tctl get locks

# Investigation — analyse des sessions
tctl get events --from=2026-04-28T00:00:00Z --to=2026-04-29T23:59:59Z --user=compromised-user

# Rejeu de sessions SSH pour analyse forensique
tsh play session-id-suspicious

# Déverrouillage après investigation
tctl rm lock/lock-uuid

La capacité de rejeu des sessions SSH est particulièrement précieuse pour l'investigation forensique. Un analyste de sécurité peut rejouer exactement ce que l'utilisateur compromis a vu et tapé dans son terminal, identifiant les commandes malveillantes, les fichiers accédés et les connexions réseau établies. Cette capacité est bien supérieure à l'analyse de logs textuels car elle fournit un contexte complet (incluant les sorties des commandes, les messages d'erreur et le timing des actions). Combinée avec l'enhanced session recording (eBPF) qui capture les appels système au niveau du noyau, cette fonctionnalité offre une visibilité forensique comparable à celle des solutions EDR pour les sessions d'accès infrastructure, complétant efficacement les stratégies de détection des attaques supply chain au niveau de l'infrastructure.

Personnalisation de l'interface web Teleport

L'interface web de Teleport peut être personnalisée pour s'adapter à l'identité visuelle de l'organisation et améliorer l'expérience utilisateur. Les options de personnalisation incluent le logo de l'entreprise sur la page de connexion, un message d'accueil personnalisé (MOTD — Message of the Day), des liens personnalisés dans la barre de navigation, et des instructions spécifiques à l'organisation pour l'installation du client et la configuration initiale. La personnalisation s'effectue via la configuration du cluster ou via les paramètres du Proxy Service.

# Personnalisation de l'interface web
# cluster-config.yaml
kind: cluster_auth_preference
version: v2
metadata:
  name: cluster-auth-preference
spec:
  message_of_the_day: |
    Bienvenue sur le portail d'accès sécurisé de Acme Corp.
    Toutes les sessions sont enregistrées et soumises à audit.
    En cas de problème, contactez security@acme.com
  logo: "/web/static/custom/logo.png"
  require_session_mfa: 2
  webauthn:
    rp_id: "teleport.acme.com"

Pour les grandes organisations, l'interface web devient le point d'entrée principal pour les utilisateurs non techniques. La personnalisation du portail avec des instructions claires, des liens vers la documentation interne et un message de bienvenue conforme à la politique de sécurité contribue à l'adoption de Teleport et au respect des bonnes pratiques d'accès. La possibilité d'afficher un avertissement légal (« Toutes les sessions sont enregistrées ») sur la page de connexion est également un prérequis dans de nombreux contextes réglementaires et juridiques.

Intégration Teleport avec les services AWS et GCP

Teleport offre des intégrations natives profondes avec les principaux fournisseurs cloud, allant au-delà du simple déploiement d'agents pour exploiter les mécanismes d'authentification natifs de chaque plateforme. Sur AWS, Teleport peut utiliser les IAM Roles pour authentifier les agents (join method IAM), les IAM Database Authentication pour accéder aux bases RDS/Aurora sans mot de passe statique, les STS Assume Role pour accéder aux consoles AWS avec des credentials temporaires, et le SSM Session Manager comme alternative de connectivité pour les instances sans agent. Sur GCP, l'intégration inclut les Service Accounts pour l'authentification des agents, le Cloud SQL IAM pour l'accès aux bases de données, et le GKE RBAC pour l'accès Kubernetes.

# Configuration de la join method IAM pour AWS
# Les instances EC2 s'enregistrent automatiquement sans pre-shared token
kind: token
version: v2
metadata:
  name: aws-iam-token
spec:
  roles: [Node, Kube, Db, App]
  join_method: iam
  allow:
    - aws_account: "123456789012"
      aws_arn: "arn:aws:sts::123456789012:assumed-role/TeleportNodeRole/*"

# Configuration de l'agent sur une instance EC2
# L'instance doit avoir un IAM Role avec la politique appropriée
ssh_service:
  enabled: true
auth_service:
  enabled: false
proxy_service:
  enabled: false
teleport:
  join_params:
    token_name: aws-iam-token
    method: iam
  auth_servers:
    - teleport.example.com:443

# Accès à la console AWS via Teleport
# L'utilisateur peut ouvrir une console AWS avec des credentials temporaires
# sans avoir besoin d'un compte IAM personnel ou de clés d'accès statiques
tsh app login aws-console
# Ouvre le navigateur avec une session AWS console temporaire

L'intégration IAM est particulièrement puissante car elle élimine la nécessité de distribuer des tokens ou des secrets d'authentification aux agents Teleport. Les instances EC2 s'enregistrent auprès du cluster Teleport en présentant leur identité IAM, que le Auth Service vérifie en appelant l'API AWS STS. Cette approche est analogue à l'utilisation de Workload Identity dans GCP ou de Managed Identities dans Azure, appliquée au contexte de l'accès infrastructure. La join method IAM est le mécanisme recommandé pour les déploiements AWS à grande échelle car il simplifie considérablement le provisionnement des agents et élimine le risque de fuite de tokens d'enregistrement.

Pour les organisations multi-cloud, Teleport unifie l'accès à travers AWS, GCP et Azure dans une seule interface. Un ingénieur peut accéder à un serveur EC2, puis à un cluster GKE, puis à une base de données Azure PostgreSQL, le tout via la même session tsh authentifiée une seule fois via SSO. Cette unification élimine le besoin de gérer des outils d'accès séparés pour chaque fournisseur cloud (AWS SSM, GCP IAP, Azure Bastion) et fournit un audit trail unifié couvrant l'ensemble de l'infrastructure multi-cloud. Cette capacité est un différenciateur significatif de Teleport par rapport aux solutions d'accès spécifiques à un fournisseur cloud et constitue une brique essentielle pour les organisations adoptant une stratégie multi-cloud avec des exigences de gouvernance centralisée.

Évolutions récentes et feuille de route de Teleport

Teleport est un projet en développement très actif avec des releases majeures trimestrielles et des releases mineures bimensuelles. Les évolutions récentes incluent l'amélioration continue du support Windows Desktop avec un rendu RDP natif dans le navigateur et la prise en charge de la redirection de périphériques USB, l'extension du Device Trust pour vérifier l'état de conformité des postes de travail avant d'autoriser l'accès (statut du disque chiffré, version de l'OS, présence d'un agent EDR), le support de nouveaux types de bases de données (DynamoDB, Snowflake, Cassandra, Elasticsearch), et l'amélioration des performances de l'enregistrement de sessions avec la compression des enregistrements et l'upload asynchrone vers S3.

La feuille de route publique de Teleport indique plusieurs développements majeurs à venir. L'accès réseau (network access) étendra Teleport au-delà de l'accès applicatif pour couvrir l'accès réseau de couche 3/4, permettant de remplacer les VPN traditionnels pour certains cas d'usage. L'auto-discovery amélioré détectera automatiquement les nouvelles ressources dans les comptes cloud et les enregistrera dans Teleport sans intervention manuelle. Le Policy Engine permettra de définir des politiques d'accès plus expressives, combinant les attributs de l'utilisateur (rôle, équipe, localisation), de la ressource (labels, type, environnement) et du contexte (heure, risque calculé, état de l'incident) pour des décisions d'accès dynamiques. Ces évolutions positionnent Teleport comme une plateforme d'accès infrastructure de plus en plus complète, capable de répondre aux besoins des organisations les plus exigeantes en matière de sécurité et de conformité.

Pour les organisations qui évaluent Teleport, la version Community Edition offre un point d'entrée accessible pour tester les fonctionnalités de base (SSH, Kubernetes, bases de données, applications web) dans un environnement de laboratoire. La migration vers Enterprise ou Cloud peut être réalisée ultérieurement pour les fonctionnalités avancées (SSO OIDC/SAML complet, Device Trust, HSM, support commercial). L'investissement dans Teleport se justifie dès que l'organisation gère plus de 20 serveurs et 10 utilisateurs nécessitant un accès SSH, ou dès que les exigences de conformité imposent un audit trail complet des accès aux données sensibles. Pour les organisations qui débutent leur transformation Zero Trust, Teleport constitue une brique fondamentale qui complète les solutions de gestion des identités (IdP), de protection des endpoints (EDR) et de monitoring de la sécurité (SIEM) dans une architecture de sécurité moderne et intégrée.

Partager cet article

Twitter LinkedIn

Télécharger cet article en PDF

Format A4 optimisé pour l'impression et la lecture hors ligne

Télécharger le PDF

À propos de l'auteur

Ayi NEDJIMI

Auditeur Senior Cybersécurité & Consultant IA

Expert Judiciaire — Cour d'Appel de Paris
Habilitation Confidentiel Défense

ayi@ayinedjimi-consultants.fr

25+

ans d'expérience

700+

articles publiés

100+

missions réalisées

Ayi NEDJIMI est un vétéran de la cybersécurité avec plus de 25 ans d'expérience sur des missions critiques. Ancien développeur Microsoft à Redmond sur le module GINA (Windows NT4) et co-auteur de la version française du guide de sécurité Windows NT4 pour la NSA.

À la tête d'Ayi NEDJIMI Consultants, il réalise des audits Lead Auditor ISO 42001 et ISO 27001, des pentests d'infrastructures critiques, du forensics et des missions de conformité NIS2 / AI Act.

Conférencier international (Europe & US), il a formé plus de 10 000 professionnels.

Domaines d'expertise

ISO 42001 Lead Auditor ISO 27001 · NIS2 Pentest & Forensics IA / LLM / RAG Cloud & Active Directory

Voir le profil complet Demander un devis

Ressources & Outils de l'auteur

GitHub

Code & projets open source

Hugging Face

Modèles IA & datasets

CertifExpress

Préparez vos certifications IT

WindowsBooster

Optimisation Windows 11

Testez vos connaissances

Mini-quiz de certification lié à cet article — propulsé par CertifExpress

Commentaires

Aucun commentaire pour le moment. Soyez le premier à commenter !

Laisser un commentaire

Teleport : Accès Zero Trust SSH, Kubernetes et Bases de Données