Кто может зайти в ваш внутренний сервис? 5 способов закрыться авторизацией
Внутренние сервисы иногда нужно открывать — сотруднику, подрядчику или заказчику. Например, открыть staging, служебную панель, внутреннюю админку или API для интеграций. Или HTTP-сервис без собственной авторизации, вроде Prometheus или Alertmanager.
Возникает задача: не встраивать логин в каждый сервис отдельно, а поставить перед ним слой доступа и решить, кого пускать, каким способом и к каким путям.
Способов решить эту задачу несколько, и каждый хорош для своей ситуации. Разберём от самых простых к более гибким по контролю. В конце — сравнительная таблица.
Перейти к разделу Приложения в документации
Способ 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.
Сравнение
| Известен пользователь | Правила доступа | MFA | Отзыв доступа | Сложность запуска | Поддержка | |
|---|---|---|---|---|---|---|
| VPN | частично (на уровне сети) | нет | зависит от VPN | вручную, профиль | средняя–высокая | постоянная |
| Basic auth | нет | нет | нет | нельзя точечно | минуты | нулевая |
| IP-фильтры | нет (только откуда) | нет | нет | правкой списка | минуты | рутина со списками |
| nginx + oauth2-proxy | да | да, собирается вручную | да | вручную | дни | на вашей стороне |
| Zero Trust proxy (Tuna Apps) | да | да, из интерфейса | да | в один шаг из интерфейса | минуты | на стороне платформы |
Итог: как выбрать
Показываете демо на пару дней → хватит 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: