Что такое ключ доступа​

Ключ доступа (passkey) — это пара криптографических ключей, которая приходит на смену паролю. Приватная половина никогда не покидает ваше устройство, менеджер паролей или аппаратный брелок, а на серверах Tuna оседает только публичный ключ. Красть на нашей стороне попросту нечего: сам по себе публичный ключ для входа бесполезен, в отличие от базы паролей.

И ещё одна приятная деталь: каждый ключ намертво привязан к домену tuna.am. Подсунуть его на фишинговый сайт-двойник не выйдет — браузер даже не предложит ключ на чужом адресе. Пароль так не умеет: его можно выманить поддельной страницей или подобрать по утёкшей базе.

Чем это удобнее пароля​

• Нечего запоминать и вводить. Логин — это один клик и касание пальцем, а не строчка из 16 символов со спецзнаками.
• Не выманить фишингом. Ключ срабатывает только на настоящем домене Tuna — фальшивая страница уйдёт ни с чем.
• Один шаг вместо двух. Passkey сам по себе сочетает два фактора: владение устройством плюс подтверждение личности (биометрия или PIN). Поэтому при входе по ключу Tuna не спрашивает отдельный одноразовый код — двухфакторность уже соблюдена.

Где может жить ваш ключ​

WebAuthn — это открытый стандарт (FIDO2), а не проприетарная фишка одного вендора. Поэтому Tuna дружит практически с любым современным хранилищем ключей. А их, по большому счёту, два семейства.

Синхронизируемые passkeys — ключ живёт в вашем менеджере паролей или облачной связке и сам подтягивается на все ваши устройства. Сменили телефон — ключи уже там. Сюда относятся:

• менеджеры паролей — 1Password, Bitwarden, Dashlane, NordPass, Proton Pass, а для любителей держать всё локально — KeePassXC;
• встроенные хранилища ОС — iCloud Keychain на Apple, Google Password Manager на Android и в Chrome, Windows Hello на Windows.

Аппаратные ключи (FIDO2) — отдельный физический брелок, из которого приватный ключ не извлекается в принципе. Максимальная защита для тех, кому важно, чтобы секрет не покидал железку:

• YubiKey от Yubico — де-факто отраслевой стандарт, версии под USB-A, USB-C и NFC (на скриншоте выше как раз добавлен такой — «Yubico 1»);
• Google Titan, Feitian, Nitrokey (открытая прошивка), Token2 и другие совместимые с FIDO2 ключи.

Один брелок хранит десятки, а современные модели — и сотни ключей от разных сервисов, так что заводить отдельный «на Tuna» не нужно.

Как добавить ключ​

Откройте Профиль и найдите блок «Ключи доступа (passkeys)» рядом с настройками двухфакторной аутентификации. Нажмите «Добавить ключ», а дальше всё сделает браузер: предложит сохранить passkey в менеджер, связку ключей или на аппаратный брелок и попросит подтвердить создание.

К одному аккаунту можно привязать до 10 ключей — например, по одному на рабочий ноутбук, телефон и физический YubiKey в связке. Каждый ключ виден в списке с датой добавления и временем последнего входа, его легко переименовать или удалить.

Как войти по ключу​

На странице входа под основной кнопкой появилась кнопка «Войти с ключом доступа». Нажимаете её, выбираете ключ, подтверждаете биометрией или PIN — и вы внутри. Никаких почты, пароля и кода из приложения.

А если в прошлый раз вы заходили именно так, рядом с кнопкой подсветится бейдж «Последний вход» — маленькая подсказка, чтобы не гадать, каким способом вы обычно пользуетесь.

Безопасность​

• На серверах Tuna хранится только публичный ключ — приватная часть остаётся у вас.
• Привязка к домену tuna.am защищает от фишинга.
• Каждый вход требует подтверждения пользователя — биометрии или PIN.
• Счётчик использований помогает выявить попытку клонирования ключа.

При этом никто не заставляет бросать привычное: пароль и вход через Google, Yandex или Mail.ru работают как раньше. Ключи доступа их не отменяют, а дополняют — а каким способом входить, решаете вы.

Попробуйте прямо сейчас​

Загляните в Профиль, откройте блок «Ключи доступа (passkeys)» и нажмите «Добавить ключ» — следующий вход в Tuna займёт одно касание.

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

Возникает задача: не встраивать логин в каждый сервис отдельно, а поставить перед ним слой доступа и решить, кого пускать, каким способом и к каким путям.

Способов решить эту задачу несколько, и каждый хорош для своей ситуации. Разберём от самых простых к более гибким по контролю. В конце — сравнительная таблица.

Перейти к разделу Приложения в документации

Способ 1. VPN: не выставлять сервис наружу вообще​

Классика: сервис живёт в приватной сети, доступ — только через VPN.

Когда работает. В компании уже есть поднятый и поддерживаемый VPN, все пользователи — штатные сотрудники с настроенными клиентами, и никого извне пускать не нужно.

Ограничения:

• Контроль на уровне сети, а не на уровне пользователя и пути. Настроить так, чтобы разработчики имели полный доступ, а дизайнеры — только к /dashboards, не получится.
• VPN кто-то должен поднимать и поддерживать.

Избыточен для небольших проектов. Разворачивать всё это ради одной Grafana и пяти человек — стрельба из пушки по воробьям.

Способ 2. Basic auth: логин-пароль на прокси​

Самый быстрый вариант: повесить HTTP basic auth на nginx или прямо на туннель — в Tuna это делается флагом при запуске:

tuna http 3000 --basic-auth="user:password"

Когда работает. Нужно на день-два показать демо заказчику или прикрыть тестовый стенд от случайных глаз и ботов. Одна пара логин-пароль, ноль настройки.

Ограничения.

• Не видно, кто заходил. Пароль один на всех, его пересылают в чатах — персональной привязки нет, и вы не узнаете, кто именно был внутри.
• Доступ нельзя отозвать у одного человека — только сменить пароль сразу всем.
• Нет ролей, второго фактора и журнала. Basic auth просто спрашивает пароль, но не дает разграничить права или посмотреть историю входов.

По сути это замок для честных людей: подходит для демо на пару дней, но не для постоянного доступа к админке.

Способ 3. IP-фильтры: пускать только со своих адресов​

Дать доступ списку IP или подсетей на файрволе, в nginx или на туннеле.

Когда работает. Доступ нужен из офиса со статическим адресом или с конкретных серверов (мониторинг, CI). Для машинного трафика с известных адресов — нормальное решение.

Ограничения:

• Когда люди работают из дома, с мобильного интернета и из поездок, и их адреса меняются.
• Нет персональной привязки. Фильтр отвечает на вопрос, откуда пришли, но не кто пришёл.

Способ 4. Собрать самому: nginx + oauth2-proxy​

Полноценная авторизация перед сервисом без правок его кода: реверс-прокси, перед ним oauth2-proxy, OIDC-провайдер, сертификаты.

Когда работает. У вас есть DevOps-ресурс, нестандартные требования и желание полностью контролировать каждый слой. Так работают многие инфраструктурные команды.

Ограничения:

• Выше порог входа. До запуска нужно связать прокси с провайдером, разобраться с cookie-доменами и редиректами, настроить обновление сертификатов.
• Нужна поддержка. Связку нужно обслуживать и переделывать при каждой смене требований.
• Тонкие правила собираются вручную. Чтобы открыть путь только одной группе пользователей и только с MFA, нужно использовать несколько инструментов.

Для одного-двух внутренних сервисов такие трудозатраты редко окупаются.

Способ 5. Zero Trust реверс-прокси: готовый слой авторизации​

Идея та же, что в способе 4 — проверять каждый запрос до того, как он дойдёт до приложения, — но всю инфраструктуру авторизации берёт на себя готовая платформа. Этот подход называют Zero Trust. По нему работают корпоративные продукты вроде Cloudflare Access, а в Tuna это сервис Приложения.

Как это выглядит на практике. Вы создаёте приложение в веб-интерфейсе и описываете правила доступа: какие пути кому открыты, где требовать второй фактор, кого не пускать вовсе. Проверка происходит на стороне Tuna — до вашего сервиса доходят только запросы, прошедшие все правила. В коде приложения ничего менять не нужно.

Несколько вещей, которые в самосборном варианте потребовали бы отдельных инструментов, здесь есть из коробки:

• разные способы входа под разных людей — корпоративный SSO для команды (Google, Yandex, GitHub, GitLab, VK или любой OIDC-провайдер) и одноразовый код на email для внешнего подрядчика, которому не нужно заводить аккаунт;
• правила на уровне путей — например, служебный /api/health оставить открытым для проверок, а всё остальное закрыть; правила комбинируются по email, команде, стране, IP и способу входа;
• управление доступом — режим запроса доступа с ручным одобрением (человек объясняет, зачем ему вход, а вы решаете, пускать ли), видимость активных сессий и отзыв доступа в любой момент: в разделе сессий видно, кто сейчас внутри, и любую сессию можно закрыть точечно или все разом;
• сервисные токены для CI/CD и мониторинга — машинный трафик ходит отдельно от человеческого и так же подчиняется правилам;
• журнал и сессии — в аудит-лог пишется, кто и откуда заходил, кто менял правила и выдавал доступ; видно историю входов и действий администраторов.

Если у сервиса нет публичного IP — он на ноутбуке, за NAT, в закрытом контуре — его можно опубликовать через туннель одной командой:

tuna app my-service --url=http://127.0.0.1:8080

Подробный разбор настройки — в документации, анонс с обзором возможностей — в блоге.

Ограничения:

• Это решение для веб-сервисов и HTTP API. Доступ к базе данных или SSH-доступ к серверам — отдельные задачи, для них есть TCP-туннели с IP-фильтрами и Бастион.
• Как любой SaaS, платформа — это внешняя зависимость: если политика компании требует держать контроль доступа строго внутри контура, ваш путь — способ 4.

Сравнение​

Итог: как выбрать​

Показываете демо на пару дней → хватит basic auth на туннеле.

Пускаете только серверы и офис со статическим IP → достаточно IP-фильтров.

Вся команда штатная, VPN уже работает и есть кому его обслуживать → оставайтесь на VPN.

Нужен контроль на уровне пользователей и путей, видно, кто заходил, и доступ нужно забирать точечно — но нет ресурса собирать и поддерживать связку прокси с OIDC — берите Zero Trust proxy.

А если требования запрещают выносить авторизацию из своего контура → собирайте способ 4 и закладывайте время на поддержку.

Попробуйте прямо сейчас​

Перейдите в раздел Приложения, нажмите + Добавить приложение — и закройте свой первый сервис авторизацией за пару минут.

Подробное описание всех возможностей — в документации:

• Политики доступа
• Запросы доступа
• Сервисные токены
• Сессии
• Настройки приложения

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

Пароли и секреты: две разные модели безопасности​

В Tuna есть два хранилища для чувствительных данных — Менеджер паролей и Секреты. Они намеренно построены по-разному, потому что решают разные задачи.

