Een reverse proxy opnieuw starten zonder sessiestatusservices opnieuw te starten

Gepland proxyonderhoud is veiliger wanneer de reverse proxy onafhankelijk kan worden herladen of herstart van de authenticatie- en sessiestatusservices erachter.

Een proxyproces hoeft doorgaans niet zelf de aanmeldstatus te beheren die het doorstuurt. Breng vóór het onderhoud in kaart welk onderdeel cookies ondertekent, sessies aan serverzijde opslaat, authenticatie beëindigt en actieve HTTP-verbindingen afhandelt. Laat deze statusafhankelijke onderdelen actief, geef bij uitsluitend configuratiewijzigingen de voorkeur aan een beheerst herladen van de proxy en controleer of een volledige vervanging van de proxy opnieuw verbinding maakt met dezelfde authenticatiegateway en sessieopslag, met ongewijzigde geheimen.

Scheid de levenscyclus van de proxy van die van de authenticatieservice

Controleer je Compose-afhankelijkheden, herstartbeleid, gedeelde scripts en acties van de stackmanager om zeker te weten dat het herstarten van de proxy niet automatisch de authenticatiegateway, applicatie, Redis of database opnieuw aanmaakt.

Een voorbeeld van een sessiearchitectuur gebruikt Redis buiten de levenscyclus van de proxy, zodat meerdere authenticatie-instanties en herstarts dezelfde sessiebackend kunnen delen.

Groepeer niet elke edge-service onder één algemene herstartopdracht. Als een certificaat- of routewijziging alleen gevolgen heeft voor de proxy, laat de services die bestaande aanmeldstatus valideren ongemoeid.

Herlaad de configuratie in plaats van te herstarten wanneer dat mogelijk is

Gebruik voor wijzigingen aan routes, certificaten of headers het ondersteunde pad voor beheerst herladen van de proxy in plaats van de service te stoppen. Valideer de configuratie voordat je deze toepast, zodat een syntaxisfout gepland onderhoud niet in downtime verandert.

De NGINX-handleiding van API7 legt uit hoe oude workers verbindingen afhandelen terwijl nieuwe workers verzoeken accepteren met de bijgewerkte configuratie.

Een herlading behoudt de procesfamilie van de proxy, maar beschermt een afzonderlijke authenticatieservice niet als je implementatiescript die service ook herstart. Houd deze twee levenscyclusvragen onafhankelijk.

Behoud externe sessieopslag tijdens vervanging van de proxy

Als een authenticatiegateway sessiegegevens buiten cookies opslaat, houd de Redis- of andere sessiebackend persistent en ongewijzigd tijdens de proxybewerking. Leg het backendadres en het geheim vast dat door elke authenticatie-instantie wordt gebruikt.

OAuth2 Proxy ondersteunt Redis als gedeelde sessieopslag wanneer sessies tussen instanties moeten worden gedeeld.

Verwar een wegwerpbare cache niet met de gezaghebbende aanmeldstatus. Als de sessiebackend vereist is om huidige gebruikers te valideren, herstart of leeg deze dan alleen volgens de eigen geteste onderhoudsprocedure.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Houd cookie- en ondertekeningsgeheimen stabiel

Leg het cookieversleutelings- of ondertekeningsgeheim vast dat door de authenticatiegateway wordt gebruikt en zorg ervoor dat de vervangende proxystack dezelfde bron van geheimen koppelt. Als je tijdens een nieuwe implementatie een nieuwe waarde genereert, worden verder geldige browsercookies ongeldig.

Een handleiding over reverse-proxysessies merkt op dat stabiel sessiebeleid herstarts overleeft en niet afhankelijk is van de levensduur van één TCP-verbinding.

Roteer ondertekeningsgeheimen als een afzonderlijke beveiligingswijziging, met een expliciete verwachting van uitloggen of een strategie voor tijdelijke overlap. Combineer het roteren van geheimen niet met een gewone geplande herlading van de proxy, tenzij het ongeldig maken van sessies de bedoeling is.

Beëindig verbindingen gecontroleerd tijdens een volledige herstart van de proxy

Wanneer het proxybinaire bestand of de container moet worden vervangen, gebruik dan waar beschikbaar het mechanisme voor een beheerste of onderbrekingsvrije herstart, zodat bestaande verzoeken niet midden in een antwoord worden afgebroken. Stel een onderhoudstime-out in voor langdurige verbindingen.

De herlaadinstructies van HAProxy laten zien hoe onderbrekingsvrije herladingen verbindingen behouden in plaats van het oude proces onmiddellijk te beëindigen.

Continuïteit van verbindingen en continuïteit van aanmeldingen zijn verschillend. Zelfs als een WebSocket opnieuw verbinding maakt, moet de sessie geldig blijven omdat de vervangende proxy dezelfde authenticatie- en statusservices bereikt.

Test één sessie vóór en na gepland onderhoud

Gebruik één ingelogde browser en één nieuwe privésessie. Noteer vóór het onderhoud de sessiecookie, proxyrouting, authenticatieservice en backend, herlaad of vervang daarna alleen de proxy en herhaal hetzelfde beveiligde verzoek.

Een Caddy-handleiding voor beheer raadt herladen in plaats van volledig herstarten aan voor geplande configuratie-updates.

Het onderhoudsontwerp werkt wanneer bestaande aanmeldingen behouden blijven, nieuwe aanmeldingen nog steeds slagen en geen statusafhankelijke afhankelijkheid onbedoeld opnieuw is gestart. Het gerelateerde ZimaSpace-artikel over sessieverlies na een herstart van de proxy blijft de juiste herstelroute als gebruikers nog steeds zijn uitgelogd.

Veelgestelde vragen

Garandeert een beheerst herladen van de proxy dat gebruikers ingelogd blijven?

Nee. Het beschermt proxyverbindingen, maar gebruikers kunnen nog steeds worden uitgelogd als de authenticatieservice, sessieopslag of het cookie-ondertekeningsgeheim tegelijkertijd verandert.

Moet Redis een herstart van de proxy altijd overleven?

Alleen wanneer Redis sessiestatus of een andere persistente afhankelijkheid voor authenticatie opslaat. Een Redis-instantie die uitsluitend als cache dient, heeft een ander herstelpunt.

Is het behouden van dezelfde cookienaam voldoende?

Nee. Het ondertekenings- of versleutelingsgeheim en de backend-sessiestatus moeten ook compatibel blijven met de cookie die de browser al bevat.