🥇Vi kör Keycloak i HA-läge på Kubernetes

TL;DR: kommer en beskrivning av Keycloak, ett system för åtkomstkontroll med öppen källkod, en analys av dess inre uppbyggnad och detaljer om konfiguration.

Introduktion och grundläggande idéer

I denna artikel kommer vi att se de grundläggande idéerna att tänka på när man distribuerar en Keycloak-kluster ovanpå Kubernetes.

Om du vill veta mer om Keycloak — vänligen se länkarna i slutet av artikeln. För att dyka djupare in i praktiken kan du studera vår repository med modulen som implementerar de grundläggande idéerna i denna artikel (en guide till att starta finns där också, i denna artikel kommer vi att ge en översikt av dess struktur och inställningar, översättarens anm.).

Keycloak är ett omfattande system, skrivet i Java och byggt ovanpå applikationsservern Wildfly. Kort sagt, det är ett ramverk för autentisering som ger applikationsanvändare federation och möjlighet till SSO (single sign-on).

Vi inbjuder dig att läsa den officiella webbplats eller Wikipedia för att få en djupare förståelse.

Körning av Keycloak

För att köra Keycloak krävs två permanent lagrade datakällor:

En databas som används för att lagra beständiga data, till exempel information om användare
Datagrid-cache, som används för att cacha data från databasen, och för att lagra vissa kortlivade och ofta ändrade metadata, till exempel användarsessioner. Implementeras av Infinispan, som vanligtvis är betydligt snabbare än databasen. Men i alla fall är de data som lagras i Infinispan efemära — och de behöver inte sparas någonstans vid omstart av klustret.

Keycloak fungerar i fyra olika lägen:

Standard — en och endast en process, konfigureras via filen standalone.xml
Standardkluster (hög tillgänglighetsvariant) — alla processer måste använda samma konfiguration, som måste synkroniseras manuellt. Inställningarna lagras i filen standalone-ha.xml, det krävs dessutom att man gör databasen och belastningsbalanseraren gemensam.
Domänkluster — att starta ett kluster i standardläge blir snabbt rutinartat och tråkigt när klustret växer, eftersom varje gång konfigurationen ändras måste alla ändringar genomföras på varje nod i klustret. Domänläget löser detta genom att ställa in något gemensamt lagringsutrymme och publicera konfigurationen. Dessa inställningar lagras i filen domain.xml
Replikering mellan datacenter — om du vill köra Keycloak i en klusterkonfiguration med flera datacenter, oftast geografiskt spridda. I detta driftsätt kommer varje datacenter att ha sin egen kluster av Keycloak-servrar.

I den här artikeln kommer vi att gå igenom det andra alternativet, det vill säga det vanliga klustret, och vi kommer även att beröra ämnet kring replicering mellan datacenter, eftersom dessa två alternativ kan vara meningsfulla att köra i Kubernetes. Lyckligtvis finns det inget problem med att synkronisera inställningar mellan flera pods (Keycloak-noder) i Kubernetes, så domenklustret blir inte särskilt svårt att skapa.

Observera också att ordet kluster fram till slutet av artikeln kommer att användas enbart i samband med en grupp av Keycloak-noder som arbetar tillsammans, utan att referera till Kubernetes-klustret.

Vanligt kluster av Keycloak

För att köra Keycloak i detta läge behövs:

konfigurera en extern gemensam databas
installera en lastbalanserare
ha ett internt nätverk med stöd för IP-multicast

Vi kommer inte att gå in på konfigurationen av den externa databasen, eftersom den inte är målet för denna artikel. Låt oss anta att det finns en fungerande databas någonstans — och att vi har en anslutningspunkt till den. Vi lägger helt enkelt till dessa uppgifter som miljövariabler.

För att bättre förstå hur Keycloak fungerar i en hög tillgänglighets (HA) kluster är det viktigt att veta hur mycket detta beror på Wildflys klusteringsförmåga.

Wildfly använder flera delsystem, vissa av dem används som lastbalanserare, andra för hög tillgänglighet. Lastbalanseraren säkerställer applikationens tillgänglighet vid överbelastning av en nod i klustret, medan hög tillgänglighet garanterar applikationens tillgång även vid fel på vissa noder i klustret. Vissa av dessa delsystem är:

mod_cluster: arbetar tillsammans med Apache som en HTTP-lastbalanserare, är beroende av TCP multicast för att hitta noder som standard. Kan ersättas av en extern lastbalanserare.
infinispan: en distribuerad cache som använder JGroups-kanaler som transportlager. Kan dessutom använda HotRod-protokollet för kommunikation med ett externt Infinispan-kluster för att synkronisera cacheinnehållet.
jgroups: tillhandahåller gruppkommunikationsstöd för hög tillgänglighetstjänster baserade på JGroups-kanaler. Namngivna kanaler låter applikationsinstanser i klustret ansluta till grupper så att kommunikationen har egenskaper som tillförlitlighet, ordning och felkänslighet.

Lastbalanserare

När lastbalanseraren installeras som ingress-controller i Kubernetes-klustret är det viktigt att tänka på följande saker:

Keycloaks funktion förutsätter att den externa klientens adress, som ansluter via HTTP till autentiseringstjänsten, är den verkliga IP-adressen för klientdatan. Inställningarna för lastbalanseraren och ingress måste korrekt ställa in HTTP-huvuden X-Forwarded-For och X-Forwarded-Proto, samt bevara den ursprungliga rubriken HOST. Den senaste versionen ingress-nginx (> 0.22.0) deaktiverar detta som standard

Aktivera flaggan proxy-address-forwarding genom att ställa in miljövariabeln PROXY_ADDRESS_FORWARDING på true ger Keycloak förståelse för att den körs bakom en proxy.

Det är också nödvändigt att aktivera sticky sessions i ingress. Keycloak använder Infinispan distribuerad cache för att lagra data relaterade till den aktuella autentisering sesssionen och användarsessionen. Cacher fungerar med en enda ägare som standard, med andra ord sparas denna specifika session på en nod i klustret, och andra noder måste begära den på distans om de behöver åtkomst till denna session.

Konkreta uppgifter har trots dokumentationen inte fungerat med namnet cookie för sessionen AUTH_SESSION_ID. Keycloak orsakade en omdirigeringsloop, så vi rekommenderar att välja ett annat cookie-namn för sticky session.

Dessutom bifogar Keycloak namnet på den nod som först svarade till AUTH_SESSION_ID, och eftersom varje nod i den hög tillgängliga versionen använder samma databas, måste varje nod ha en separat och unik nodidentifierare för att hantera transaktionerna. Det rekommenderas att sätta i JAVA_OPTS parametrar jboss.node.name och jboss.tx.node.id unika för varje nod - du kan till exempel sätta podnamnet. Om du använder podnamn, kom ihåg att det finns en begränsning på 23 tecken för jboss-variabler, så det är bättre att använda StatefulSet istället för Deployment.

Ett annat problem är att om en server tas bort eller startas om, kommer dess cache att försvinna. Med det i åtanke bör antalet cacheägare för alla cacher ställas in på minst två, så att en kopia av cachen kvarstår. Lösningen är att köra skriptet för Wildfly vid uppstarten av podden, genom att inkludera det i katalogen /opt/jboss/startup-scripts i containern:

Innehållet i skriptet

embed-server --server-config=standalone-ha.xml --std-out=echo
batch

echo * Sätter CACHE_OWNERS till "${env.CACHE_OWNERS}" i alla cache-containrar

/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})

run-batch
stop-embedded-server

därefter ställa in värdet för miljövariabeln CACHE_OWNERS till det som krävs.

Privat nätverk med stöd för IP multicast

Om du använder Weavenet som CNI kommer multicast att fungera direkt — och dina Keycloak-noder kommer att se varandra så snart de startas.

Om du inte har stöd för IP multicast i Kubernetes-klustret kan du konfigurera JGroups för att fungera med andra protokoll för nodupptäckten.

Det första alternativet är att använda KUBE_DNS, som använder headless service för att hitta Keycloak-noder, du anger helt enkelt JGroups namnet på tjänsten som ska användas för att upptäcka noder.

Ett annat alternativ är att tillämpa metoden KUBE_PING, som arbetar med API:er för att hitta noder (du måste konfigurera serviceAccount med behörigheter list och hämta, och sedan ställa in poddar för att arbeta med denna serviceAccount).

Metoden för att upptäcka noder för JGroups konfigureras genom att ställa in miljövariablerna JGROUPS_DISCOVERY_PROTOCOL och JGROUPS_DISCOVERY_PROPERTIES. För KUBE_PING måste du välja poddar genom att ange namnrymd och labels.

️ Om du använder multicast och kör två eller fler Keycloak-kluster i ett och samma Kubernetes-kluster (låt oss säga ett i namespace production, den andra — staging) — noderna i ett Keycloak-kluster kan gå med i ett annat kluster. Se till att använda en unik multicast-adress för varje kluster genom att ställa in variablerjboss.default.multicast.address och jboss.modcluster.multicast.address på JAVA_OPTS.

Replikering mellan datacenter

Anslutning

Keycloak använder flera separata Infinispan-cachekluster för varje datacenter där Keycloak-kluster som består av Keycloak-noder är belägna. Men det finns ingen skillnad mellan Keycloak-noder i olika datacenter.

Keycloak-noder använder en extern Java Data Grid (Infinispan-servrar) för kommunikation mellan datacentren. Kommunikationen fungerar via protokollet Infinispan HotRod.

Infinispan-cachemåste konfigureras med attributet remoteStore, så att data kan lagras i externa (i ett annat datacenter, översättarens anm.) cacher. Det finns separata infinispan-kluster bland JDG-servrar så att data som sparas på JDG1 på platsen site1 kommer att replikeras på JDG2 på platsen site2.

Och slutligen meddelar den mottagande JDG-servern Keycloak-servrarna i sitt kluster via klientanslutningar, vilket är en funktion hos HotRod-protokollet. Keycloak-noderna på site2 uppdaterar sina Infinispan-cacher, och en specifik användarsession blir också tillgänglig på Keycloak-noderna på site2.

För vissa cacher är det också möjligt att inte göra säkerhetskopior och helt överge dataskrivning via Infinispan-servern. För detta måste inställningen remote-store tas bort från den specifika Infinispan-cachen (i filen standalone-ha.xml), varefter en specifik replicated-cache inte längre kommer att vara nödvändig på Infinispan-serverns sida.

Cachekonfigurationer

Det finns två typer av cachar i Keycloak:

Lokal. Den är belägen nära databasen och minskar belastningen på databasen samt sänker svarstiden. I denna typ av cache lagras realm, klienter, roller och användarmetadata. Denna typ av cache replikeras inte, även om denna cache är en del av Keycloak-klustret. Om en post ändras i cache meddelas övriga servrar i klustret om ändringen, varefter posten tas bort från cachen. Se beskrivningen work nedan för en mer detaljerad beskrivning av proceduren.
Replikabel. Den hanterar användarsessioner, offline-token och övervakar inloggningsfel för att identifiera försök till phishing av lösenord och andra attacker. De lagrade datan i dessa cacher är temporära, lagras bara i arbetsminnet, men kan replikeras över klustret.

Infinispan-cacher

Sessioner — ett koncept i Keycloak, separata cacher som kallas authenticationSessions, tillämpas för lagring av specifika användardata. Förfrågningar från dessa cachar behövs vanligtvis av webbläsaren och Keycloak-servrarna, inte av applikationerna. Här blir beroendet av sticky sessions tydligt, och sådana cachar behöver inte replikeras, inte ens i fall av Active-Active-läge.

Åtgärdstokens. En ytterligare koncept som vanligtvis används för olika scenarier där, till exempel, en användare måste göra något asynkront via e-post. Till exempel, under processen glöm bort lösenord cache actionTokens används för att spåra metadata relaterad till tokens – till exempel en token som redan har använts och inte kan aktiveras igen. Denna typ av cache bör vanligtvis replikeras mellan datacenter.

Caching och föråldring av lagrad data fungerar för att avlasta databasen. Sådan caching förbättrar prestanda men ger en uppenbar utmaning. Om en Keycloak-server uppdaterar data måste andra servrar meddelas om detta så att de kan uppdatera sina cachar. Keycloak använder lokala cachar realms, users och auktorisation för caching av data från databasen.