Менеджер паролей — модель нулевого знания (zero-knowledge). Ключи шифрования создаются на вашем устройстве и никогда не покидают клиент — браузер или приложение. Шифрование и расшифровка происходят только на вашей стороне, а на сервер уходит уже зашифрованный текст. Принцип, заложенный в основу: компрометация нашей инфраструктуры не должна приводить к компрометации ваших паролей — расшифровать их можно лишь там, где есть мастер-ключ, а он есть только у вас. Обратная сторона — данные доступны только владельцу мастер-ключа: автоматически выдать пароль скрипту или пайплайну, не раскрывая его, в такой модели невозможно.

Секреты — серверное шифрование. Здесь мастер-ключ находится на стороне платформы, и шифрование выполняет сервер. Это осознанный компромисс, и сделан он ради главного сценария секретов — автоматизации. Секрет должен сам, без участия человека, попадать в приложение при запуске, в CI/CD-пайплайн, в скрипт развёртывания. Запуск приложения с подгрузкой переменных, сервисные ключи для CI, автоматический перезапуск при изменении значения — всё это работает именно потому, что сервер способен выдать секрет по запросу авторизованного клиента, не требуя мастер-пароль каждый раз.

Платой за удобство становится доверие к инфраструктуре платформы — технически сервер может расшифровать секрет. Поэтому всё, что описано дальше, — про то, как мы это доверие оправдываем.

Модель доверия секретов​

Раз сервер умеет расшифровывать секреты, главный принцип звучит так: база данных не должна содержать ничего, чем можно расшифровать секреты. Даже если у злоумышленника окажется полный дамп таблиц, в нём не должно быть достаточно материала, чтобы получить исходные значения.

Достигается это классической схемой конвертного шифрования (envelope encryption) — двухуровневой иерархией ключей.

Конвертное шифрование: два уровня ключей​

В системе два уровня ключей:

1. Мастер-ключ платформы (KEK, Key Encryption Key). Хранится на стороне Tuna и в базу данных не попадает. Сам по себе он ничего пользовательского не шифрует — его единственная задача «оборачивать» (защищать) ключи команд.

2. Ключ команды (DEK, Data Encryption Key). Для каждой команды генерируется свой случайный ключ — криптографическим генератором случайных чисел. Именно им шифруются значения секретов этой команды.

Ключ команды не хранится в открытом виде: он зашифрован мастер-ключом и в таком «обёрнутом» виде лежит в базе. Чтобы им воспользоваться, сервер сначала разворачивает его мастер-ключом в памяти.

Получается цепочка зависимостей: значение секрета защищено ключом команды, а ключ команды защищён мастер-ключом. Разорвав любое звено, дальше пройти нельзя.

Любопытно, что менеджер паролей построен на той же идее конвертного шифрования — с двумя принципиальными отличиями: «конверт» там запечатывается асимметрично, на паре открытого и закрытого ключей, а корневой ключ остаётся на стороне клиента, а не сервера. Схема одна и та же, по-разному распределено лишь доверие: секреты настроены на автоматизацию, пароли — на нулевое знание.

Где и как хранится мастер-ключ​

Это основной для всей схемы вопрос, поэтому разберем каждое место хранения:

• Не в базе данных. Мастер-ключ принципиально отделён от данных, которые он защищает. В дампе базы его нет.
• Не в коде и не в репозитории. Он не зашит в исходники, а передаётся сервису извне — из защищённого хранилища конфигурации платформы.
• Только в памяти процесса. Сервер держит ключ в оперативной памяти на время работы и не пишет его на диск в открытом виде.
• Полноценный 256-битный ключ. Этого достаточно, чтобы перебор был вычислительно невозможен.

Главный вывод: доступ к базе данных и доступ к мастер-ключу — это два разных уровня доступа с разными правами. Компрометация одного из них не означает автоматически компрометацию второго.

Жизненный цикл секрета: запись и чтение​

Шифрование и расшифровка встроены в слой работы с данными и происходят прозрачно — приложение никогда не пишет открытое значение в базу и никогда не читает его оттуда напрямую.

При сохранении значение шифруется ключом команды ещё до записи. Для каждого значения берётся свой случайный одноразовый вектор (nonce) — поэтому даже два одинаковых секрета выглядят в базе по-разному. В хранилище попадает только зашифрованный текст.

При чтении происходит обратный процесс: сервер достаёт шифр, разворачивает ключ команды и расшифровывает данные. Открытое значение существует только в памяти процесса ровно столько, сколько нужно, чтобы отдать его авторизованному клиенту.

Мы используем режим GCM (Galois/Counter Mode) — это аутентифицированное шифрование. Помимо конфиденциальности оно гарантирует целостность: если кто-то изменит хотя бы один байт зашифрованных данных в базе, расшифровка не вернёт «мусор», а честно провалится с ошибкой проверки. Подделать или незаметно подменить значение в обход сервера не получится.

В транзите всё дополнительно защищено TLS — между вашим клиентом и API данные идут по зашифрованному каналу.

Что лежит в базе зашифровано, а что открыто​

Разбор того, какие данные и в каком виде реально хранятся в базе:

Да, метаданные — это тоже информация. Даже не видя значений, по именам переменных можно судить о том, какими сервисами и технологиями вы пользуетесь. Сами секреты при этом остаются зашифрованными. Но это снова небольшой компромисс в угоду удобству и быстроте работы.

Что будет, если утечёт база данных​

Это сценарий, ради предотвращения которого вся схема и строилась. Представим худшее: злоумышленник получил полный дамп нашей базы.

Что у него на руках:

