Hodor – prosty strażnik Twoich aplikacji webowych

Każdy, kto budował dashboardy, środowiska stagingowe czy narzędzia monitorujące, zna ten moment. Potrzebujesz ochrony, a tradycyjne rozwiązania ciągną za sobą bazy użytkowników, hashowanie haseł i integracje OAuth. W efekcie tworzysz skomplikowaną infrastrukturę dla prostego problemu: „nie wpuszczać obcych”.

Hodor rozwiązuje to inaczej. To lekki reverse proxy, który stawia przed aplikacją jedną, wspólną bramę logowania. Nic więcej – zero baz danych, brak zarządzania kontami, tylko jedno hasło i gotowe.

Kiedy prostota ma sens

Hodor nie jest narzędziem dla każdego. Nie nadaje się do publicznych platform SaaS z tysiącami użytkowników. Za to świetnie sprawdza się tam, gdzie zespół jest mały i ufa sobie nawzajem.

• Wewnętrzne dashboardy – szybki dostęp dla zespołu ops bez tworzenia kont dla każdego.
• Środowiska testowe – ochrona przedprodukcyjnych wersji bez zbędnego overheadu.
• Prototypy – pokazujesz coś klientowi, nie budując pełnego systemu autentykacji.
• Małe projekty zespołowe – gdy i tak wszyscy używają tego samego hasła.

Co Hodor pomija (i dlaczego to jego siła)

Cała elegancja tego narzędzia wynika z tego, czego w nim nie ma:

• Brak bazy użytkowników – nie musisz projektować schematów ani obsługi CRUD.
• Brak integracji z zewnętrznymi dostawcami tożsamości.
• Brak skomplikowanego zarządzania sesjami – wystarczy prosta cookie.
• Jedna binarka obsługuje całość.

Wystarczy postawić Hodor przed aplikacją, podać hasło i działa. Bez konfiguracji middleware’ów na wielu warstwach.

Szczerze o ograniczeniach

Trzeba być świadomym kompromisów:

• Brak śladów audytowych – nie wiesz, kto dokładnie co zrobił.
• Brak uprawnień granularnych – dostęp jest albo pełny, albo go nie ma.
• Rotacja haseł – gdy ktoś odchodzi z zespołu, trzeba zmieniać hasło wszystkim.
• Ryzyko udostępniania – hasło może trafić na Slacka lub do dokumentacji.

Te ograniczenia sprawiają, że Hodor działa najlepiej w zaufanych, niewielkich zespołach.

Jak to działa w praktyce

Hodor działa jako reverse proxy. Gdy ktoś wchodzi na aplikację:

1. Przechwytuje żądanie.
2. Sprawdza cookie z autentykacją.
3. Jeśli jej nie ma – pokazuje stronę logowania.
4. Po poprawnym haśle ustawia cookie.
5. Kolejne żądania przekazuje już do właściwej aplikacji.

Bez złożonych mechanizmów sesji, bez tokenów i OAuth. Prosto i skutecznie.

Bezpieczeństwo – kontekst ma znaczenie

Architekci bezpieczeństwa zazwyczaj nie lubią wspólnego hasła. Ale Hodor nie udaje, że rozwiązuje każdy scenariusz. Chroni przed przypadkowym dostępem i skanowaniem zewnętrznym – nie przed zaawansowanymi atakami.

Jeśli obecnie nie masz żadnej ochrony, Hodor to duży krok naprzód. Jeśli i tak wymieniacie hasła na czacie, Hodor po prostu formalizuje tę praktykę w bardziej uporządkowany sposób.

Wdrożenie

Jako reverse proxy Hodor wpisuje się w istniejącą infrastrukturę:

• Działa w sieci wewnętrznej lub prywatnej chmurze.
• Najlepiej łączyć go z HTTPS – transmisja hasła musi być szyfrowana.
• Obsługuje Docker, Kubernetes i zwykłe maszyny wirtualne.
• Można go ustawić przed wieloma aplikacjami jednocześnie.

Filozofia, która ma sens

Hodor to przykład narzędzia, które robi dokładnie jedną rzecz i robi ją dobrze. Nie próbuje być pełnopłatną platformą tożsamości. Jest po prostu prostym strażnikiem, który rozwiązuje konkretny problem bez nadmiarowej złożoności.

Jeśli chronisz Grafanę, wewnętrzny serwis albo własny projekt – warto mieć Hodor w zanadrzu. Czasem najprostsze rozwiązanie okazuje się najlepsze.

Jak zacząć

Projekt jest dostępny na GitHubie. Dokumentacja jest czytelna, a wdrożenie naprawdę proste. Jeśli odkładasz zabezpieczenie narzędzi wewnętrznych, bo boisz się złożoności – Hodor właśnie tę wymówkę usuwa.

Proste narzędzia dla prostych problemów. Czasem właśnie tego nam w rozwoju brakuje.