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

Ключ доступа (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 займёт одно касание.

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

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

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

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

Способ 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 и закладывайте время на поддержку.

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

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

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

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

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

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

В 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 и аудит.

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

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

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

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

Представьте: у вас есть внутренний сервис — админка, 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).

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

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

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

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

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

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

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

Проблема​

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

• бот, зарегистрированный через 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.

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

Доски​

Хедлайнер релиза!

Как и многие наши инструменты, Tuna Доски выросли из инструмента для внутреннего использования. Первые его версии были крайне примитивные и простые, но для нас этого всегда было достаточно.

Вот так проект выглядел исторически ...

Поэтому мы никогда не использовали другие аналоги вроде Miro и всегда старались использовать свой внутренний продукт. Если вы заметили, какие-либо схемы и фирменные рисунки сделаны именно в этом инструменте.

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

Встречи​

Видео звонки давно стали неотъемлемой частью любых онлайн-встреч, каждый уважающий себя разработчик, ненавидит эти проклятые созвоны, но теперь вы можете делать это на нашей платформе!

Встречайте, Tuna Встречи.

Функционал достаточно стандартный, есть режим докладчика, презентации, размытие фона и так далее. Интерфейс полностью адаптирован под мобильные устройства, поэтому вы можете созваниваться как за компьютером, так и в дороге.

Интеграции с трекерами задач​

После того, как у нас появились Отчеты и Мониторы, нам стало сразу понятно, что было бы удобно по инциденту в мониторах либо по новому отчету иметь возможность одной кнопкой создать задачу в GitLab, Jira или Яндекс.Трекере. Поэтому мы сделали интеграцию с основными популярными трекерами задач для того, чтобы вы могли быстро создавать задачи в вашем любимом трекере.

Фильтр в инспекторе запросов​

В инспекторе запросов добавилась строка фильтрации запросов по множеству параметров: тип запроса, статуса ответа, заголовки, IP-адрес и многое другое. Чтобы начать использовать, обновитесь до последней версии tuna-cli.

Улучшения в SSHd туннелях​

Не забываем развивать и туннели.

1. Добавлена поддержка Windows 11+, пользователь получит терминал PWSH.
2. Авто обнаружение $HOME, $SHELL и настроек профиля пользователя из под которого запущен SSHd туннель.
3. Переход на asciinema формат в ssh-sessions. Так, что сессии теперь пишут всё, включая работу в тестовых редакторах, запуск TUI утилит и т.д. Записи можно смотреть в терминале, встроить на сайт стандартным плеером или конвертировать в GIF командой tuna ssh-session export.

• Asciinema плеер
• GIF

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

Что изменилось?​

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

Почему переименовали?​

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

Смена тарифа с Профи на Легенду​

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

Что остаётся без изменений?​

• Стоимость подписок
• Лимиты и функции каждого тарифа
• Дополнительные лицензии
• Все активные подписки продолжают работать

Если у вас есть вопросы — свяжитесь с нами.

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

$ 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

Перейти к документации

Зачем нужен PROXY Protocol?​

При использовании туннелей ваше приложение видит подключения от туннельного сервера, а не от реального клиента. PROXY Protocol решает эту проблему — он передаёт оригинальный IP и порт клиента в заголовке соединения, что позволяет:

• Вести корректные логи подключений с реальными IP-адресами
• Применять правила контроля доступа на уровне приложения
• Собирать точную аналитику по географии пользователей

Новый флаг​

В команде tuna tcp появился новый флаг --proxy-protocol, принимающий версию протокола:

Примеры использования​

Базовый пример​

tuna tcp 8443 --proxy-protocol=1
# или с переменной окружения
TUNA_PROXY_PROTOCOL=1 tuna tcp 8443

Minecraft сервер​

Некоторые сборки игровых серверов, например Velocity, поддерживают PROXY Protocol. Включите его в конфиге игры и в клиенте tuna:

tuna tcp 45678 --proxy-protocol=2

Совместимость​

PROXY Protocol широко поддерживается популярным серверным ПО:

• Haproxy — поддерживает обе версии, определяет автоматически
• Nginx — поддерживает обе версии, определяет автоматически
• Envoy — поддерживает обе версии
• Многие базы данных и приложения через прокси-слой

Обновление​

Для обновления следуйте инструкции.

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

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

Что такое Tuna Мониторы?​

Мониторы позволяют контролировать работу ваших cron-задач, сервисов и инфраструктуры. При возникновении проблем вы сразу получите уведомление через настроенные каналы связи — email, Telegram, Slack и другие.

Мониторы — это:

• Отслеживание периодических задач (backup скриптов, cron задач)
• Проверка доступности веб-сайтов и API, туннелей из нескольких регионов
• Мониторинг сетевой инфраструктуры (TCP, DNS, ICMP)
• Автоматические уведомления при сбоях и восстановлении
• Интеграция с tuna CLI для удобной работы из терминала

Для кого?​

1. DevOps-инженерам — для мониторинга инфраструктуры и автоматизированных задач
2. Разработчикам — для отслеживания доступности API и сервисов
3. Системным администраторам — для контроля выполнения backup-скриптов и cron-задач
4. Командам — для централизованного мониторинга всех сервисов с общими уведомлениями

6 типов мониторов​

Tuna поддерживает 6 типов мониторов, разделённых на две категории:

Пользовательские мониторы​

Эти мониторы ожидают сигналы от ваших приложений и скриптов:

Внешние мониторы​

Эти мониторы самостоятельно проверяют доступность ваших ресурсов из нескольких географических регионов:

HTTP и TCP мониторы интегрированы с Туннелями. Если у вас есть активные туннели или зарезервированные домены/порты, то при создании монитора нужный ресурс будет в меню справа от адреса.

Ключевые возможности​

Мониторинг cron-задач​

Отслеживайте выполнение backup-скриптов, синхронизаций и других периодических операций:

# Простой backup с мониторингом
tuna monitor exec MONITOR_ID -- pg_dump -U postgres mydb > /backups/dump.sql

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

Система автоматически отправляет сигналы start, finish или fail, а также захватывает логи выполнения.

Heartbeat мониторинг​

Для сервисов в закрытых сетях, IoT устройств и фоновых процессов:

# Отправка heartbeat каждые 5 минут
*/5 * * * * tuna monitor ping MONITOR_ID --host=my-server

Проверка из нескольких регионов​

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

SSL/TLS и Whois мониторинг​

HTTP мониторы автоматически проверяют SSL-сертификаты и отслеживают срок действия домена, чтобы вы не пропустили момент продления.

Интеграция с уведомлениями​

Мониторы интегрированы с системой Контактов и Интеграций. Настройте уведомления в Telegram, Slack, по email или через webhook.

CLI-интеграция​

Консольный клиент tuna полностью интегрирован с мониторами:

• tuna monitor ping — отправка сигнала Heartbeat монитору
• tuna monitor exec — выполнение команды с автоматическим отслеживанием
• tuna monitor status — просмотр статуса мониторов

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

Уведомления и интеграции​

Уведомления и интеграции - это также большая часть нового функционала, которая интегрирована не только с мониторами, но и отчётами.

Поддерживаются популярные каналы связи: Telegram, Slack, Discord, VK Teams, Google Chat и произвольные Webhook. Группы контактов позволяют гибко управлять получателями — объединяйте email-адреса и интеграции в именованные группы, используйте одну группу для нескольких мониторов и легко добавляйте или удаляйте получателей без изменения настроек самих мониторов.

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

Перейти к разделу Отчёты в документации

Как это работает?​

1. Перейдите в личный кабинет и создайте проект в разделе Отчёты.

2. Добавьте на ваш сайт код перед закрытием тега <head>:

   <!-- tuna. Запись экрана и действий пользователей -->
   <script>
       window.reportOptions = {
           captureKey: "YOUR_CAPTURE_KEY"
       };
   </script>
   <script src="https://reports.tuna.am/latest/index.js" async></script>
   

3. Вызовите скрипт CTRL + ALT + S или ⌘ + ⌥ + S и создайте отчёт.

