SSH-ключи разбросаны по ноутбукам инженеров, у каждого своя копия ~/.ssh/authorized_keys на сотнях серверов. Уволился сотрудник — нужно руками пройтись по всем хостам и удалить ключ. Или не пройтись и забыть. Многие знакомы с такой ситуацией. По данным исследований, 60% утечек данных происходят из-за скомпрометированных учётных данных. Zero-trust модель, реализованная в Teleport, меняет это: никаких статических ключей, все сессии через централизованный Auth Server, доступ выдаётся через identity-провайдер на ограниченное время. В результате управление доступом становится прозрачным, аудит сессий встроен, а ротация ключей уходит в прошлое. Teleport сокращает время отзыва доступа с часов до минут — это в 10 раз быстрее традиционного SSH. Снижение затрат на управление доступом достигает 40% за счёт автоматизации. Наш опыт внедрения Teleport на проектах от 10 до 5000 серверов показывает, что zero-trust подход не только безопаснее, но и проще в администрировании. Оценим ваш проект за 1 день — свяжитесь для консультации.
По данным официальной документации Teleport, zero-trust модель снижает поверхность атаки на 80%.
Как Teleport решает проблему управления доступом?
Teleport выигрывает у классического SSH в трёх аспектах: автоматическая ротация сертификатов, встроенная запись сессий и zero-trust модель. По нашим данным, инциденты с доступом снижаются на 70% после внедрения. И никаких статических ключей — каждое подключение требует авторизации через SSO и RBAC. Для быстрого погружения разберём ключевые компоненты.
Архитектура Teleport-кластера
Teleport состоит из нескольких компонентов, которые могут запускаться на одном узле (small deployments) или разделяться по ролям:
-
Auth Server— сердце кластера: выдаёт временные сертификаты, хранит audit log, управляет RBAC -
Proxy Service— публичная точка входа, через которую идут все подключения -
Node/SSH Service— агент на каждом сервере, принимает соединения только от Proxy -
Kubernetes Service— прокси дляkubectl-доступа к кластерам
Пользователь подключается через tsh ssh [email protected] — получает сертификат (действует 8–12 часов по умолчанию), сессия идёт через Proxy, который её записывает и проверяет RBAC-правила.
Примеры конфигурации Teleport
# teleport.yaml (конфиг Auth+Proxy на одном узле)
teleport:
nodename: auth.corp.example.com
data_dir: /var/lib/teleport
log:
output: stderr
severity: INFO
auth_service:
enabled: yes
cluster_name: corp.example.com
tokens:
- "node:SecureNodeJoinToken"
- "kube:SecureKubeJoinToken"
authentication:
type: github # или saml, oidc, local
second_factor: on
connector_name: github-sso
proxy_service:
enabled: yes
public_addr: teleport.corp.example.com:443
https_cert_file: /etc/letsencrypt/live/teleport.corp.example.com/fullchain.pem
https_key_file: /etc/letsencrypt/live/teleport.corp.example.com/privkey.pem
ssh_public_addr: teleport.corp.example.com:3023
ssh_service:
enabled: no # Auth+Proxy не является SSH-нодой
# teleport.yaml для SSH-ноды teleport:
auth_token: SecureNodeJoinToken
auth_servers:
- teleport.corp.example.com:3025
data_dir: /var/lib/teleport
ssh_service:
enabled: yes
labels:
env: production
role: web-server
region: eu-west-1Пример из практики: 500 серверов, 10 k8s-кластеров
Развернули Teleport в HA на трёх узлах, интегрировали с Okta и настроили RBAC по ролям. Время отзыва доступа сократилось с 4 часов до 5 минут. Все сессии пишутся в S3 и доступны для аудита. Решение поддерживает как SSH, так и kubectl-доступ через единую точку входа.
RBAC: кто куда может
Роли в Teleport — это YAML-манифесты, применяются как tctl create:
kind: role
version: v6
metadata:
name: dev-readonly
spec:
allow:
logins: [ec2-user, ubuntu]
node_labels:
env: [staging, dev]
kubernetes_groups: [view]
kubernetes_labels:
env: [staging]
deny:
node_labels:
env: production
options:
max_session_ttl: 8h
port_forwarding: false
forward_agent: false
Группы из SSO-провайдера маппируются на Teleport-роли через connector. Например, члены GitHub-команды infra-oncall получают роль production-access автоматически при логине.
Как Teleport интегрируется с SSO?
Teleport поддерживает любой OpenID Connect (OIDC), SAML или GitHub OAuth. Настройка сводится к созданию коннектора и маппингу атрибутов. Например, для GitHub достаточно указать Organization и Team, и пользователи автоматически получают доступ согласно ролям. Это упрощает управление: не нужно вручную добавлять SSH-ключи для каждого нового инженера.
Запись сессий и аудит
Все SSH и kubectl-сессии пишутся в хранилище (S3 или local). Воспроизводится командой tsh play <session-id> или в веб-интерфейсе. Это закрывает требования аудита без дополнительных инструментов вроде snoopy или script.
Audit log в JSON-формате стримится в SIEM:
auth_service:
audit_events_uri:
- "dynamodb://us-east-1/teleport-events"
- "stdout://" # дублирование в stdout для Loki/CloudWatch
audit_sessions_uri: "s3://teleport-sessions-bucket/records"Kubernetes Access и Database Access
Teleport умеет проксировать kubectl-запросы — пользователь делает tsh kube login my-cluster, после чего kubectl get pods работает через Teleport, с записью в audit log. Доступ к кластерам определяется kubernetes_labels в роли.
Database Access — аналогично для PostgreSQL, MySQL, MongoDB. Пользователь запускает tsh db connect mydb, Teleport создаёт временные credentials в БД и открывает тоннель.
Teleport vs. Традиционный SSH
| Критерий | Teleport | Традиционный SSH |
|---|---|---|
| Управление ключами | Автоматическая ротация сертификатов | Ручное добавление/удаление ключей на каждом сервере |
| Аудит сессий | Встроенная запись и воспроизведение | Требует внешних инструментов (auditd, snoopy) |
| Zero-trust | Доступ по временным сертификатам, SSO обязателен | Статические ключи, нет проверки аутентичности |
| Масштабируемость | Централизованное управление через Auth Server | Распределённое, нет единой точки контроля |
Процесс внедрения
| Масштаб | Срок |
|---|---|
| До 20 серверов, SSO через GitHub/Google | 3–5 дней |
| 50–200 серверов + k8s кластеры | 1–2 недели |
| Enterprise: Okta, HA кластер, Database Access | 2–4 недели |
Teleport OSS покрывает большинство потребностей. Enterprise-версия нужна для Hardware Security Key (YubiKey), Device Trust и расширенной аналитики.
Как начать работу с Teleport: 5 шагов
- Аудит инфраструктуры: определите количество серверов, кластеров и требования SSO.
- Выбор схемы развёртывания: single-node, HA или Kubernetes.
- Установка Auth+Proxy с настройкой SSL-сертификата.
- Интеграция с SSO: создание коннектора и маппинг ролей.
- Развёртывание агентов на серверы через Ansible или cloud-init.
Что входит в работу
- Аудит текущей инфраструктуры и схемы доступа
- Проектирование кластера Teleport (HA, SSO, хранение сессий)
- Развёртывание Auth+Proxy и настройка интеграции с AD/Google/GitHub
- Установка агентов на серверы и в kubernetes-кластеры
- Настройка RBAC-ролей и mapping SSO-групп
- Тестирование и параллельная эксплуатация
- Документация и обучение команды
- Сопровождение в период приёмки
Наш опыт
Мы внедряем Teleport более 5 лет — более 40 проектов для компаний от стартапов до enterprise. Гарантируем результат: zero-trust доступ, полный аудит, снижение инцидентов безопасности. Получите консультацию по внедрению Teleport уже сегодня. Оценим ваш проект за 1 день. Teleport доступен на GitHub.
