Hodor — минимализм в вопросах аутентификации

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

Hodor решает её иначе. Вместо сложной инфраструктуры он предлагает один бинарник и один общий пароль. Никаких баз, никаких токенов, никаких ролей — просто защитный слой перед вашим приложением.

Когда минимализм оправдан

Hodor не претендует на универсальность. Его ниша — внутренние инструменты, staging-среды, proof-of-concept и небольшие командные дашборды. Там, где все и так используют один пароль, нет смысла строить полноценную систему управления учётными записями.

Что Hodor сознательно не делает

• Не хранит пользователей и не ведёт базу данных
• Не интегрируется с внешними провайдерами идентификации
• Не усложняет работу с сессиями — только простая cookie-аутентификация
• Работает как единый бинарник без внешних зависимостей

Это значит, что для запуска достаточно указать пароль и запустить прокси перед приложением. Никаких дополнительных настроек.

Где Hodor показывает себя лучше всего

• Внутренние дашборды и мониторинг — когда команде нужен доступ к метрикам, но не хочется заводить отдельные аккаунты.
• Staging и тестовые окружения — защита без лишних накладных расходов.
• Быстрые демо-версии — когда нужно показать проект заказчику за пару минут.
• Небольшие командные проекты — когда все и так работают под одним паролем.
• Self-hosted сервисы — добавление защиты без усложнения инфраструктуры.

Честный разговор о компромиссах

У такого подхода есть очевидные ограничения:

• Нет аудита — все пользователи выглядят одинаково.
• Нет разграничения прав — либо полный доступ, либо ничего.
• Смена пароля затрагивает всю команду сразу.
• Пароль легко разлетается по чатам и документации.

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

Как это работает на практике

Hodor располагается между клиентом и приложением. При первом запросе он проверяет наличие cookie. Если её нет — показывает страницу входа. После ввода правильного пароля устанавливает cookie и начинает проксировать трафик. Всё остальное приложение получает уже аутентифицированные запросы.

Никаких сложных хранилищ сессий и токенов — только простой цикл «запрос → проверка → прокси».

Когда Hodor уместен, а когда нет

Если у вас сейчас вообще нет защиты — Hodor уже заметно повышает уровень безопасности. Если пароли и так летают в Slack — Hodor хотя бы формализует этот процесс. А вот если нужна granular-права и аудит — лучше сразу смотреть в сторону полноценных решений.

Hodor честно признаёт свой threat model: он защищает от случайного доступа и сканирования, но не от targeted-атак. Это не замена security-команде, а просто запертая дверь.

Развёртывание

Hodor легко вписывается в существующую инфраструктуру: Docker, Kubernetes, обычные виртуалки. Главное — не забыть про HTTPS, чтобы пароль не передавался в открытом виде. Один экземпляр можно поставить перед несколькими приложениями одновременно.

Философия инструмента

Hodor — это пример «правильного размера» решения. Не каждое приложение нуждается в enterprise-аутентификации. Иногда достаточно простого механизма, который решает 80 % реальных задач без избыточной сложности.

Если вы ищете способ быстро защитить Grafana, внутренний сервис или личный проект — стоит присмотреться. Иногда именно такие минималистичные инструменты оказываются самыми практичными.

С чего начать

Репозиторий Hodor доступен на GitHub. Документация короткая, а запуск действительно простой. Если вы давно откладывали защиту внутренних инструментов из-за страха перед сложностью аутентификации — Hodor снимает это препятствие.