• Зашифрованные значения секретов — шифр AES-256-GCM, статистически неотличимый от случайного шума.
• Ключ команды — но он сам зашифрован мастер-ключом.
• Метаданные — имена, типы, структура проектов.

Чего у него нет:

• Мастер-ключа. Его нет в базе — он на стороне сервера, куда дамп базы доступа не даёт.

Цепочка обрывается на первом же шаге. Чтобы расшифровать значение, нужен ключ команды. Чтобы развернуть ключ команды — нужен мастер-ключ. Мастер-ключа в дампе нет, а взломать AES-256 перебором невозможно. Значения секретов остаются защищены. Злоумышленник видит лишь каркас: имена и структуру, но не содержимое.

Границы защиты​

Никакая схема не защищает от всего, и важно понимать её рамки:

• Если утечёт И база, И мастер-ключ одновременно — защита падает. Именно поэтому они хранятся раздельно, с разными правами доступа: чтобы одна уязвимость не вскрывала сразу оба уровня.
• Метаданные видны при утечке базы — об этом сказано выше.
• Реакция на инцидент. При подозрении на компрометацию правильный шаг — ротация: смена мастер-ключа, перевыпуск сервисных ключей и обновление самих секретов в их первоисточниках. Сервисные ключи можно выпускать с ограниченным сроком жизни именно на такой случай.

Дополнительные уровни защиты​

Шифрование — это фундамент, но не единственный слой. Доступ к секретам ограничен ещё на нескольких уровнях:

• Скрытые значения (Restricted). Секрет с такой видимостью не отдаётся через API и не попадает в выгрузки — даже авторизованному пользователю показывается только факт его существования.
• Сервисные ключи с узким доступом. Для CI/CD выпускаются ключи, привязанные к конкретной конфигурации, с правами только на чтение или на чтение и запись, и с опциональным сроком действия. Утечка такого ключа не открывает доступ ко всем секретам команды.
• Ограничение по IP (Trusted IP). Доступ к конфигурации можно ограничить списком разрешённых адресов и подсетей в формате CIDR.
• Полный аудит. Все изменения внутри конфигураций журналируются — видно, кто и когда менял каждый секрет.

Что в планах​

Сейчас Tuna Секреты — это централизованное и зашифрованное хранилище. Логичный следующий шаг — сделать его источником истины, из которого секреты автоматически синхронизируются туда, где они нужны.

В планах — интеграции для односторонней синхронизации:

• HashiCorp Vault — отправка секретов в Vault, чтобы Tuna стала удобным интерфейсом управления, а приложения продолжали читать их привычным способом.
• Kubernetes Secrets — синхронизация конфигурации напрямую в секреты нужного namespace кластера.
• GitHub Actions — публикация в encrypted secrets репозитория или организации для использования в пайплайнах.
• GitLab CI/CD — синхронизация в CI/CD variables проектов и групп.

Идея в том, чтобы вы редактировали секрет в одном месте, а он автоматически и безопасно доходил до всех ваших окружений — без копирования значений между десятком панелей.

Итог​

Безопасность Tuna Секретов держится на нескольких простых и проверенных принципах:

• Две модели под две задачи — пароли шифруются на клиенте (мы их не видим), секреты — на сервере, ради автоматизации.
• AES-256-GCM — аутентифицированное шифрование значений до записи в базу.
• Конвертное шифрование — мастер-ключ защищает ключи команд, ключи команд защищают данные.
• Мастер-ключ отделён от данных — его нет ни в базе, ни в коде, и утёкший дамп БД бесполезен.
• Слои доступа сверху — видимость, сервисные ключи, ограничение по IP и аудит.

Мы не делаем вид, что защита абсолютна, и открыто показываем её границы — потому что доверие строится на прозрачности, а не на маркетинговых обещаниях.

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

Перейти к разделу Приложения в документации

Зачем это нужно?​

Представьте: у вас есть внутренний сервис — админка, staging-окружение, Grafana, внутренний API. Вы хотите дать к нему доступ только нужным людям, из нужных стран, с подтверждением через корпоративный SSO. Раньше это означало возню с nginx, oauth2-proxy, сертификатами и списками доступа.

С Приложениями Tuna проверяет каждый входящий запрос: кто пользователь, как он аутентифицировался, откуда пришёл и имеет ли право видеть запрашиваемый путь. Всё это настраивается через веб-интерфейс за пару минут.

Что можно сделать:

• закрыть любой веб-сервис авторизацией без изменений в коде;
• гранулярно разграничить доступ — например, /admin/* только для администраторов из России, а /api/health открыть без аутентификации;
• подключить корпоративный SSO (Google, Yandex, GitHub, GitLab, VK, любой OIDC-совместимый провайдер);
• требовать MFA или ручное одобрение администратора для чувствительных операций;
• опубликовать сервис без публичного IP через туннель — достаточно одной команды;
• выдать машинный доступ через сервисные токены для CI/CD, мониторинга и автоматизации.

Два режима доставки трафика​

При создании приложения вы выбираете, как Tuna будет доходить до вашего сервиса.

В режиме туннеля после создания приложения вы получаете готовую команду:

tuna app <имя> --url=http://127.0.0.1:8080

Запустите её на машине с сервисом — и приложение станет доступно через защищённый домен.

Политики доступа — сердце системы​

Каждый запрос проходит через цепочку политик. Первая политика, чей шаблон пути совпал, определяет судьбу запроса: пропустить, потребовать MFA, запросить одобрение или отказать. По умолчанию доступ запрещён.

Каждая политика — это паттерн пути (glob-шаблон вроде /admin/*) и действие:

• Разрешить — доступ при прохождении правил;
• Требовать MFA — то же плюс второй фактор (TOTP или код на email);
• Запретить — безусловная блокировка;
• Пропустить — путь без аутентификации (health check, webhook-эндпоинты).

Внутри политики настраиваются правила — кто именно получит доступ. Их можно комбинировать по режимам OR / AND / NOT и собирать из разных типов:

Например, чтобы открыть /admin/* только участникам команды и только из России, достаточно одной политики с правилами «Команда» (or) и «Страна: RU» (and).

Тестирование без риска​

Прежде чем применять конфигурацию, её можно проверить инструментом Тест политик — смоделировать запрос с любыми параметрами и увидеть, какое решение примет система. Без создания реальных сессий.

Вход через корпоративный SSO​

Способы входа комбинируются — пользователь увидит их все на странице входа:

• Email OTP — одноразовый код на email, удобно для внешних подрядчиков;
• Аккаунты tuna.am — вход через личный аккаунт;
• Провайдеры команды — внешние Identity Provider (Google, Yandex, GitHub, GitLab, VK, любой OIDC).

Ещё больше контроля​

Запросы доступа — для чувствительных ресурсов включите ручное одобрение. Пользователь объяснит причину, администратор одобрит доступ на нужный срок (от 15 минут до бессрочного).

Сервисные токены — машинная аутентификация для CI/CD, мониторинга и скриптов. Пара Client ID + Client Secret, передаётся в заголовках. Поддерживается ротация с grace-периодом — обновляйте секрет без простоя.

curl -H 'Tuna-Access-Client-Id: sat_...' \
     -H 'Tuna-Access-Client-Secret: ...' \
     https://your-app.example.com/

Сессии — пользователи видят свои активные сессии, администраторы — сессии всей команды с полной информацией (IP, страна, User-Agent, последняя активность). Любую сессию можно отозвать, а кнопка «Закрыть все сессии» завершает их разом.

Гибкие настройки прокси — заголовки запроса и ответа, переписывание путей, CORS, лимит размера тела, TLS до upstream и клиентский сертификат (mTLS).

Полный аудит​

Все действия с приложениями записываются в аудит-лог: создание и изменение приложений, входы пользователей, одобрения и отклонения запросов доступа, отзыв сессий. Каждое событие содержит детали — кто, когда, откуда и что именно произошло.

Попробуйте прямо сейчас​

Перейдите в раздел Приложения, нажмите + Добавить приложение — и закройте свой первый сервис авторизацией за пару минут.

Подробное описание всех возможностей — в документации:

• Политики доступа
• Запросы доступа
• Сервисные токены
• Сессии
• Настройки приложения

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

Проблема​

Симптомы следующие:

• бот, зарегистрированный через setWebhook, перестал получать обновления;
• запросы от api.telegram.org не доходят до туннеля в регионе RU — их не видно ни в логах клиента, ни в инспекторе;
• при этом туннель работает: запросы из браузера и от других сервисов проходят штатно.

Со стороны нашего сервиса и хостинг-провайдера в России никаких ограничений нет — туннель работает штатно, мы видим установленное соединение. Проблема где-то в магистрали между инфраструктурой Telegram и нашими RU-нодами; вероятнее всего, это ограничение со стороны РКН. Повлиять на это с нашей стороны мы не можем, но регион подключения у туннеля — это параметр клиента, и сменить его — дело пары секунд.

Решение — сменить регион туннеля​

Самый быстрый способ — поднять туннель в другом регионе, например nl (Нидерланды). Полный список доступных регионов и все способы переопределения — в документации.

Tuna Desktop​

При создании туннеля выберите регион в выпадающем списке Регион:

После сохранения туннель поднимется в выбранном регионе — webhooks от Telegram начнут приходить.

Командная строка​

Передайте регион аргументом --location (или коротким -l):

tuna http 8080 --location=nl
tuna http 8080 -l nl

Чтобы не указывать флаг каждый раз, регион можно задать по умолчанию одним из трёх способов.

Команда tuna config save-location — сохранит значение в конфигурационный файл:

tuna config save-location nl

Параметр в конфигурационном файле напрямую:

location: nl

Переменная окружения TUNA_LOCATION:

TUNA_LOCATION=nl

Что дальше​

После смены региона у туннеля изменится URL — не забудьте обновить адрес webhook'а в настройках вашего Telegram-бота (метод setWebhook с новым URL).

Если и после этого webhooks не приходят — напишите нам в Telegram-сообщество или на info@tuna.am.

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

Boards​

The headliner of the release!

Like many of our tools, Tuna Boards grew out of an internal tool. Its first versions were extremely primitive and simple, but for us that was always enough.

Here's what the project looked like historically ...

That's why we never used other alternatives like Miro and always tried to use our own internal product. If you've noticed, any diagrams and signature drawings are made exactly in this tool.

Today we're pleased to introduce Boards as part of our developer platform. Here you can sketch out an infrastructure diagram, plan new features, design new UX and UI, and also use the built-in voice chat, timer and other features.

Meets​

Video calls have long been an integral part of any online meeting; every self-respecting developer hates these damned calls, but now you can do it on our platform!

Meet Tuna Meets.

The functionality is fairly standard: there's a presenter mode, presentations, background blur and so on. The interface is fully adapted for mobile devices, so you can take calls both at your computer and on the go.

Integrations with task trackers​

After we launched Reports and Monitors, it immediately became clear that it would be convenient, for an incident in monitors or for a new report, to be able to create a task in GitLab, Jira or Yandex.Tracker with one click. So we built integrations with the main popular task trackers so you can quickly create tasks in your favorite tracker.

Filter in the request inspector​

The request inspector now has a filter bar for requests by many parameters: request type, response status, headers, IP address and much more. To start using it, update to the latest version of tuna-cli.

Improvements in SSHd tunnels​

We're not forgetting to develop tunnels either.

1. Added support for Windows 11+, the user gets a PWSH terminal.
2. Auto-detection of $HOME, $SHELL and the profile settings of the user under whom the SSHd tunnel is launched.
3. Switched to the asciinema format in ssh-sessions. So sessions now record everything, including work in text editors, launching TUI utilities, etc. Recordings can be watched in the terminal, embedded on a website with a standard player, or converted to GIF using the tuna ssh-session export command.

• Asciinema player
• GIF

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

What's changed?​

The new names better reflect the level of capabilities of each plan and the user's growth path on the platform.

Why did we rename?​

The old name Team was misleading users — many thought the plan was intended exclusively for team use. In reality there are no such restrictions, and this plan can be used solo, getting expanded limits and all the platform's features. The new name Legend removes this misunderstanding.

Switching from Pro to Legend​

Previously, to switch to the Legend plan you had to create a separate team — now this is no longer required. You can switch from Pro to Legend directly from your dashboard without any additional steps, keeping all your resources and settings.

What stays the same?​

• Subscription pricing
• Limits and features of each plan
• Additional licenses
• All active subscriptions continue to work

If you have any questions — get in touch.

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

$ tuna tcp 54321 --proxy-protocol=2
INFO[22:08:58] Welcome to Tuna
INFO[22:09:00] Forwarding tcp://ru.tuna.am:22347 -> 127.0.0.1:54321

Go to documentation

Why do you need PROXY Protocol?​

When using tunnels, your application sees connections from the tunnel server rather than from the real client. PROXY Protocol solves this problem — it passes the original client IP and port in the connection header, which allows you to:

• Keep correct connection logs with real IP addresses
• Apply access control rules at the application level
• Collect accurate analytics on user geography

New flag​

The tuna tcp command has a new --proxy-protocol flag that accepts the protocol version:

Usage examples​

Basic example​

tuna tcp 8443 --proxy-protocol=1
# or with an environment variable
TUNA_PROXY_PROTOCOL=1 tuna tcp 8443

Minecraft server​

Some game server builds, for example Velocity, support PROXY Protocol. Enable it in the game config and in the tuna client:

tuna tcp 45678 --proxy-protocol=2

Compatibility​

PROXY Protocol is widely supported by popular server software:

• Haproxy — supports both versions, detects automatically
• Nginx — supports both versions, detects automatically
• Envoy — supports both versions
• Many databases and applications via a proxy layer

Updating​

To update, follow the instructions.

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

Go to Monitors section in documentation

What are Tuna Monitors?​

Monitors let you control the operation of your cron jobs, services and infrastructure. If a problem occurs, you'll get an immediate notification through the configured communication channels — email, Telegram, Slack and others.

Monitors are:

• Tracking of periodic jobs (backup scripts, cron jobs)
• Availability checks for websites, APIs and tunnels from multiple regions
• Network infrastructure monitoring (TCP, DNS, ICMP)
• Automatic notifications on failures and recoveries
• Integration with the tuna CLI for convenient work from the terminal

Who is it for?​

1. DevOps engineers — for monitoring infrastructure and automated jobs
2. Developers — for tracking the availability of APIs and services
3. System administrators — for controlling the execution of backup scripts and cron jobs
4. Teams — for centralized monitoring of all services with shared notifications

6 monitor types​

Tuna supports 6 monitor types, divided into two categories:

User monitors​

These monitors wait for signals from your applications and scripts:

External monitors​

These monitors independently check the availability of your resources from multiple geographic regions:

HTTP and TCP monitors are integrated with Tunnels. If you have active tunnels or reserved domains/ports, when creating a monitor the resource you need will be in the menu to the right of the address.

Key features​

Cron job monitoring​

Track the execution of backup scripts, syncs and other periodic operations:

# Simple backup with monitoring
tuna monitor exec MONITOR_ID -- pg_dump -U postgres mydb > /backups/dump.sql

# In crontab
0 3 * * * tuna monitor exec MONITOR_ID -- /scripts/backup.sh

The system automatically sends start, finish or fail signals, and also captures execution logs.

Heartbeat monitoring​

For services in closed networks, IoT devices and background processes:

# Sending a heartbeat every 5 minutes
*/5 * * * * tuna monitor ping MONITOR_ID --host=my-server

Checks from multiple regions​

External monitors check the availability of your resources from different geographic locations, which makes it possible to detect routing issues or regional unavailability.

SSL/TLS and Whois monitoring​

HTTP monitors automatically check SSL certificates and track the domain expiration date so you don't miss the renewal moment.

Integration with notifications​

Monitors are integrated with the Contacts and Integrations systems. Set up notifications via Telegram, Slack, email or webhook.

CLI integration​

The tuna console client is fully integrated with monitors:

• tuna monitor ping — sending a Heartbeat signal to a monitor
• tuna monitor exec — executing a command with automatic tracking
• tuna monitor status — viewing monitor statuses

Detailed information about each monitor type, settings and usage examples is available in the documentation.

Notifications and integrations​

Notifications and integrations are also a big part of the new functionality, which is integrated not only with monitors but also with reports.

Popular communication channels are supported: Telegram, Slack, Discord, VK Teams, Google Chat and custom Webhooks. Contact groups let you flexibly manage recipients — combine email addresses and integrations into named groups, use one group for multiple monitors, and easily add or remove recipients without changing the monitors' settings themselves.

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

Go to Reports section in documentation

How does it work?​

1. Go to your dashboard and create a project in the Reports section.

2. Add this code to your website before the closing <head> tag:

   <!-- tuna. Screen and user actions recording -->
   <script>
       window.reportOptions = {
           captureKey: "YOUR_CAPTURE_KEY"
       };
   </script>
   <script src="https://reports.tuna.am/latest/index.js" async></script>
   