Как выглядит отчёт?​

Внутри отчёта будет скриншот или видео и вся отладочная информация из консоли, сетевые операции, действия пользователя и снимок DOM-дерева страницы.

• Информация
• Инспектор
• Консоль
• Сеть
• Действия
• Комментарии

На первой вкладке содержится общая сводная информация о клиенте, устройстве, браузере...

Видео обзор​

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

Вебхуки​

Политика трафика​

Помимо простого ответа теперь можно описать сложные правила обработки вебхука, имитируя например ответ API. Важно отметить что это будет работать даже на бесплатном тарифе и вы можете попробовать политики трафика бесплатно.

Пересылка запроса в туннель​

Если у вас есть запущенные туннели вы можете переслать в него принятый запрос. Нам показалось это может быть удобно и полезно при отладке чего-то на начальных этапах.

TOTP в Менеджере паролей​

Появились долгожданные TOTP (Time-based one-time) пароли. Это значит, что если у вас есть 1 аккаунт от стороннего сервиса на команду, теперь вы можете спокойно включить 2FA.

Улучшение дистрибуции клиентов​

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

Мы делаем упор на безопасности, поэтому рекомендуем проверять, что вы используете именно наши официальные сборки клиентов. Теперь все артефакты сборки, архивы, пакеты, инсталляторы, checksum файлы и docker образы подписываются нашей электронной подписью.

• Публичный GPG ключ для верификации распространяется по ссылке - https://releases.tuna.am/tuna.asc
• Публичный Cosign ключ для верификации Docker images - https://releases.tuna.am/tuna-cosign.asc

Дистрибуция для ALT Linux​

Добавили поддержку дистрибуции для российского ALT Linux, подробнее в инструкции по установке.

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

Обзор​

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

К счастью, есть такой прекрасный ресурс как VirusTotal, по сути это агрегатор. В нём вы можете проверить ресурс (домен, ip, файл) на присутствие в базах каких либо - антивирусов. Всё очень просто и наглядно, выглядит примерно так:

VirusTotal имеет публичное API, ещё cli утилиту, готовые клиенты для некоторых языков и если зарегистрироваться и получить API Key, то можно всё неплохо автоматизировать, что позволит узнавать о присутствии в базах максимально оперативно. Что мы и сделали. Но стоит помнить, что на бесплатном тарифе есть некоторые ограничения по количеству запросов, но на дюжину доменов/ip вам точно хватит.

Как использовать?​

В репозитории вы найдёте бинарные сборки и образы docker для запуска, а также инструкцию по конфигурации. Мы будем рады обратной связи и merge requests.

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

Перейти в личный кабинет

Обзор​

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

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

Новые флаги​

В командах tuna tcp, tuna ssh, tuna postgres и tuna redis появились новые флаги и аналоги env:

--cidr-allow # Отклонять соединения, которые не соответствуют заданным CIDR
--cidr-deny # Отклонить соединения, соответствующие заданным CIDR

TUNA_CIDR_ALLOW # Отклонять соединения, которые не соответствуют заданным CIDR
TUNA_CIDR_DENY # Отклонить соединения, соответствующие заданным CIDR

Примеры использования​

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 политики в Легенде​

В командах, если указаны IP политики, то он будут работать в комплексе с этими флагами.

Обновление​

Для обновления следуйте инструкции.

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

🤷‍♂️ Зачем?​

При локальной разработке часто бывает так, что есть какой-то туннель с статичным адресом, который должен быть доступен всегда. Например, когда мы тестируем наши платежи в ЮКасса, у нас есть тестовый магазин для каждого разработчика, где прописан статичный адрес HTTP уведомления. Открывать каждый раз отдельный терминал и писать tuna http -l ru -s test-yookassa-1 8080 становится утомительно, я каждый раз забываю сделать это заранее и приходится создавать несколько счетов или ждать когда платёжная система отправит повторное уведомление.

Также мы знаем, что порой открыть доступ к локальному ресурсу нужно не только разработчикам или системным администраторам, а командная строка не самый дружелюбный интерфейс.

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

🎯 Ключевые возможности​

Сейчас на момент первого релиза приложение имеет минимум возможностей:

• HTTP туннели
• TCP туннели

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

🧑‍💻 Поддерживаемые платформы​

Мы поддерживаем все популярные платформы Windows, macOS и Linux - инструкция по установке.

Для macOS и Windows позже планируем публикацию через официальные магазины приложений.

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

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

🔐 Что такое Tuna Секреты?​

Сервис секретов предназначен для хранения настроек к вашим приложениям, которые вы запускаете - локально, в CI/CD или в своих тестовых и продуктовых окружениях. Он является отличной альтернативой .env файлам и переменным окружениям в CI/CD системах.

Секреты — это:

• Единый источник конфигурации для локальной разработки, CI/CD, staging и production сред.
• Удобный интерфейс управления — через веб, CLI и API.
• Поддержка RBAC, комментариев, напоминаний и аудита изменений.
• Гибкая работа с проектами, окружениями и конфигурациями.
• Все секреты шифруются, ключи не хранятся в базе. Утечка БД не приведёт к раскрытию данных.

👥 Для кого?​

1. Разработчикам — для упрощения настройки окружений и сокращения "магических" значений в коде.
2. DevOps-инженерам — для централизации и автоматизации конфигураций.
3. Командам — для безопасного и контролируемого совместного доступа к конфиденциальным данным.

🎯 Ключевые возможности​

Мы внедрили структуру, позволяющую эффективно управлять секретами.
В этом ролике вы увидите небольшой обзор возможностей:

Иерархия: проекты → окружения → конфигурации.

Мы придерживаемся общепринятой структуры, поэтому хранение секретов разделяется по проектам, внутри проектов есть окружения, а внутри окружений конфигурации основные или дочерние. Внутри конфигураций сосредоточенно множество функций работы непосредственно с секретами и доступом к ним, аудит и прочее. При работе в Команде, в разделе с ролями появляется возможность гранулярно распределять доступ участников к нужным окружениям в проектах.

Что ещё есть в секретах?

• Дублирование конфигураций - создавайте уникальные конфигурации для каждого пользователя.
• Типы переменных — можно указать тип bool, int и др.
• Генератор и комментарии — удобное добавление и аннотация секретов.
• Напоминания — email-уведомления о необходимости обновить секрет.
• Сравнение окружений — находите различия между конфигурациями.
• Скрытие секретов — исключите из сравнения уникальные прод-переменные.
• Сервисные ключи — API-ключи на чтение/запись для конкретной конфигурации.
• Ограничение по IP — контроль доступа по CIDR.
• История изменений — полный аудит всех действий.

⚙️ CLI-интеграция​

Естественно консольный клиент tuna полностью интегрирован:

• tuna secrets download — Получение секретов с возможностью сохранения в файл (json, yaml, env) или вывода в stdout.
• tuna secrets setup — Настройка каталога для конфигурации области действия.
• tuna secrets run — Автоматическая конфигурация приложения с передачей переменных окружения непосредственно процессу. А с указанием флага --watch, перезапуск приложения будет автоматический, при изменении секрета в личном кабинете.

🛡️ Управление доступом и безопасность​

• RBAC в команде — Предоставляйте доступ к окружениям точечно по пользователям.
• Сервисные ключи — Выпускайте уникальные ключи для конкретных конфигураций с ограничением на чтение или чтение и запись. Идеально подходит для использования в CI/CD.
• Разрешенные IP адреса и подсети — Ограничивайте доступ к секретам, указывая разрешенные IP адреса и подсети в формате CIDR.
• История изменений — Полный аудит всех действий и изменений внутри конфигураций позволяет отслеживать, кто и когда изменил секреты.

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

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

Postgres​

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

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

Redis​

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

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

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

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

• 178.20.41.29 > 37.252.22.27
• 178.20.43.146 > 37.252.21.90

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

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

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

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

• 193.33.194.47 > 89.19.217.251
• 62.84.101.212 > 147.45.238.190

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

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

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество

Оставьте отзыв​

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Помощь​

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество