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.