3. Call the script with CTRL + ALT + S or ⌘ + ⌥ + S and create a report.

What does a report look like?​

Inside the report you will find a screenshot or video and all the debugging information from the console, network operations, user actions and a snapshot of the page DOM tree.

• Info
• Inspector
• Console
• Network
• Actions
• Comments

The first tab contains general summary information about the client, device and browser.

Video overview​

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

Webhooks​

Traffic Policy​

In addition to a simple response, you can now describe complex webhook processing rules, imitating an API response for example. It's important to note that this will work even on the free plan, and you can try traffic policies for free.

Resend request to tunnel​

If you have running tunnels, you can forward the received request to them. We thought this could be convenient and useful when debugging something in the early stages.

TOTP in Password Manager​

Long-awaited TOTP (Time-based one-time) passwords have appeared. This means that if you have 1 account from a third-party service for the team, now you can safely enable 2FA.

Client distribution improvements​

Security​

We focus on security, so we recommend checking that you're using our official client builds. Now all build artifacts, archives, packages, installers, checksum files, and docker images are signed with our digital signature.

• Public GPG key for verification is distributed via the link - https://releases.tuna.am/tuna.asc
• Public Cosign key for Docker images verification - https://releases.tuna.am/tuna-cosign.asc

Distribution for ALT Linux​

Added distribution support for the Russian ALT Linux, more details in the installation instructions.

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

Overview​

Even in the early stages, we faced the use of our platform by scammers. They distribute malware, send spam, publish phishing sites, and engage in other misconduct. Therefore, we implemented quite a lot of tools for analysis and early detection of such violations. But this doesn't provide 100% protection - sometimes tunnel nodes still end up in antivirus databases, and here our task is to learn about this as quickly as possible, block the violator, and promptly contact the antivirus company to remove our domains, subdomains, and IP addresses from quarantine databases.

Fortunately, there's such a wonderful resource as VirusTotal - essentially an aggregator. In it, you can check a resource (domain, IP, file) for presence in any antivirus databases. Everything is very simple and visual, looks something like this:

VirusTotal has a public API, also a CLI utility, ready-made clients for some languages, and if you register and get an API Key, you can automate everything quite well, which will allow you to learn about presence in databases as quickly as possible. Which is what we did. But keep in mind that the free tier has some limitations on the number of requests, but for a dozen domains/IPs it will definitely be enough.

How to use?​

In the repository you'll find binary builds and docker images for deployment, as well as configuration instructions. We'll be happy to receive feedback and merge requests.

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

Go to dashboard

Overview​

A new section Webhooks has appeared in the dashboard. Here you can create links for testing, debugging, and creating mocks. This is quite convenient when you want to understand why a service's webhook documentation doesn't match reality - just specify the link and everything will become clear. You'll see all headers and request body in a convenient format. In the documentation section, you'll find more detailed information on managing webhooks and examples.

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

New flags​

The tuna tcp, tuna ssh, tuna postgres and tuna redis commands have new flags and env analogs:

--cidr-allow # Reject connections that do not match specified CIDRs
--cidr-deny # Reject connections matching specified CIDRs

TUNA_CIDR_ALLOW # Reject connections that do not match specified CIDRs
TUNA_CIDR_DENY # Reject connections matching specified CIDRs

Usage examples​

tuna tcp 3389 --cidr-allow="10.0.0.1/32"

tuna tcp 3389 --cidr-deny="10.0.0.1/32"

tuna tcp 3389 --cidr-allow="10.0.0.1/24" --cidr-deny="10.0.0.33/32"

tuna tcp 3389 --cidr-allow="10.0.0.1/24,192.168.0.1/24" --cidr-deny="10.0.0.33/32,192.168.0.33/32"

tuna ssh --cidr-allow="10.0.0.1/32"

tuna ssh --cidr-deny="10.0.0.1/32"

tuna ssh --cidr-allow="10.0.0.1/24" --cidr-deny="10.0.0.33/32"

tuna ssh --cidr-allow="10.0.0.1/24,192.168.0.1/24" --cidr-deny="10.0.0.33/32,192.168.0.33/32"

tuna postgres 5432 --cidr-allow="10.0.0.1/32"

tuna postgres 5432 --cidr-deny="10.0.0.1/32"

tuna postgres 5432 --cidr-allow="10.0.0.1/24" --cidr-deny="10.0.0.33/32"

tuna postgres 5432 --cidr-allow="10.0.0.1/24,192.168.0.1/24" --cidr-deny="10.0.0.33/32,192.168.0.33/32"

tuna redis 6379 --cidr-allow="10.0.0.1/32"

tuna redis 6379 --cidr-deny="10.0.0.1/32"

tuna redis 6379 --cidr-allow="10.0.0.1/24" --cidr-deny="10.0.0.33/32"

tuna redis 6379 --cidr-allow="10.0.0.1/24,192.168.0.1/24" --cidr-deny="10.0.0.33/32,192.168.0.33/32"

IP policies in Team​

In teams, if IP policies are specified, they will work in conjunction with these flags.

Update​

To update, follow the instructions.

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

🤷‍♂️ Why?​

During local development, it often happens that there is a tunnel with a static address that needs to be always accessible. For example, when testing our payments in YooKassa, we have a test store for each developer, where a static HTTP notification address is specified. Opening a separate terminal each time and typing tuna http -l ru -s test-yookassa-1 8080 becomes tedious, and I always forget to do it in advance, which leads to creating multiple invoices or waiting for the payment system to resend the notification.

We also know that sometimes access to a local resource needs to be opened not only for developers or system administrators, and the command line is not the most user-friendly interface.

Considering several factors, we decided to create a GUI application with a maximally simple interface, so even an accountant could use it comfortably.

🎯 Key Features​

Currently, at the time of the first release, the application has minimal features:

• HTTP tunnels
• TCP tunnels

Even this functionality is significantly limited compared to the console version, all in favor of simplicity. However, in the future, we plan to expand the functionality, for example, by adding a file server and basic authorization.

🧑‍💻 Supported Platforms​

We support all popular platforms: Windows, macOS, and Linux.
Below are the links for downloading and installation:

For macOS and Windows, we plan to publish through official app stores later.

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

Go to the Secrets section in the documentation

🔐 What are Tuna Secrets?​

The secrets service is designed to store settings for your applications that you run - locally, in CI/CD, or in your test and production environments. It is an excellent alternative to .env files and environment variables in CI/CD systems.

Secrets are:

• A single source of configuration for local development, CI/CD, staging, and production environments.
• Convenient management interface - via web, CLI, and API.
• Support for RBAC, comments, reminders, and change auditing.
• Flexible work with projects, environments, and configurations.
• All secrets are encrypted, keys are not stored in the database. A database leak will not lead to data disclosure.

👥 Who is it for?​

1. Developers — to simplify environment setup and reduce "magic" values in code.
2. DevOps engineers — for centralization and automation of configurations.
3. Teams — for secure and controlled shared access to confidential data.

🎯 Key Features​

We have implemented a structure that allows for effective secret management. In this video, you'll see a brief overview of the capabilities:

Hierarchy: projects → environments → configurations.

We follow a common structure, so secret storage is divided by projects, within projects there are environments, and within environments there are main or child configurations. Inside configurations, there are many functions for working directly with secrets and access to them, auditing, and more. When working in a Team, the roles section allows you to granularly distribute participant access to the needed environments in projects.

What else is in secrets?

• Configuration duplication - create unique configurations for each user.
• Variable types — you can specify bool, int, and other types.
• Generator and comments — convenient addition and annotation of secrets.
• Reminders — email notifications about the need to update a secret.
• Environment comparison — find differences between configurations.
• Secret hiding — exclude unique prod variables from comparison.
• Service keys — API keys for read/write access to a specific configuration.
• IP restriction — access control by CIDR.
• Change history — full audit of all actions.

⚙️ CLI Integration​

Naturally, the tuna console client is fully integrated:

• tuna secrets download — Getting secrets with the ability to save to a file (json, yaml, env) or output to stdout.
• tuna secrets setup — Setting up a directory for scope configuration.
• tuna secrets run — Automatic application configuration with passing environment variables directly to the process. And with the --watch flag, the application will restart automatically when a secret is changed in the personal account.

🛡️ Access Management and Security​

• RBAC in team — Provide access to environments precisely by users.
• Service keys — Issue unique keys for specific configurations with read or read and write restrictions. Perfect for use in CI/CD.
• Allowed IP addresses and subnets — Restrict access to secrets by specifying allowed IP addresses and subnets in CIDR format.
• Change history — Full audit of all actions and changes within configurations allows tracking who changed secrets and when.

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

Ранее для предоставления доступа к любым базам данных нужно было открывать доступ с помощью TCP туннеля, но теперь для Postgres и Redis мы добавили возможность запускать специализированный тип туннеля. При этом появляется аудит и инспекция запросов которые вы отправляете в базу.

Postgres​

Postgres туннель позволяет предоставить доступ к базе данных PostgreSQL и отслеживать выполняемые SQL запросы в инспекторе.

Слева отображается список сессий, а справа вывод команд, которые были выполнены внутри сессий.

Redis​

Redis туннель аналогично позволяет предоставить доступ к базе данных Redis и отслеживать выполняемые запросы в инспекторе.

Слева отображается список сессий, а справа вывод команд, которые были выполнены внутри сессий.

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

Будет произведена смена IP адресов и переезд к новому провайдеру.

• 178.20.41.29 > 37.252.22.27
• 178.20.43.146 > 37.252.21.90

Старый IP на адресе 178.20.41.29 продолжит работать, для обратной совместимости с пользовательскими доменами, что используют в dns А запись. По завершении работ мы объявим о дате полного отключения старого адреса, а всех владельцев пользовательскими доменов дополнительно уведомим о необходимости изменить DNS запись после проведения работ.

Работы необходимо провести в рамках модернизации инфраструктуры и повышения стабильности.

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

Будет произведена смена IP адресов и переезд к новому провайдеру.

• 193.33.194.47 > 89.19.217.251
• 62.84.101.212 > 147.45.238.190

Старый IP на адресе 193.33.194.47 продолжит работать, для обратной совместимости с пользовательскими доменами, что используют в dns А запись. По завершении работ мы объявим о дате полного отключения старого адреса, а всех владельцев пользовательскими доменов дополнительно уведомим о необходимости изменить DNS запись после проведения работ.

Работы необходимо провести в рамках модернизации инфраструктуры и повышения стабильности.

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community

Leave feedback​

If you enjoy using Tuna, or on the contrary you are not happy with something, please leave feedback.

Help​

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

• Email
• Telegram community