Кто может зайти в ваш внутренний сервис? 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 и закладывайте время на поддержку.
Попробуйте прямо сейчас
Перейдите в раздел Приложения, нажмите + Добавить приложение — и закройте свой первый сервис авторизацией за пару минут.
Подробное описание всех возможностей — в докум ентации:
Оставьте отзыв
Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.
Помощь
Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов: