Привет Habr!
В первой статье блога я хочу рассказать о нашей платформе для разработчиков - Tuna. Как мы начали делать свой сервис реверс-прокси туннелей а-ля ngrok, затем добавили менеджер паролей и теперь не можем остановиться .
❯ Туннели
Собственно как и у всех аналогов у нас есть HTTP (реверс-прокси) и TCP туннели. А ещё есть SSHd и Trigger туннели. В настоящий момент у нас есть 2 региона где размещаются туннельные ноды:
RU - Москва
NL - Амстердам
Наличие туннельной ноды в России делает работу более комфортной ввиду отсутствия большой задержки. Также в ближайшее время мы планируем расширять точки присутствия на восток, вероятнее всего появятся ноды на Урале, Сибири и Дальнем востоке.
Я не буду здесь рассказывать про все функции или пересказывать документацию, но остановлюсь на основном и приведу популярные примеры использования.
HTTP туннели
Обратные-прокси туннели, чаще всего их используют для превью разработки web-сайтов и telegram webapp, тестирования платежей, тестирования телеграм ботов, peer-to-peer передачи больших файлов и прочее.
Открываем доступ к локальному сайту на 127.0.0.1:3000:
# на случайном поддомене
tuna http 3000
# на статичном поддомене
tuna http 3000 -s habr
# на собственном домене
tuna http 3000 -d demo.habr.teamФайловый сервер, если надо передать большой файл, например дамп базы данных:
# сервим текущий каталог закрыв авторизацией
tuna http --basic-auth='user:pass' -f .
# сервим SPA приложение
tuna http -F ./distЕщё есть флаги для включения CORS, генерация QR кода с ссылкой в консоль, что-бы проще было тестировать мобилку, инспектор запросов, управление заголовками, авторизация, WebDAV сервер и прочие ништяки.
Также возможно подключить свой домен. После настройки DNS, проверки и выпуска Let's Encrypt сертификата - можно использовать, а в тарифе для команд есть поддержка и доменных зон (wildcard), где и TLS сертификат свой можно загрузить, вдруг у вас интеграция с кем-то кто доверяет только сертификатам от Минцифры.
TCP туннели
Если же вам надо открыть доступ к какому то не HTTP приложению, например база данных, сервер очередей, minecraft, RTSP поток от IP камеры, RDP в общем что угодно, что работает по TCP - то нужны TCP туннели.
По умолчанию порт выделяется динамически но можно зарезервировать статичный порт, задать ему алиас и тогда вы всегда будете знать куда подключаться.
# динамический порт к локальному postgres
tuna tcp 5432
# статический порт к IP камере в локальной сети
tuna tcp --port=rtsp 192.168.0.55:554SSHd туннели
Нет, это не SSH туннели про которые написано много всего.
Tuna содержит встроенный SSH-сервер, это позволяет создать туннель и предоставить удаленный доступ по SSH без необходимости запускать SSH сервер и какой-либо конфигурации со стороны пользователя. Помимо функционала обычного SSH-сервера, tuna позволяет записывать сессии пользователей и просматривать их.
Возвращаясь к преимуществам, хочу отметить, что такой фичи нет в ngrok или аналогах, ну или пока нет 😜.
Когда это полезно? Например для помощи с настройкой окружения новому коллеге с macOS или Linux. Оказание технической поддержки или аудит на удалённых серверах заказчиков. Доступ к серверам или IoT устройствам в серой сети. Ещё как пример можно запустить в контейнере в Kubernetes и отлаживать работу приложения, при этом не нужно будет предоставлять доступ, настраивать роли и пользователя, генерировать kubeconfig и учить человека делать kubectl port-forward.
Но давайте разберём подробнее какой нибудь живой пример. Вот вы купили некое серверное ПО, запустили его на сервере, но работает как-то плохо, вы пишите в поддержку, вам говорят - предоставьте SSH доступ. А ваш сервер в серой сети, надо настроить проброс портов на роутере, создать пользователя, добавить в sudo в общем куча дел, по меркам некоторых Enterprise-ов задача на неделю. Но вместо этого вы заходите на сервер и лёгким нажатием на Enter запускаете SSHd туннель:
tuna ssh
В этот момент создаётся TCP туннель и запускается встроенный SSH-сервер, а в логе вы увидите короткую инструкцию по подключению. Передаёте поддержке реквизиты и ждёте когда они подключатся и решат вашу проблему. Но помимо решения проблемы ещё вы хотите знать, а что они там делали? Какие команды вводили? Вдруг проблема повторится и проще будет решить её самостоятельно. На этот случай tuna пишет лог ssh сессии и вы можете всё посмотреть.
# смотрим список всех записанных ssh сессий и находим нужную
tuna ssh-session list
# смотрим лог нужной ssh сессии
tuna ssh-session watch 2swT2BHUrpnqx4Qchh2yW8eF7cx
Поддержка авторизации по ключам также есть, для этого нужно загрузить публичный ключ в личный кабинет и разрешить подключение с его помощью в настройках.
Trigger туннели
Триггеры - команды, выполняемые по определенному событию, сейчас поддерживается HTTP запрос (Webhook) и Письмо (SMTP). Тоже уникальный функционал, полезен для IoT и автоматизаций.
Например у вас на даче есть шлагбаум который вы хотите открывать по получении письма.
# запускаем trigger smtp туннель на статичном порту
tuna trigger smtp -p ipcam /tmp/trigger.sh
# имитируем камеру
curl -s \
--url "smtp://ru.tuna.am:19840" \
--mail-from "tuna@example.com" \
--mail-rcpt "tuna@example.com" \
--upload-file /tmp/upload-file-must-be.txtПримерно тоже самое можно настроить и для HTTP Webhook.
Думаю тут можно закончить обзор базовых функций Туннелей, мы обязательно разберём разные интересные случаи их применения для ускорения и упрощения работы в отдельных статьях и заметках. Но перейдём дальше.
В какой то момент делая туннели мы поняли, что не хотим делать просто какой то аналог. Так как мы сами разработчики и наши пользователи разработчики мы лучше всего знаем что бывает неудобно в работе какие есть проблемы и какого сервиса не хватает. Туннели - это прекрасно, с ними проще что-то тестировать, а для демонстрации продакту нового цвета кнопок не надо деплоить всё на тестинг и ждать когда пройдут все тесты в CI. Вы действительно можете ускориться и сохранить часы ожидания пайплайнов.
Но помимо скорости, при работе в команде, есть и другие проблемы. Например мне часто пишут коллеги в личку и просят поменять какие то токены или сказать пароль от личного кабинета какого-нибудь сервиса. И все мы прекрасно отправляем друг другу пароли в чатиках. Да есть компании у которых есть корпоративный 1Password или что-то ещё. Но чаще всего ничего нет, а хранить инфраструктурные пароли, ssh ключи, пароли от сервисов, API интеграций, сертификаты где-то надо, но что важнее надо как то безопасно этим делиться с коллегами.
Тут мы плавно переходим к второму но не последнему нашему продукту.
❯ Менеджер паролей
Создан для безопасного хранения и удобного обмена паролей и других видов секретов для разработчиков, администраторов их команд и не только. Мы не храним пароли в открытом виде, согласно модели нулевого знания, только пользователь обладает ключами, которые могут расшифровать данные.
Наша цель (хм звучить амбициозно, но пусть..) - это повысить культуру хранения секретов среди наших пользователей и обезопасить клиентов от утечек, и несанкционированного доступа к их инфраструктуре. Поэтому Менеджер паролей является базовой и бесплатной функцией для всех.
Подробнее об устройстве менеджера паролей мы напишем отдельную статью, чуть подробнее уже есть у нас в документации.
Два продукта кажется маловато, чтобы называть себя платформой, не так ли?
❯Бастион
Этот функционал ещё тестируется, но уже скоро станет доступен в тарифе для Команд.
Если вы слышали про Teleport или Hashicorp boundary, то да, это примерно оно. Доступ к инфраструктуре с архитектурой нулевого доверия (zero trust architecture).
По сути это продолжение нашей мысли о безопасности в команде, только уже на уровне доступа к инфраструктуре. Приведу пример - большинство проектов можно с лёгкостью запустить локально, и тогда нам помогают Туннели, но бывает, что проект включает так много компонентов, что локальная разработка невозможна. Тогда вам приходится организовывать доступ к инфраструктуре для разработчиков, тестировщиков, аналитиков и т.д. Это может быть ssh доступ на сервер, доступ к базе данных, redis, kafka, да что угодно. Какая же тут возникает проблема? А проблема в том, что используя штатные инструменты предоставления доступа вы на 99% теряете контроль, добавив SSH-ключ пользователя на все серверы вы уже не узнаете каким ещё пользователям он разложил свой ключ, когда и зачем он подключается, что делает. Вы начинаете ему просто доверять, а проверять не можете. Именно эту проблему мы и хотим решить с помощью tuna-bastion.
На текущем этапе мы реализовали только SSH доступ с но функционал доступа к базам данных, Kubernetes и прочим прочим приложениям тоже есть в планах.
Как это работает, коротко
Tuna API имеет CA для серверов и для пользователей.
В панели управления вы добавляете сервер и получаете команду что-то вроде такой:
tuna-bastion --enroll-key ff57be51-e4fc-427f-96cb-86e2846dc806Запускаете эту команду на целевом сервере, tuna-bastion начинает работать как SSH-сервер, а подключиться смогут только пользователи команды, которым вы разрешили и только к тому логину, что вы разрешили, а когда вы передумаете, подключаться станет нельзя.
Пользователь когда хочет подключиться запускает у себя локально команду для авторизации в API и подписания своего сертификата User CA, а также получает Host CA. Выше есть Упрощённая схема работы давайте я расскажу подробнее что там происходит.
Пользователь запускает команду tuna bastion login и получает ссылку по которой ему нужно перейти и подтвердить, что он - это он. Параллельно клиент генерирует локально Ключ и Сертификат. Сертификат передаётся на подпись, ключ никуда не передаётся это гарантия что доступ будет только у этого пользователя (Zero trust), а не унас или ещё кого-то Даже если произойдёт утечка нашей базы данных, к вашим серверам никто доступ получить не сможет, так мы ничего не храним.
Если пользователь проходит авторизацию в my.tuna.am и подтверждает сгенерированную ссылку, то Tuna API подписывает Сертификат и возвращает его. В этом сертификате описано, что пользователю можно согласно описанию ролей доступа. Все файлы складываются локально на файловую систему. Уже с подписанными сертификатом пользователь может получить список серверов.
Получив список серверов пользователь может подключаться tuna bastion ssh ubuntu@server-1 , примерно тут происходит преобразование и генерируется команда для подключения стандартным ssh-клиентом:
ssh -i ~/.tuna/bastion/keys/id_rsa -o CertificateFile=~/.tuna/bastion/keys/ubuntu-cert.pub -o UserKnownHostsFile=~/.tuna/bastion/keys/known_hosts -p 993 ubuntu@192.168.1.11Сервер сверяет сертификат клиента, проверяет что он действующий, проверяет доступы и если всё в порядке, то...
Клиент получает доступ к оболочке.
В чём тут преимущество пред штатным SSH?
Вам не надо добавлять ssh-ключи пользователей в .ssh/authorized_keys
Даже если пользователь положит свой ключ в .ssh/authorized_keys, то подключиться он не сможет.
Если вы уволили сотрудника вы можете в тот же момент запретить ему доступ ко всей инфраструктуре, а не ждать когда ваш devops прокатит ansible playbook, который ещё и не исключает полностью вероятность присутствия пользователя при закладках.
Если вы хотите посмотреть кто, куда и когда подключался - это будет возможно
Банально можно запретить вообще всем подключаться в мораторий, например в новогодние праздники, чтобы исключить поломки от желания некоторых что-то поправить на проде.
Какая наша мотивация?
Если вы попытаетесь хотя бы узнать сколько стоит подобное решение у аналогов, то почти везде вы увидите кнопку Связаться с менеджером, как правило это означает Очень дорого. Как и с Менеджером паролей, наша цель - это повысить безопасность и сократить риски несанкционированного доступа к инфраструктуре наших клиентов.
Безопасность - это базовая потребность (даже по пирамиде Маслоу), и мы хотим, чтобы даже самые маленькие стартапы на 5 человек могли себе это позволить.
Тут закончу про бастион, возможно получилось несколько сумбурно, но я вернусь с более подробной статьёй, когда будет релиз.
На этом у меня всё, спасибо что дочитали до конца 🙂
Контакты
Подробнее можете посмотреть всё на сайте tuna.am, в документации и блоге надеюсь вам понравится работать с tuna.
Если возникли вопросы, можете задать их нам по почте info@tuna.am, тут в коментариях или нашем чате в telegram.
