Строим свой PAM на основе Teleport
На связи команда Безопасности Wildberries — сегодня расскажем, как построить PAM на основе Teleport. Эту статью по мотивам нашего доклада на PHDays для вас подготовили руководитель департамента информационной безопасности и противодействия мошенничеству Wildberries Антон Жаболенко и руководитель направления безопасности инфраструктуры Павел Пархомец. В материале рассмотрим критерии идеального PAM, опыт его внедрения в Wildberries, разные подходы и наши результаты.
Прежде, чем начинать, нужно определиться с тем, что такое РАМ. Аббревиатура PAM в информационной безопасности имеет две легитимные расшифровки. Одна из них — это Pluggable Authentication Modules, то есть модули аутентификацию Linux. В контексте этого материала, PAM — это Privileged Access Management система. Например, она обеспечивает доступ к виртуальным машинам, серверам, кластерам Kubernetes и так далее.
Есть довольно-таки большое количество проприетарных PAM-решений. Вы можете сказать: «Возьмите уже и купите — хватит нам про всё это рассказывать!»
Но на самом деле не все так просто. Дело в том, что большинство PAM-решений, которые есть на рынке, заточены под классическую Windows-инфраструктуру. Как следствие, у них совсем другая идеология, другие подходы, и они не учитывают некоторые возможности Linux, которые можно было бы использовать для того, чтобы обеспечить хорошую защиту. Это не значит, что данные PAM-решения плохие, просто они не совсем подходят для Linux.
Критерии
Критериев к РАМ-системам довольно много, но их можно объединить в следующие:
безопасность и удобство аутентификации;
персонифицированность доступов;
гибкость управления доступами;
безопасность системы и её компонентов;
надёжность;
функциональность;
универсальность;
простота внедрения и поддержки.
Они высокоуровневые и выливаются в конкретные технические требования, но в этой статье мы их подробно рассматривать не будем. Весь список критериев можно посмотреть по ссылке.
Выделив основные технические требования, применяемые к различным РАМ-решениям и к различным подходам на основе open source, можно очень быстро прийти к пониманию того, что решения, которое удовлетворяло бы все критерии, просто не существует.
Что в таком случае взять за основу PAM для Linux-инфраструктуры?
Есть два основных подхода:
Самостоятельно написать решение, которое удовлетворяло бы всем критериям полностью.
Взять существующее open source решение, которое удовлетворяет уже части критериев, и доработать его.
Второй путь позволяет запустить итоговое решение сильно быстрее и далее итеративно его развивать. За основу можно взять такое решение, как Телепорт — это open source решение, которое разрабатывается компанией Gravitational. Телепорт поставляется в двух видах: open source решение, которое выложено на гитхабе, и enterprise-версия с расширенным функционалом и закрытым исходным кодом, которую можно купить.
В нашем примере за основу была взята именно open source версия Телепорт. «Почему?» —спросите вы. Всё потому, что он из коробки соответствует целому ряду важных критериев:
Предположим, что вы администратор, который любит технику Apple. Каким образом будет выглядеть взаимодействие с инфраструктурой через Teleport? Например, администратор, который использует MacBook, решил посетить некий сервер test-machine. Администратора зовут p.parkhomets, а сервер находится за Телепортом.
Ему выводится некоторое предупреждение о том, что будет использоваться платформенный аутентификатор (Platform authenticator в терминологии FIDO2 — да, Телепорт позволяет использовать FIDO2!), и далее система предлагает проследовать инструкциям:
После этого администратор видит сообщение от операционной системы, которая предлагает пройти аутентификацию с помощью Touch ID. Администратор прикладывает палец, проходит аутентификацию по биометрии и далее попадает на сервер, где получает сообщение о том, что подключение осуществлено с помощью Телепорт.
По тому, как выглядит заход на конечный сервер, уже можно сделать базовые выводы о том, что такое Телепорт и как он работает. Выводов несколько:
Вместо классической утилиты ssh, к которой привыкло большинство Linux администраторов, придётся использовать некоторую утилиту tsh — это реализация протокола ssh от компании Gravitional, которая поставляется вместе с Телепортом и реализует помимо самого протокола ssh довольно большое количество дополнительных фич. При этом для администраторов она может быть непривычной.
Администратор аутентифицировался на конечном сервере с помощью биометрии, в данном случае с помощью Touch ID.
Телепорт записывает все сессии.
Телепорт позволяет управлять привилегиями пользователей на конечных машинах.
Как устроен Телепорт?
У Телепорта относительно простая архитектура — она модульная, и в неё заложена идея кластеризации. То есть все компоненты можно разнести по разным контейнерам, раскидать по разным сервера, и масштабировать это всё по ресурсам под вашу нагрузку. Данный подход позволяет избежать такой проблемы, как единая точка компрометации.
Основные компоненты Телепорта:
Proxy — входная точка в ваш кластер. Пользователь взаимодействует с вашими ресурсами через прокси. Также прокси решает ряд других важных задач, например, мультиплексирование портов, поддержка реверс туннелей, расшифровка трафика при определённых конфигурациях и так далее.
Auth — сервис, который отвечает за проверку учётных данных пользователей, а также за выписывание сертификатов и их проверку.
Teleport Node — компонент, позволяющий получить доступ к конечному ресурсу, например, к веб-приложению, базе данных, серверу или кластеру Kubernetes.
etcd — хранит информацию обо всём кластере, включая ключи certificate authority (CA).
Пользователь взаимодействует со всеми конечными ресурсами через прокси, предварительно пройдя аутентификацию и получив сертификат. На процессе аутентификации следует остановиться более подробно.
Аутентификация в Телепорт
Но прежде чем говорить про то, как устроена аутентификация в Teleport, поговорим немного про аутентификацию по сертификатам в классическом OpenSSH (да-да, именно по сертификатам, а не ключам!).
OpenSSH Certificate Authentication
Это функциональность классического ssh-демона, который позволяет ему аутентифицировать пользователей по сертификатам. Ниже приведена выдержка про опцию TrustedUserCAKeys [источник].
TrustedUserCAKeys
Specifies a file containing public keys of certificate authorities that are trusted to sign user certificates for authentication, or none to not use one. Keys are listed one per line; empty lines and comments starting with »#» are allowed.
If a certificate is presented for authentication and has its signing CA key listed in this file, then it may be used for authentication for any user listed in the certificate’s principals list. Note that certificates that lack a list of principals will not be permitted for authentication using TrustedUserCAKeys. For more details on certificates, see the CERTIFICATES section in ssh-keygen (1).
Это опция классического sshd, которому можно «скормить» путь до сертификата CA, и ssh-демон будет проверять сертификаты, когда к нему подключаются пользователи.
Как это можно применить на практике? Давайте рассмотрим следующую схему [источник]:
Здесь объяснено, как, используя SSH CA, можно построить аутентификацию в распределённой Linux-инфраструктуре на основе сертификатов. Данная схема работает следующим образом. У нас есть HashiCorp Vault, в который зашивается ssh certificate authority, то есть приватный ключик сертификата для certificate authority. Далее:
Обратим внимание на цифру 1: у нас есть администратор, который хочет посещать ресурсы внутри нашей инфраструктуры. Он генерирует некоторую криптографическую пару ключей, генерирует на их основе сертификат.
Цифра 2: аутентификация в HashiCorp Vault с помощью какого-то из стандартных методов аутентификации. После того, как пользователь аутентифицируется в HashiCorp Vault, он передаёт туда свой запрос на сертификат, и этот запрос подписывается certificate authority, который зашит в HashiCorp Vault.
После этого — цифра 4 — администратор получает свой подписанный сертификат обратно, и далее он может с этим сертификатом ходить по инфраструктуре. При этом ssh-демон на конечных серверах настроен в режиме ssh certificate authentication, и будет проверять подпись certificate authority на сертификате, который предоставляет непосредственно администратор.
Если опустить детали, то процесс выглядит примерно так, как описано выше. Но зачем нужны сертификаты, когда есть обычная и всем привычная ключевая пара? Всё очень просто. Сертификаты, в отличие от обычной ключевой пары, предоставляют некоторые дополнительные фичи, например, можно ограничить их срок жизни. То есть вы можете с помощью certificate authority выписать сертификат, который истечёт, например, через 24 часа. Такое может быть полезно, когда вы хотите предоставить доступ к вашему проду какому-то разработчику, когда всё упало, но при этом на постоянной основе разработчиков туда пускать не хотите. Также в сертификат можно заложить другую дополнительную информацию, которую тоже можно использовать, когда вы принимаете решение о том, пускать пользователя на конечный сервер или нет.
Схема, описанная выше, очень понятная и прозрачная, на основе очень похожей схемы и работает Телепорт. Он выступает в роли certificate authority вместо HashiCorp Vault, и пользователям, которые перед ним аутентифицируются, выписывает кратковременные ssh-сертификаты, с которыми уже потом можно ходить по инфраструктуре. Кроме того, Телепорт может работать в OpenSSH в совместимом режиме. А вместо Teleport Agent можно использовать OpenSSH в режиме certificate authentication.
Как можно аутентифицироваться?
Мы с вами разобрались в том, как с точки зрения архитектуры устроена сама аутентификация. Теперь давайте посмотрим чуть подробнее на то, какие опции с точки зрения аутентификации предоставляет Телепорт.
Во-первых, давайте ответим на вопрос: «Как можно аутентифицироваться в Телепорте и через что?»
Как можно аутентифицироваться:
Через что можно аутентифицироваться:
Да, Телепорт позволяет ходить на сервера через браузер. В Linux инфраструктуре это может быть немного странно, но реальность такова.
Ещё один вопрос, на который стоит ответить — с помощью каких стандартов Телепорт позволяет аутентифицироваться. Тут три варианта:
Третий пункт — FIDO2-аутентификация — нам наиболее интересен:
Аутентификация с использованием SSO при tsh
Рассмотрим схему аутентификации в Телепорте с использованием SSO при утилите tsh:
Это самый сложный флоу аутентификации — он нигде не описан в документации. Есть некоторый клиент, который использует утилиту tsh, — например, некоторый администратор. Также есть его браузер, есть непосредственно сам Телепорт и некоторый SSO-провайдер, например, Keycloak, который подключён к Телепорту по протоколу Open ID Connect.
Разберём, как устроен процесс аутентификации в этом случае:
Предположим, что администратор, про которого мы уже говорили (p.parkhomets), вбивает команду для того, чтобы зайти на конечный сервер. В этот момент утилита tsh на своей стороне генерирует несколько значений: публичный ключ, секретный ключ и некоторое значение secret.
После этого терминал открывает браузер. Да, для того чтобы аутентифицироваться с помощью SSO на конечном сервере придётся открывать браузер. На вход передаётся два параметра — это public key и secret, то есть публичный ключ и секрет. Браузер внутри себя делает переход на Телепорт прокси — один из компонентов Телепорта, про который уже было написано выше.
Телепорт, получив public key и secret, сохраняет данные у себя в базе.
Далее происходит стандартный флоу аутентификации с помощью SSO. Телепорт делает редирект на SSO провайдера, например, на какой-нибудь Keycloak. SSO провайдер аутентифицирует клиента.
Телепорт получает информацию о том, что такая учетная запись действительно есть, далее генерирует сертификат для клиента и подписывает его с помощью своего приватного ключа точно так же, как это делал HashiCorp Vault в примере выше. На самом деле, в Auth Телепорта хранится приватный ключ, с помощью которого подписывается кратковременный сертификат.
Телепорт подписывает его, шифрует на переменной secret, которая изначально была сгенерирована клиентом, и отправляет обратно в браузер клиента, откуда она уже выпадает в утилиту tsh.
Итого, у клиента есть кратковременный сертификат, с помощью которого можно уже сходить на конечный сервер. То есть получается, что приватный ключ вообще не покидает клиента.
Аутентификация через браузер
Основные отличия:
пара ключей генерируется на сервере Teleport и хранятся в базе, на пользователя выписывается только bearer-токен.
Teleport Proxy осуществляет имперсонификацию пользователя при взаимодействии с ресурсами.
Приватный ключ клиента хранится на стороне Телепорта. Честно говоря, схема аутентификации через браузер не очень нужна и при этом ещё расширяет поверхность атаки на систему, потому что добавляет флоу, когда пользователь может прийти в Телепорт прокси со статическим токеном, а Телепорт прокси будет представляться этим пользователем в инфраструктуре. К сожалению, Телепорт эту фичу отключить не позволяет.
Подведём итог
Мы рассказали про то, как устроена аутентификация с помощью SSO. Без SSO она происходит практически так же, только непосредственно на сервере Телепорта без редиректов и браузера. Собственно говоря, у аутентификации с помощью Телепорта и SSO есть один основной плюс — пользователю не нужно нигде дополнительно регистрироваться, если у вас уже есть SSO-провайдер, который содержит информацию о ваших сотрудниках. Зато у такого подхода есть огромное количество минусов. Если кратко: стабильность и безопасность SSO влияет на стабильность и безопасность PAM. Компрометация SSO-провайдера мгновенно приведёт к компрометации всей инфраструктуры, потому что злоумышленник, который скомпрометировал SSO-провайдера, сможет выписывать сертификаты. Также есть ряд технических проблем и проблемы эстетические. Так, аутентификация с помощью утилиты tsh требует открытия браузера, что далеко не всех порадует.
Подробнее о минусах
Управление доступами с помощью Teleport
В инфраструктуре можно управлять пользователями в двух местах:
PAM
Конечные хосты
Сосредоточимся на первом пункте. Для начала надо ввести такие понятия как «метка» и «роль».
Метка — это некое свойство, которое вы даете всем своим ресурсам. По факту это просто обычная строка в формате ключ-значение, которая хранится в конфигурационном файле.
Роль нужна для того, чтобы ответить на один вопрос:, а может ли пользователь, который владеет этой ролью, получить доступ к ресурсу, у которого выставляются определённые метки (ABC). Получается, что роль предоставляет доступ к тому ресурсу, с которым у неё совпадают метки. По умолчанию вообще нет никакой регламентации того, как вам называть свои роли, как называть свои метки, какие значения прописывать и так далее. Всё потому, что при большом количестве пользователей у вас в любом случае будет большое количество ролей, и если вы не начнете с самого начала вводить какие-то жесткие правила, регламентировать название ролей, вводить жесткие метки, впоследствии вам будет очень плохо.
К каким выводам мы пришли в Wildberries:
приняли строгий набор меток;
приняли конвенцию названия ролей;
сделали стандартные роли;
сделали процессы создания ролей, согласования доступа;
сделали интеграции
с системами виртуализации, контейнеризации и наливки серверов,
с кадровыми сервисами и мессенджером.
Как выглядят наши метки
Роль и её название должны соответствовать правилам:
роль даёт доступ только к одному типу ресурса;
роль даёт доступ только к одному окружению;
роль даёт доступ или по меткам (к набору ресурсов) или по имени ресурса (к одному ресурсу);
по названию роли всегда должно быть понятно, к чему она даёт доступ;
название роли всегда должно иметь вид <тут большая регулярка, я её показывать не буду>.
В Wildberries мы пришли к следующим двум форматам:
Первый формат определяет роли, которые выдают доступы к ресурсам по меткам. Второй формат — роль, которая выдает доступ только к одному ресурсу.
Resource_type — это тип ресурса, к которому мы даем доступ.
Env — окружение.
Team — команда, которая отвечает за поддержку администрирования данного ресурса.
Project, product — необязательные метки.
Namespace — метка специфична только для СУБД и кубов. В кубах это куда вы даёте доступ, а в СУБД — название базы.
Access_type — тип доступа который вы хотите выдать.
Name — имя ресурса, которому вы даете доступ.
Конечные роли выглядят так:
Кроме того, в Wildberries мы ввели стандартные роли: это оказался очень простой, но достаточно эффективный механизм. Они выдаются всем пользователям по умолчанию и позволяют реализовать дополнительную логику, в том числе по управлению пользователями.
Стандартные роли:
выдаются автоматически при регистрации,
предоставляют доступы по умолчанию,
позволяют реализовывать дополнительную логику.
Выдача по умолчанию объясняется тем, что пользователей создают не через стандартную админку, а через кастомную, и получается, что при создании любого пользователя им сразу выдаются роли.
Наши входные данные:
несколько Proxmox,
система наливки bare-metal,
приватное облако,
большое количество кластеров Kubernetes.
Что было сделано?
Автоматическое подключение всех VM в Proxmox к PAM.
Автоматическое подключение Baremetal к PAM.
Автоматическое подключение всех VM в WB Cloud к PAM.
Автоматическое прорастание доступа тому, кто заказал ресурс.
Автоматическая нарезка ролей для создаваемых неймспейсов Kubernetes.
На виртуальную машину по умолчанию сразу ставятся метки, они подключаются к телепорту. Как это выглядит:
Что делает Teleprox:
создает VM в Proxmox;
пишет информацию о хосте в Netbox;
указывает владельца хоста.
Teleprox — это наша разработка. По факту, это обыкновенная HTML-форма, которая решает несколько важных задач. Во-первых, Teleprox сразу требует от пользователя выставления обязательных меток — то есть надо обязательно указать, кто владелец, какой базовый образ вы будете использовать и так далее. Следующее — Teleprox сам довозит эти метки в netbox и затем создаёт виртуалку в проксах. Таким образом, вам надо прийти в Телепрокс, заказать себе машину, указать владельца и всё — больше вам ничего не нужно делать для того, чтобы у вас автоматически появились доступы на новые создаваемые виртуалки.
Затем мы промасштабировали этот процесс на Baremetal:
Последним нашим шагом по интеграции была интеграция с приватным облаком. Для приватного облака мы собрали отдельный базовый образ и написали модуль cloud init — это демон, который стартует при запуске виртуальной машины.
Процесс наливки и подключения виртуальных машин в облаке отличается не только по наливке, но и по подключению. Любые создаваемые машины в облаке подключаются к Control Plane по реверс туннелю — это значит, что машина при старте создаёт реверс туннель, а пользователь заходит на эту машину по уже установленному туннелю. Вдобавок, namespace создаются пачками каждый день, а пользователям остаётся только заказать себе эту роль.
Встраиваем Телепорт в архитектуру ИБ
Как может быть устроена архитектура VPN + Телепорт.
Доступы из VPN:
внутренние балансировщики,
PAM (Teleport),
Персональные ACL (если нужен доступ до специфичных протоколов).
Предположим, что у нас есть обычный пользователь, который хочет подключиться к внутренним админкам и веб-ресурсам. Что можем для этого сделать? Собрать все эти ресурсы, поместить их за пачку приватных балансеров и выдать с VPN доступ только к этим балансерам — никуда больше. Таким образом, большинство сотрудников, которым не нужны привилегированные доступы, попадают только до веб-ресурсов, которые находятся за этими балансерами. В свою очередь на веб-ресурсах обязательно должна быть дополнительная аутентификация.
В случае с админами, открываем доступ от VPN до Teleport Proxy только по одному порту 443, потому что Телепорт прокси предоставляет такую замечательную фичу как мультиплексирование портов. Это добавляет дополнительный слой защиты. Если есть злоумышленник, который хочет попасть в привилегированную инфраструктуру, например, на сервера, то ему всегда нужно преодолеть несколько слоёв защиты: аутентификацию на уровне VPN сервера и на уровне Телепорта.
Модель угроз и подходы к харденингу
Теперь давайте поговорим про то, как Телепорт нужно защищать, если вы всё-таки решили использовать его в качестве ядра PAM.
Оттолкнёмся от моделей злоумышленников. Есть две верхнеуровневые модели, актуальные для PAM. Первая — внешний злоумышленник, и его можно отрезать, убрав Телепорт за VPN. А вот подвидов внутренних злоумышленников может быть несколько:
с доступом к сети без учётной записи в Телепорте
с доступом к сети и учётной записью в Телепорте
с доступом к управляющим интерфейсам серверов
с физическим доступом к стойкам.
Как обезопасить сам Телепорт? Для того, чтобы ответить на этот вопрос более подробно, стоит вспомнить архитектуру телепорта и понять, что у этого вопроса есть три ключевые составляющие:
защита Control Plane;
защита конечных хостов (Teleport Node);
мониторинг подозрительной аутентификации и прочих действий.
Харденинг Control Plane
etcd. Телепорт в качестве базы данных использует распределённую базу etcd. И не просто использует, а хранит там приватный ключ для certificate authority. Что это значит? Компрометация etcd мгновенно приведет к компрометации всей вашей инфраструктуры. Поэтому etcd нужно корректно защищать. Это отдельная большая тема, выходящая за рамки данной статьи, тут лишь обозначим её важность.
Защита KVM. Если вы качественно и хорошо захарденели etcd, но при этом у вас в инфраструктуре к серверам, на которых развернут Телепорт, можно получить доступ через управляющие интерфейсы самих серверов, понятное дело, что злоумышленник сможет также получить доступ к сертификату и приватному ключу, и всё будет скомпрометировано. И очень часто находится какой-нибудь сервер, на котором пароль — это adminadmin или 123… Поэтому важно помнить о безопасности доступов через IPMI/KVM.
Сетевая изоляция. Управляющие компоненты Телепорта тоже нужно аккуратно изолировать — либо на уровне локального фаервола, либо какого-то другого — чтобы они не были доступны там, где не надо.
Шифрование дисков. etcd хранит свои файлы в файловой системе сервера, на котором она задеплоена. При этом важно понимать, что в рамках жизненного цикла вашей инфраструктуры и вашего Телепорт-кластера сервера периодически будут выходить из строя. Периодически будут выходить из строя и диски, при этом сотрудники могут их забывать корректно уничтожать. Поэтому, если вы не реализуете корректное шифрование на серверах, на которых задеплоен Телепорт, существует вероятность того, что когда-нибудь диск выйдет из строя и его просто выкинут, не уничтожив. Ваш приватный ключик для CA может так утечь.
Вынести на bare-metal. По-хорошему, этот пункт должен быть первым. Телепорт можно задеплоить в кубере, на виртуалках, а можно на bare-metal. Мы рекомендуем именно последнее. Если вы его деплоите, например, в кубере или на какой-то системе виртуализации, Control Plane этой системы виртуализации или кубера расширяет возможности для атаки. Так как Телепорт — это супер критичная штука с точки зрения управления доступами, этого стоит избежать.
Контроль доступа на хосты Control Plane. При этом, если вы всё обезопасили, зашифровали, но у вас на хостах Control Plane проходной двор и доступ есть у всех, то ничего хорошего из этого не выйдет. Имеет смысл пускать туда только выделенных администраторов, причем желательно только по ssh-ключам, которые хранятся на аппаратных токенах.
Харденинг хоста. Хосты, на которых всё это задеплоено, нужно захарденить с помощью стандарта безопасного конфигурирования, который вы считаете применимым к вашей инфраструктуре.
Мониторинг ИБ. Безопасники очень любит ставить в инфраструктуру какие-нибудь хосты мониторинга, которые могут выполнять произвольный код на конечных серверах, потому что так удобнее расследовать инциденты. Но важно понимать, что если вы поставите такой агент мониторинга, то он тоже может стать одним из векторов, через который приватные ключи будут скомпрометированы. При этом хосты Телепорта, действительно, важно мониторить и следить за подозрительными событиями на них.
Харденинг хостов
Вторая часть того, что нужно захарденить — это конечные хосты, то есть непосредственно те сервера, на которых ставится Teleport Node. И тут есть интересный момент — Teleport Node не поддерживает механизм tcpwrap (он используется для ограничения доступа к Linux-демонам по сети). То есть вы для Teleport Node не можете написать конфиг hosts.allow, который разрешит доступ к Teleport Node только из вашей локальной сети. Из-за этого приходится всячески ухищряться и блокировать доступ к Teleport Node на бордерах либо на фаерволе (локальном или внутреннем).
Ну и важно не забыть про то, что при конфигурировании Teleport Node есть такая вещь как ListenAddress — то есть тот интерфейс, на котором слушает ваш Teleport Node. И это должен быть локальный интерфейс, чтобы ваши Teleport Node не торчали в интернет.
Последнее, о чём хочется сказать, — это харденинг OpenSSH. Вы в целом можете спросить, откуда здесь Open SSH, если мы ставим Телепорт. Однако использовать OpenSSH, например, в качестве Break Glass механизма. В таком случае нужно корректно его защитить и написать конфиг и для hosts.allow, и для самого SSH, чтобы ниоткуда кроме специальных, например, Break Glass Node доступа оттуда не было.
Подведём итоги
Пожалуй, сам Телепорт даже с учётом всех плюсов — это не РАМ нашей мечты. Телепорт — это лишь фреймворк, на базе которого можно построить нормальный РАМ.
Мы многое сделали с Телепортом, чтобы он начал отвечать нашим требованиями к PAM: заинтегрировали с различными сервисами, наливаторами, написали собственную админку, сделали кастомный PAM-модуль, который управляет привилегиями, и так далее.
У читателя может возникнуть вопрос, какие есть пределы масштабируемости? В нашей инсталляции Телепорта на момент написания статьи больше 30 тысяч хостов. И на 30 тысячах хостов в рамках одного отказоустойчивого кластера Телепорта (хотя телепорт с агентской схемой сложно назвать отказоустойчивым решением), задеплоенного в разные ЦОДы, полёт нормальный. Есть некоторые проблемы, но глобально всё работает достойно.
Напоследок покажем результаты того, каким из предложенных выше критериев удовлетворяет получившийся у нас PAM на Teleport.
Также важно отметить, что у Телепорта есть ряд проблем, про которые мы рассказывали в другом нашем докладе на Saint HighLoad++.