Det finns också en separat cache work, som replikerar över alla datacenter. Den lagrar inga data från databasen, utan tjänar till att skicka meddelanden om föråldrade data till klusternoder mellan datacentren. Med andra ord, så snart data uppdateras skickar Keycloak-noden ett meddelande till de andra noderna i sitt datacenter och även till noder i andra datacenter. Efter att ha mottagit ett sådant meddelande rensar varje nod de relevanta data i sina lokala cachar.

Användarsessioner. Cachar med namnen sessions, clientSessions, offlineSessions och offlineClientSessions, replikerats vanligtvis mellan datacenter och används för att lagra data om användarsessioner som är aktiva under användarens aktivitet i webbläsaren. Dessa cachar arbetar med applikationen som hanterar HTTP-förfrågningar från slutbrukare, så de är kopplade till sticky sessions och bör replikeras mellan datacenter.

Skydd mot brute force-angrepp. Cache loginFailures tjänar för att spåra inloggningsfel, till exempel hur många gånger en användare har skrivit in fel lösenord. Replikering av denna cache är Administrationens ansvar. Men för att få en exakt räknare bör replikering aktiveras mellan datacenter. Å andra sidan, om dessa data inte replikeras, kan prestandan förbättras, och om frågan uppstår behöver replikeringen inte aktiveras.

Vid distribution av Infinispan-klustret måste cache-definitioner läggas till i konfigurationsfilen:

Det är nödvändigt att konfigurera och starta Infinispan-klustret innan Keycloak-klustret startas

Därefter måste remoteStore konfigureras för Keycloak-cacher. För detta räcker det med ett skript, som görs på samma sätt som det föregående, som används för att konfigurera variabeln CACHE_OWNERS, det ska sparas i en fil och placeras i katalogen /opt/jboss/startup-scripts:

Innehållet i skriptet

embed-server --server-config=standalone-ha.xml --std-out=echo
batch

echo *** Uppdatera infinispan subsystem ***
/subsystem=infinispan/cache-container=keycloak:write-attribute(name=module, value=org.keycloak.keycloak-model-infinispan)

echo ** Lägg till fjärrsockelbindning till infinispan-server **
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-cache:add(host=${remote.cache.host:localhost}, port=${remote.cache.port:11222})

echo ** Uppdatera elementet för replikerad-cache arbete **
/subsystem=infinispan/cache-container=keycloak/replikerad-cache=arbete/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=arbete, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)

/subsystem=infinispan/cache-container=keycloak/replikerad-cache=arbete:write-attribute(name=statistics-enabled,value=true)

echo ** Uppdatera distribuerad-cache sessionselement **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessioner/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=sessioner, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessioner:write-attribute(name=statistics-enabled,value=true)

echo ** Uppdatera distribuerad-cache offlineSessions-element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=offlineSessions, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:write-attribute(name=statistics-enabled,value=true)

echo ** Uppdatera distribuerad-cache clientSessions-element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=clientSessions, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:write-attribute(name=statistics-enabled,value=true)

echo ** Uppdatera distribuerad-cache offlineClientSessions-element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=offlineClientSessions, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:write-attribute(name=statistics-enabled,value=true)

echo ** Uppdatera distribuerad-cache loginFailures-element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=loginFailures, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:write-attribute(name=statistics-enabled,value=true)

echo ** Uppdatera distribuerad-cache actionTokens-element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    cache=actionTokens, 
    remote-servers=["remote-cache"], 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens:write-attribute(name=statistics-enabled,value=true)

echo ** Uppdatera distribuerad-cache authenticationSessions-element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:write-attribute(name=statistics-enabled,value=true)

echo *** Uppdatera undertow subsystem ***
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=proxy-address-forwarding,value=true)

run-batch
stop-embedded-server

Kom ihåg att ställa in JAVA_OPTS för Keycloak-noder för att använda HotRod: remote.cache.host, remote.cache.port och tjänstnamn jboss.site.name.

Länkar och ytterligare dokumentation

Artikeln har översatts och förberetts för Habr av medarbetare från Slörms utbildningscenter — intensivkurser, videokurser och företagsutbildning från praktiker (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

Källa: habr.com