Produkční nasazení Keycloaku: na co myslet, než přepnete ostro

Keycloak v testovacím prostředí rozjedete za odpoledne. Produkční nasazení, které vydrží výpadek databáze, přežije aktualizaci bez přerušení provozu a upozorní vás na bezpečnostní incident dříve, než ho zpozorují uživatelé – to je jiná disciplína.

Tenhle článek nepokrývá každý konfigurační parametr. Pokrývá rozhodnutí, která ovlivní, jak se vám bude Keycloak spravovat za rok, za dva, za pět.

Proč na produkčním nasazení záleží více než u jiných systémů

Keycloak je identitní brána. Pokud nefunguje, uživatelé se nemohou přihlásit do žádné aplikace, která na něj spoléhá. Výpadek Keycloaku neznamená, že jedna funkce nefunguje – znamená, že nefunguje nic.

To ho řadí mezi kritickou infrastrukturu – podobně jako firemní e-mail nebo VPN. A kritická infrastruktura vyžaduje jiný přístup k nasazení než interní nástroj, který si firma může dovolit na hodinu vypnout.

Dobrá zpráva: Keycloak je na tuto roli navržený. Zvládá vysokou dostupnost, bezpečnostní monitorování i aktualizace bez přerušení provozu. Ale jen pokud je správně nakonfigurovaný od začátku.

Dostupnost: co se stane, když jeden server padne

Základní instalace Keycloaku běží na jednom serveru. Pokud tento server padne – výpadek hardwaru, restart při aktualizaci nebo přetížení – uživatelé se nepřihlásí. Pro testování to nevadí. Pro produkci to nestačí.

Produkční nasazení Keycloaku typicky běží na minimálně dvou instancích, které jsou navzájem synchronizované. Pokud jedna přestane reagovat, druhá přebere provoz automaticky – uživatelé nic nepoznají.

Kubernetes, tedy kontejnerová platforma, na které moderní aplikace běží, toto přepínání zvládá bez lidského zásahu.

Synchronizace mezi instancemi je klíčová: pokud se uživatel přihlásí přes první instanci a jeho další požadavek zpracuje druhá, musí druhá instance vědět, že tento uživatel je přihlášený.

Keycloak tuto synchronizaci řeší automaticky přes distribuovanou cache Infinispan, která mezi instancemi synchronizuje data po síti – ale pouze pokud jsou instance správně propojené.

Špatně nakonfigurovaný cluster se tváří jako fungující, dokud si uživatel při přepnutí na druhou instanci nevšimne, že je najednou odhlášený.

Vysoká dostupnost tedy není jen otázka „máme dva servery“. Je to otázka, jestli tyto servery správně spolupracují.

Ověřte to před spuštěním do produkce – ne po něm.

Bezpečnost: co nastavit ještě před prvním přihlášením

Keycloak má rozumné výchozí bezpečnostní nastavení, ale pro produkci ho nestačí nechat tak, jak je po instalaci. Tři věci byste měli nastavit ještě před prvním ostrým přihlášením.

Ochrana proti útokům hrubou silou

Keycloak umí automaticky zablokovat účet po opakovaných neúspěšných pokusech o přihlášení. Výchozí nastavení je vypnuté.

Zapněte ho a nastavte přiměřené limity – například zablokování na 15 minut po pěti neúspěšných pokusech.

Útočník, který zkouší hesla automatizovaně, narazí na zeď. Uživatel, který zapomněl heslo, se za chvíli zkusí přihlásit znovu.

Délka platnosti tokenů a SSO session

Keycloak rozlišuje dvě nezávislé věci: access token a SSO session.

Access token má krátkou platnost. Je to to, co aplikace předkládá API. Výchozí hodnota bývá krátká, typicky v řádu minut.

SSO session určuje, jak dlouho trvá přihlášení v Keycloaku. Výchozí maximum bývá výrazně delší, typicky v řádu hodin.

Obojí nastavujete zvlášť. Pro SSO session je osm hodin odpovídajících délce pracovního dne rozumný kompromis. Access token nechte krátký – odcizený token pak platí jen minuty, ne hodiny.

Vícefaktorové ověření

Keycloak podporuje ověřování přes autentizační aplikaci, hardwarové bezpečnostní klíče i moderní biometriku, například Windows Hello nebo Touch ID.

MFA výrazně snižuje riziko zneužití odcizených přihlašovacích údajů. Keycloak ho navíc umožňuje vyžadovat selektivně – například jen pro přístup k citlivým aplikacím nebo pro uživatele mimo firemní síť.

Aktualizace: jak udržet Keycloak aktuální bez výpadků

Keycloak vychází s novými verzemi pravidelně. U produkčního nasazení proto nejde o otázku, jestli aktualizovat, ale jak aktualizovat bezpečně.

Od verze 26 Keycloak rozlišuje LTS vydání, tedy Long-Term Support, a standardní vydání. LTS verze mají delší podporu a jsou vhodnější pro produkční provoz. Standardní vydání mají kratší podporu a vyžadují rychlejší upgrade cyklus.

Bezpečnostní záplaty se typicky backportují do podporovaných větví. Pro produkci proto doporučujeme stavět na LTS vydání. Starší verze mimo podporu časem přestanou dostávat opravy zranitelností.

Aktualizace Keycloaku v produkci přitom nemusí znamenat výpadek. Při správně nakonfigurovaném nasazení se instance aktualizují postupně.

První instance se aktualizuje a restartuje, druhá mezitím obsluhuje provoz. Pak se aktualizuje druhá, zatímco první už běží v nové verzi. Celý proces může proběhnout bez přerušení – uživatelé nic nepoznají.

Předpokladem je, že aktualizace nevnáší breaking changes, které by způsobily nekompatibilitu mezi starou a novou verzí.

Keycloak k novým verzím publikuje migration guide, kde takové změny popisuje. Přečíst ho před každou aktualizací není volitelné – je to povinný krok procesu.

Osvědčený postup

Před každou aktualizací produkce aktualizujte nejdřív staging prostředí, které by mělo být pokud možno identické s produkcí.

Otestujte základní scénáře: přihlášení, odhlášení, integrace klíčových aplikací a komunikaci s adresářovou službou.

Pokud staging prošel, produkce by měla projít také.

Monitoring: vědět o problému dříve, než ho zahlásí uživatelé

Identity provider, o kterém se nic nedozvíte, dokud ho nezačnou hlásit uživatelé, je identity provider, který vám způsobí problémy.

Keycloak vystavuje metriky ve standardním formátu, který umí zpracovat běžné monitorovací nástroje jako Prometheus a Grafana.

Počet neúspěšných přihlášení

Náhlý nárůst může signalizovat brute-force útok nebo výpadek integrace s Active Directory. Obojí chcete vědět co nejdříve.

Rychlost zpracování přihlášení

Keycloak by měl přihlášení zpracovat v řádu desetin sekundy. Pokud průměrná doba začne narůstat, je to první příznak problému – například přetížené databáze, špatné konfigurace cache nebo síťového problému.

Zdraví databázového připojení

Keycloak ukládá konfiguraci, uživatele a session data do databáze. Pokud databáze přestane reagovat, Keycloak přestane fungovat.

Monitorujte počet aktivních připojení a dobu odezvy databáze.

Dostupnost jednotlivých instancí

V clusteru chcete vědět okamžitě, pokud jedna z instancí přestane reagovat.

Hotové dashboardy pro Grafanu jsou dostupné jako open-source. Nemusíte je stavět od nuly. Nastavení monitorování je práce na jeden den, která vám může ušetřit hodiny diagnostiky při prvním incidentu.

Zálohy a obnova: co dělat, když se něco pokazí

Keycloak ukládá veškerou konfiguraci a data uživatelů do databáze. Databáze je primární záloha – bez ní nelze Keycloak obnovit.

Databáze

Zálohujte celou databázi pravidelně, minimálně jednou denně. Zálohu ukládejte mimo produkční infrastrukturu. Pokud přijdete o server i zálohu zároveň, nemáte nic.

Export konfigurace

Keycloak umožňuje exportovat nastavení celého realmu jako JSON soubor – například přihlašovací toky, nastavení aplikací, role a skupiny.

Tento export je rychlý způsob, jak obnovit konfiguraci do nové instance nebo přenést nastavení mezi prostředími.

Doporučujeme ho dělat před každou větší změnou konfigurace.

Pozor: export z admin console neobsahuje uživatelská hesla ani credentials. Pro úplnou obnovu včetně uživatelů je nutná databázová záloha nebo CLI export.

Zálohy bez pravidelného testování obnovy jsou jen předpoklad. Jednou za kvartál si ověřte, že z dostupné zálohy dokážete Keycloak skutečně obnovit.

Zjistit při incidentu, že záloha je poškozená nebo neúplná, je špatná chvíle na takové zjištění.

Kubernetes: standardní platforma pro moderní nasazení

Většina firem, které Keycloak nasazují dnes, ho provozuje na Kubernetes – kontejnerové platformě, která automatizuje nasazování, škálování a obnovu aplikací.

Kubernetes zvládá restartovat padlou instanci Keycloaku bez lidského zásahu, rozložit provoz mezi více instancí a provést aktualizaci bez výpadku.

Pro nasazení na Kubernetes máte dvě základní cesty: Helm chart nebo Keycloak Operator.

Helm chart

Helm chart je konfigurační šablona, kterou si přizpůsobíte podle vlastního prostředí.

Keycloak Operator

Keycloak Operator je komponenta, která automatizuje lifecycle management Keycloaku, včetně upgradů.

Pro nové instalace doporučujeme Operator – je to směr, do kterého Keycloak komunita investuje, a přináší více automatizace za méně ruční práce.

Pokud Kubernetes nespravujete sami a Keycloak byste chtěli provozovat bez starostí o infrastrukturu, existuje i managed varianta.

Chcete Keycloak bez starostí o provoz?

Produkční nasazení Keycloaku je projekt, který vyžaduje zkušenosti s identity managementem, Kubernetes a bezpečnostní konfigurací.

Výsledek – stabilní, bezpečně nakonfigurovaná identitní platforma – se vyplatí. Ale ne každý tým má kapacitu nebo chuť se tím zabývat sám.

BOOTIQ provozuje Keycloak jako managed službu. Nasadíme ho, nakonfigurujeme pro vaše prostředí a postaráme se o provoz: pravidelné aktualizace, monitoring, zálohy a incident response.

Váš tým se může soustředit na to, co umí nejlépe.