Como reiniciar um proxy inverso sem reiniciar os serviços de estado das sessões

A manutenção planeada do proxy é mais segura quando o proxy inverso pode ser recarregado ou reiniciado de forma independente dos serviços de autenticação e de estado das sessões que se encontram atrás dele.

Normalmente, um processo de proxy não precisa de ser responsável pelo estado de início de sessão que encaminha. Antes da manutenção, identifique qual o componente que assina os cookies, armazena as sessões no servidor, termina a autenticação e drena as ligações HTTP ativas. Mantenha esses componentes com estado em execução, prefira recarregamentos graciosos do proxy quando apenas houver alterações de configuração e confirme que uma substituição completa do proxy volta a ligar-se ao mesmo gateway de autenticação e armazenamento de sessões, com os mesmos segredos.

Separe o ciclo de vida do proxy do ciclo de vida do serviço de autenticação

Verifique as dependências do Compose, as políticas de reinício, os scripts partilhados e as ações do gestor da stack, para garantir que reiniciar o proxy não recria automaticamente o gateway de autenticação, a aplicação, o Redis ou a base de dados.

Um exemplo de arquitetura de sessões utiliza o Redis fora do ciclo de vida do proxy, permitindo que várias instâncias de autenticação e vários reinícios partilhem o mesmo backend de sessões.

Não agrupe todos os serviços de edge num único comando de reinício indiscriminado. Se uma alteração de certificado ou de rota afetar apenas o proxy, deixe inalterados os serviços que validam o estado atual das sessões iniciadas.

Recarregue a configuração em vez de reiniciar, quando possível

Para alterações de rotas, certificados ou cabeçalhos, utilize o processo de recarregamento gracioso suportado pelo proxy, em vez de parar o serviço. Valide a configuração antes de a aplicar, para que um erro de sintaxe não transforme uma manutenção planeada em indisponibilidade.

O guia da API7 sobre NGINX explica como os workers antigos drenam as ligações enquanto os novos aceitam pedidos com a configuração atualizada.

Um recarregamento mantém a mesma família de processos do proxy, mas não protege um serviço de autenticação separado se o seu script de implementação também reiniciar esse serviço. Mantenha estas duas questões do ciclo de vida independentes.

Preserve o armazenamento externo das sessões durante a substituição do proxy

Se um gateway de autenticação armazenar os dados da sessão fora dos cookies, mantenha o Redis ou outro backend de sessões persistente e inalterado durante a operação do proxy. Registe o endereço do backend e o segredo utilizado por cada instância de autenticação.

O OAuth2 Proxy suporta o Redis como armazenamento partilhado de sessões quando as sessões têm de ser partilhadas entre instâncias.

Não confunda uma cache descartável com o estado autorizado das sessões. Se o backend de sessões for necessário para validar os utilizadores atuais, reinicie-o ou limpe-o apenas de acordo com o seu próprio procedimento de manutenção testado.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Mantenha estáveis os segredos dos cookies e da assinatura

Registe o segredo de encriptação ou assinatura dos cookies utilizado pelo gateway de autenticação e garanta que a stack de substituição do proxy monta a mesma origem do segredo. Gerar um novo valor durante a reimplementação invalidará cookies do navegador que, de outro modo, continuariam válidos.

Um guia sobre sessões em proxies inversos salienta que a política de sessões estável sobrevive aos reinícios, e não da duração de uma única ligação TCP.

Faça a rotação dos segredos de assinatura como uma alteração de segurança separada, com uma expectativa explícita de encerramento de sessão ou uma estratégia de sobreposição. Não combine a rotação de segredos com um recarregamento normal do proxy, a menos que a invalidação das sessões seja intencional.

Drene as ligações durante um reinício completo do proxy

Quando for necessário substituir o binário ou o contentor do proxy, utilize, quando disponível, o mecanismo de reinício gracioso ou sem interrupção, para que os pedidos estabelecidos não sejam interrompidos a meio da resposta. Defina um tempo limite de manutenção para ligações de longa duração.

As orientações de recarregamento do HAProxy mostram como os recarregamentos sem interrupção preservam as ligações, em vez de terminarem imediatamente o processo antigo.

A continuidade das ligações e a continuidade da sessão de início de sessão são coisas diferentes. Mesmo que um WebSocket volte a ligar-se, a sessão deverá continuar válida, porque o proxy de substituição acede aos mesmos serviços de autenticação e de estado.

Teste uma sessão antes e depois da manutenção planeada

Utilize um navegador com sessão iniciada e uma sessão privada nova. Registe o cookie da sessão, a rota do proxy, o serviço de autenticação e o backend antes da manutenção; depois, recarregue ou substitua apenas o proxy e repita o mesmo pedido protegido.

Um guia de operações do Caddy recomenda o recarregamento em vez do reinício completo para atualizações de configuração planeadas.

O desenho da manutenção está a funcionar quando as sessões iniciadas existentes sobrevivem, as novas sessões continuam a ser iniciadas com sucesso e nenhuma dependência com estado recebeu um reinício não intencional. O artigo relacionado da ZimaSpace sobre perda de sessões após um reinício do proxy continua a ser o procedimento de recuperação correto se os utilizadores continuarem com a sessão terminada.

Perguntas frequentes

Um recarregamento gracioso do proxy garante que os utilizadores permanecem com a sessão iniciada?

Não. Protege as ligações do proxy, mas os utilizadores podem continuar a ter a sessão terminada se o serviço de autenticação, o armazenamento de sessões ou o segredo de assinatura dos cookies mudar ao mesmo tempo.

O Redis deve sobreviver sempre a um reinício do proxy?

Apenas quando o Redis armazena o estado das sessões ou outra dependência persistente da autenticação. Uma instância Redis utilizada apenas como cache tem um limite de recuperação diferente.

Manter o mesmo nome de cookie é suficiente?

Não. O segredo de assinatura ou encriptação e o estado das sessões no backend também têm de permanecer compatíveis com o cookie que o navegador já possui.