Teleport для Kubernetes: безопасный доступ к кластеру — разбор

Добро пожаловать в Teleport для Kubernetes В следующих шести видеороликах мы пройдем путь от нуля до полностью рабочей конфигурации — доступ на основе идентификаторов, управление на основе ролей, повышение привилегий в режиме реального времени и полное ведение аудита. Все, что вам нужно для правильной защиты доступа к Kubernetes. Проблема Если вы работали с Kubernetes, вы знакомы с файлами kubeconfig. Стандартный способ аутентификации в любом кластере Kubernetes — вы получаете файл, помещаете его в `~/.kube/config` и все готово. Но заглядывали ли вы когда-нибудь внутрь файла kubeconfig? Как правило, ваш файл kubeconfig содержит долгосрочный секрет. Эти сертификаты действуют месяцами или годами, и их невозможно отозвать, если вы не обновите весь центр сертификации вашего кластера. Тема всегда общая — `kubernetes-admin` — потому что в Kubernetes нет реального понятия пользователей. Это создает пробелы в аудите: когда у всех одинаковая идентификация, трудно определить, кто что сделал. А в нашей среде ИИ ваши агенты ИИ потенциально имеют доступ ко всем вашим кластерам с теми же правами доступа, что и вы. Решение: Teleport Teleport — это платформа доступа к инфраструктуре, которая располагается перед вашими кластерами Kubernetes, SSH-серверами, базами данных и веб-приложениями. Она предоставляет единый унифицированный уровень аутентификации и авторизации с полными возможностями аудита. Вместо выдачи долгосрочных учетных данных Teleport выступает в качестве вашего центра сертификации. Когда вы проходите аутентификацию через корпоративную систему единого входа (SSO) — Okta, Google Workspace или GitHub — Teleport выдает вам краткосрочный сертификат x509, содержащий вашу реальную идентификацию, роли и время истечения срока действия. По умолчанию сертификаты действительны около 12 часов. Как работает Teleport В основе Teleport лежат три основных сервиса: 1. *Сервис аутентификации* — «мозг» Teleport. 1. Он управляет центром сертификации, хранит состояние кластера, пользователей, роли, коннекторы и записывает данные в журнал аудита. 2. *Служба прокси* — ваш публичный шлюз. Она обрабатывает обнаружение протокола и маршрутизацию — один и тот же порт может обслуживать веб-интерфейс, SSH-соединения, запросы к API Kubernetes и подключения к базе данных в мультиплексном режиме. 3. *Служба Kubernetes* — агент, который соединяет Teleport с API-сервером вашего кластера Kubernetes. Он поддерживает обратный туннель к прокси, а это значит, что ваш API-сервер никогда не должен быть доступен из интернета. Что нас ждет В этом курсе мы рассмотрим развертывание Teleport с помощью Helm, настройку единого входа GitHub, создание детальной системы RBAC с многоуровневой защитой, реализацию запросов доступа «точно в срок», а также изучение аудита и записи сессий. Каждое видео включает в себя исполняемые демонстрационные скрипты, которые вы можете запустить на своей машине.