Anunciando o NGINX Plus R23

Liam CrillyDiretor Sênior de Gestão de Produtos

Temos o prazer de anunciar a disponibilidade do NGINX Plus Release 23 (R23). Baseado no NGINX Open Source, o NGINX Plus é o único balanceador de carga de software, proxy reverso e gateway de API.

Os novos recursos do NGINX Plus R23 incluem:

• Verificações de integridade do gRPC – Testar ativamente se um serviço gRPC consegue processar solicitações antes de encaminhá-las aumenta significativamente a confiabilidade.
• Suporte à instalação sem privilégios – Agora, o NGINX Plus pode ser instalado e atualizado por um usuário sem privilégios (que não seja o root). Essa solução com suporte completo está alinhada à tendência crescente de adoção de modelos de segurança de confiança zero.
• Suporte a PKCE no OpenID Connect – O NGINX Plus R23 implementa a extensão Proof Key for Code Exchange (PKCE) para o fluxo de Código de Autorização do OpenID Connect. O PKCE impede vários tipos de ataque e permite trocas OAuth seguras com clientes públicos.

Completando esta versão estão um controle mais granular sobre SSL/TLS, um método nativo para definir sinalizadores de cookies e a configuração de variáveis no módulo Stream. As atualizações do ecossistema NGINX Plus incluem os novos módulos Buffer e Query String para o módulo JavaScript do NGINX, o novo módulo dinâmico SPNEGO for Kerberos e melhorias no módulo dinâmico Prometheus‑njs.

Mudanças importantes de comportamento

• Módulo obsoleto – O módulo Cookie-Flag de terceiros foi descontinuado e substituído pela nova diretiva proxy_cookie_flags. O módulo será removido no NGINX Plus R26. Para obter detalhes, consulte Método nativo para definir sinalizadores de cookies.
• Novos sistemas operacionais compatíveis:
  • Alpine 3.12 (x86_64, aarch64)
  • Debian 10 (aarch64; x86_64 é compatível desde o NGINX Plus R17)
• Sistemas operacionais mais antigos removidos ou que serão removidos:
  • O Alpine 3.9 não é mais compatível; a versão mais antiga com suporte é a 3.10
  • CentOS/Oracle Linux/RHEL 6.5+ não é mais compatível; a versão mais antiga com suporte é a 7.4
  • O Ubuntu 19.10 não é mais compatível
  • O Debian 9 será removido no NGINX Plus R24

Novos recursos em detalhes

Verificações de integridade do gRPC

Quando implantado como balanceador de carga, o NGINX Plus pode monitorar a integridade dos servidores de backend (upstream) realizando verificações ativas de integridade. O NGINX Plus R23 oferece suporte ao protocolo de verificação de integridade do gRPC, permitindo verificar com precisão se os servidores gRPC de backend conseguem processar novas solicitações. Isso é particularmente útil em ambientes dinâmicos e conteinerizados. Ao iniciar novas instâncias de um serviço gRPC, é importante enviar solicitações somente quando o serviço estiver “totalmente operacional”. Isso exige uma verificação de integridade que vá além de examinar a porta TCP ou verificar a disponibilidade do URI HTTP – uma verificação em que o próprio serviço indique se está pronto para receber solicitações.

Para serviços gRPC que implementam o protocolo de verificação de integridade do gRPC, a configuração é simples.

Carregando exemplo de código…

Essa configuração distribui a carga de todas as solicitações para o grupo upstream grpc_backend. A diretiva health_check inclui o parâmetro type=grpc para invocar o método Check do serviço Health de cada servidor upstream. Os serviços que respondem com SERVING são considerados íntegros. O parâmetro mandatory garante que, quando o NGINX Plus é iniciado ou um novo servidor é adicionado ao grupo upstream, o tráfego não seja encaminhado até que uma verificação de integridade seja bem-sucedida (caso contrário, por padrão, os novos serviços são considerados íntegros).

Se houver vários serviços gRPC expostos em cada servidor upstream, o serviço mais importante (aquele que possui serviços dependentes ou subordinados) poderá ser monitorado especificando seu nome como o valor do parâmetro grpc_service, como neste exemplo:

Carregando exemplo de código…

Para serviços gRPC que não implementam o protocolo de verificação de integridade do gRPC, podemos testar se o servidor upstream está pelo menos respondendo às solicitações gRPC, pois, nesse caso, ele envia um código de status de erro em resposta ao método Check. Com a configuração em grpc_health.conf, esperamos que um serviço que não implemente o protocolo gRPC responda com o código de status 12 (UNIMPLEMENTED).

Também podemos verificar se um serviço gRPC consegue responder às solicitações recebidas sem precisar modificar o código do backend. Podemos usar essa abordagem para monitorar qualquer serviço gRPC:

Carregando exemplo de código…

Instalação para usuário sem privilégios

Em versões anteriores, o NGINX Plus operava com um número mínimo de processos executados como o usuário privilegiado root. Por exemplo, as instruções de instalação no Guia de Administração do NGINX Plus criam estes processos:

$ ps auxf | grep nginxroot  ...  9068  888 ?  Ss 21:44  0:00 nginx: master process nginx
nginx ...  9712 3572 ?  S  21:44  0:00  \_ nginx: worker process

Como mostrado, o processo mestre está sendo executado com privilégios de root. Todos os outros processos (workers e gerenciamento de cache) usam a conta de usuário sem privilégios nginx.

Sistemas críticos que lidam com dados confidenciais podem optar por não usar o usuário root. Nesse caso, o NGINX Plus R23 pode ser instalado e executado por um usuário sem privilégios. Disponibilizamos um script de instalação, ngxunprivinst.sh, em nosso repositório do GitHub para uso nos seguintes sistemas operacionais:

• Alpine Linux
• Amazon Linux, Amazon Linux 2
• CentOS, Red Hat Enterprise Linux
• Debian, Ubuntu

Observação: Se algum listener do NGINX Plus estiver configurado em uma porta abaixo de 1024 (por exemplo, 80 ou 443), o processo mestre deverá ter privilégios de root (mas ainda será possível instalar o NGINX Plus usando uma conta de usuário sem privilégios).

Para usar o script de instalação, execute os comandos a seguir. (Para ver todos os comandos disponíveis do ngxunprivinst.sh, execute o script sem especificar um nome de comando ou consulte o código do script no repositório do GitHub.)

1. Baixe o script e verifique se ele é executável:

$ chmod +x ngxunprivinst.sh

1. Copie o certificado e a chave do NGINX Plus (nginx-repo.crt e nginx-repo.key) para o diretório local. As opções ‑c e ‑k são incluídas em todos os comandos ngxunprivinst.sh para identificá-los.
2. Liste as versões do NGINX Plus disponíveis no repositório do NGINX Plus.

$ ./ngxunprivinst.sh list -c nginx-repo.crt -k nginx-repo.key
18-1
18-2
19-1
20-1
21-1
22-1
23-1

1. Baixe o pacote desejado (aqui, estamos baixando o NGINX Plus R23-1). A opção ‑p especifica o diretório de instalação:

$ ./ngxunprivinst.sh fetch -c nginx-repo.crt -k nginx-repo.key -p /home/nginxrun -v 23-1

1. Instale os pacotes necessários (aqui, estamos instalando o NGINX Plus e o módulo JavaScript do NGINX, o njs).

$ ./ngxunprivinst.sh install -c nginx-repo.crt -k nginx-repo.key -p /home/nginxrun -v 23.1 nginx-plus-23-1.el8.ngx.x86_64.rpm nginx-plus-module-njs-23%2B0.4.6-1.el8.ngx.x86_64.rpm

1. Inicie o NGINX, incluindo a opção ‑p para especificar o caminho, ‑c para indicar o nome do arquivo de configuração e ‑e para indicar o nome do log de erros.

$ /home/nginxrun/usr/sbin/nginx -p /home/nginxrun/etc/nginx -c nginx.conf -e /home/nginxrun/var/log/error.log

1. Incluímos a opção ‑e para suprimir a mensagem de aviso que seria exibida. Antes de o NGINX Plus ler sua configuração durante a inicialização, ele grava no log de erros padrão, /var/log/nginx/error.log. Usuários sem privilégios não têm permissão para criar ou gravar nesse arquivo, o que resulta em um aviso. Depois que a configuração é lida, a diretiva error_log define o log de erros em um local no qual o usuário sem privilégios pode gravar.
2. (Opcional) Para verificar se o NGINX Plus está sendo executado como um usuário diferente de root, execute este comando:

$ ps auxf | grep nginx
nginxrun ...  9068  888 ?  Ss 21:55 0:00 nginx: master process
nginxrun ...  9712 3572 ?  S  21:55 0:00  \_ nginx: worker process

Suporte a PKCE no OpenID Connect

A Chave de Prova para Troca de Código (PKCE) é uma extensão adicionada recentemente ao fluxo de Código de Autorização do OpenID Connect (OIDC) para evitar vários tipos de ataque e proteger a troca OAuth com clientes públicos. Para o NGINX Plus R23, atualizamos nossa implementação de referência do OpenID Connect para oferecer suporte à extensão. A PKCE se tornará obrigatória com o OAuth 2.1.

A alteração específica consiste em substituir client_secret por dois novos valores no desafio de código:

• code_challenge
• code_verifier

Para mitigar diferentes ataques, especialmente em dispositivos móveis, o desafio para um token (seja ele um Token de Acesso, de ID ou de Atualização) foi ajustado da seguinte forma:

1. NGINX Plus gera (e memoriza) um code_verifier.
2. NGINX Plus redireciona o usuário final para fazer login na página de login do provedor de identidade (IdP) OIDC. A solicitação inclui uma versão com hash do code_verifier chamada de code_challenge.
3. O IdP envia um auth_code do usuário para o NGINX Plus.
4. Com base no estado compartilhado, o NGINX Plus consegue localizar o code_verifier gerado e enviar a solicitação para trocar o código de autorização por um conjunto de tokens no endpoint de token do IdP.

Antes da adição do PKCE, bastava que o NGINX Plus compartilhasse um segredo de cliente estático com o IdP.
Na versão atualizada da implementação de referência do OIDC, o NGINX Plus é capaz de processar fluxos de Código de Autorização tanto com PKCE quanto com a metodologia de segredo de cliente.

Veja um exemplo de configuração que habilita o fluxo estendido de Código de Autorização com PKCE:

Carregando exemplo de código…

A nova variável $oidc_pkce_enable funciona como um seletor para o fluxo PKCE. Se definida como 1 para um domínio específico, o fluxo PKCE será usado. Se definida como 0 (o padrão), será usado o fluxo de Código de Autorização sem PKCE.

Outras melhorias no NGINX Plus R23

Controle granular sobre conexões SSL/TLS

O TLS v1.3 oferece uma segurança mais robusta do que as versões anteriores do TLS, com criptografia de ponta a ponta entre servidores e entre servidores e seus clientes. O NGINX Plus R23 fornece acesso direto à configuração do OpenSSL para um controle granular sobre o TLS v1.3.

Como criar um servidor HTTPS padrão sem certificado e chave

Em versões anteriores, o bloco server padrão para tráfego HTTPS protegido por TLS precisava incluir as diretivas ssl_certificate e ssl_certificate_key, exigindo a criação de um certificado autoassinado e de uma chave “fictícios”.

A diretiva ssl_reject_handshake elimina a necessidade de um certificado e uma chave, como nesta configuração de exemplo:

Carregando exemplo de código…

Configuração direta do OpenSSL

O NGINX Plus R23 oferece um controle mais granular sobre como o NGINX Plus lida com SSL/TLS usando o OpenSSL 1.0.2 e versões posteriores.

Os seguintes casos de uso aproveitam o novo nível de controle:

• Cifras ChaCha – O NGINX Plus usa o ChaCha20 quando um cliente (geralmente móvel) especifica essa cifra no topo de sua lista de preferências. O ChaCha20 melhora significativamente o desempenho dos clientes compatíveis.
• Configuração de cifras do TLS v1.3 – Nas versões anteriores, a diretiva ssl_ciphers era usada para definir a lista de cifras SSL/TLS preferenciais do NGINX Plus, como neste exemplo:

  Carregando exemplo de código…

  No entanto, essa diretiva não se aplica ao TLS v1.3, pois a implementação de cifras do OpenSSL para o TLS v1.3 não é compatível com as interfaces mais antigas. Para definir a lista de cifras do TLS v1.3, use a nova diretiva ssl_conf_command, como neste exemplo:

  Carregando exemplo de código…

  Para definir cifras para o TLS v1.2 e o TLS v1.3, inclua ambas as diretivas na configuração:

  Carregando exemplo de código…

• Atualização de conexões por proxy – Com base no mecanismo de configuração de cifras implementado pela diretiva ssl_conf_command, o NGINX Plus R23 oferece o mesmo controle sobre os conjuntos de cifras para conexões encaminhadas por proxy com estes protocolos:
  • HTTP e TCP – proxy_ssl_conf_command
  • gRPC – grpc_ssl_conf_command
  • uwsgi – uwsgi_ssl_conf_command

O exemplo a seguir mostra como configurar o NGINX Plus para que as solicitações de clientes que usam versões mais antigas do TLS passem a utilizar servidores de backend compatíveis com o TLS v1.3.

Carregando exemplo de código…

O Gerenciador de Cache Pode Monitorar o Espaço Disponível em Disco

Quando o NGINX Plus é configurado como um proxy de cache, o processo gerenciador de cache garante que o tamanho do cache não exceda o limite definido pelo parâmetro max_size da diretiva proxy_cache_path, removendo o conteúdo acessado há mais tempo.

Com o NGINX Plus R23, o gerenciador de cache também pode monitorar a quantidade de espaço em disco disponível no sistema de arquivos que armazena o cache e remover conteúdo quando o espaço disponível for menor que o valor do novo parâmetro min_free da diretiva proxy_cache_path.

Isso significa que, mesmo quando o cache compartilha o mesmo sistema de arquivos com outros processos, o NGINX Plus garante que o preenchimento do cache não ocupe inadvertidamente todo o espaço em disco.

Carregando exemplo de código…

Método nativo para definir atributos de cookies

Cookies não protegidos continuam sendo um vetor de ataque de alto risco. Conforme observado na Mozilla Developer Network (MDN), uma forma de garantir que os cookies não sejam acessados por terceiros ou scripts não autorizados é definir sinalizadores como HttpOnly e Secure no cabeçalho Set-Cookie.

Em versões anteriores, fornecíamos a diretiva set_cookie_flag para essa finalidade, conforme implementada no módulo Cookie‑Flag de terceiros, disponível em nosso repositório de módulos dinâmicos. O NGINX Plus R23 apresenta a diretiva proxy_cookie_flags para substituir essa diretiva e esse módulo.

O módulo Cookie‑Flag obsoleto será removido no NGINX Plus R26. Portanto, recomendamos que você localize todas as diretivas set_cookie_flag na sua configuração e as substitua pela diretiva proxy_cookie_flags o mais rápido possível.

Veja um exemplo de configuração de proxy para uma aplicação de backend simples que não define por conta própria nenhum sinalizador de proteção de cookies:

Carregando exemplo de código…

Neste exemplo, adicionamos os sinalizadores HttpOnly, Secure e SameSite para proteger o cookie de sessão appcookie criado pelo servidor upstream, que o NGINX Plus usa para persistência de sessão, conforme descrito no Guia de Administração do NGINX Plus.

Usando o comando curl ou as ferramentas de desenvolvedor do seu navegador, você pode ver que os sinalizadores HttpOnly, Secure e SameSite agora estão definidos para appcookie.

< HTTP/1.1 200 OK< Server: nginx/1.19.4
< Date: Thu, 08 Dec 2020 14:46:12 GMT
< Content-Type: application/octet-stream
< Content-Length: 9
< Connection: keep-alive
< Set-Cookie: appcookie=appserver1; Secure; HttpOnly; SameSite=Strict
< Content-Type: text/html

Com o NGINX Plus R23, você também pode adicionar o sinalizador SameSite aos cookies usando a diretiva sticky, como neste exemplo (os parâmetros httponly e secure são compatíveis desde o NGINX Plus R6):

Carregando exemplo de código…

Definindo variáveis no módulo Stream

O NGINX Plus R23 apresenta a diretiva set para definir variáveis em configurações TCP/UDP, ampliando a funcionalidade comumente usada para processamento de tráfego HTTP.

Veja um exemplo que cria valores compostos e complexos a partir de várias variáveis.

Carregando exemplo de código…

Um caso de uso mais sofisticado utiliza a diretiva set para atualizar o armazenamento de chave-valor. Nessa configuração de balanceamento de carga de DNS, o armazenamento de chave-valor registra o horário em que cada endereço IP de cliente faz uma solicitação de DNS e mantém cada registro por 24 horas.

Carregando exemplo de código…

Em seguida, você pode usar a API do NGINX Plus para saber quando cada cliente fez sua solicitação de DNS mais recente nas últimas 24 horas.

$ curl http://localhost:8080/api/6/stream/keyvals/dns_timestamp{
  "172.17.0.1": "2020-12-08T15:51:28+00:00",
  "172.17.0.2": "2020-12-08T12:36:08+00:00",
  "172.17.0.7": "2020-12-08T15:15:42+00:00"
}

Atualizações no ecossistema do NGINX Plus

Aprimoramentos no módulo JavaScript do NGINX

O módulo JavaScript do NGINX (njs) foi atualizado para a versão 0.5.0. Esta versão apresenta o módulo Buffer, que é semelhante ao módulo Buffer do Node.js. Os objetos Buffer facilitam o trabalho com dados binários, em vez de depender de strings.

Outras melhorias importantes no módulo incluem o módulo Query String para facilitar o acesso aos pares de chave-valor transmitidos na URL e o suporte a rastreamento de pilha no nível de linha para depuração.

Alterações nos módulos dinâmicos

Novo SPNEGO para o módulo Kerberos

O suporte à autenticação Kerberos por SPNEGO agora está disponível no repositório de módulos dinâmicos do NGINX Plus. Para obter instruções de instalação e mais informações, consulte o Guia de Administração do NGINX Plus.

Módulo Cookie-Flags obsoleto

Conforme detalhado em Método nativo para definir sinalizadores de cookies acima, a nova diretiva proxy_cookie_flags substitui a diretiva set_cookie_flag implementada no módulo Cookie-Flag de terceiros, que agora está obsoleto e tem sua remoção programada para o NGINX Plus R26. Se a sua configuração incluir a diretiva set_cookie_flag, substitua-a por proxy_cookie_flags assim que possível.

Atualizações do módulo Prometheus-njs

O módulo Prometheus‑njs agora disponibiliza métricas adicionais. Ele também foi atualizado para oferecer suporte a implantações que usam o módulo JavaScript do NGINX (njs). Ao atualizar o Prometheus‑njs para a versão 1.3.1 ou posterior, é importante atualizar o arquivo de configuração do NGINX para evitar referências a configurações obsoletas do njs:

• A diretiva js_include foi descontinuada e substituída pela diretiva js_import directive
• As diretivas js_content e js_set podem fazer referência a uma função de módulo

Correção de bug importante

As verificações de integridade que usavam a diretiva require em um bloco match para verificar se as variáveis não estavam vazias podem não ter detectado servidores upstream com problemas se a resposta fosse maior que o valor da diretiva proxy_buffer_size.

Atualize ou experimente o NGINX Plus

Se você estiver usando o NGINX Plus, recomendamos enfaticamente que faça a atualização para o NGINX Plus R23 o mais rápido possível. Você também terá acesso a várias correções e melhorias adicionais, além de facilitar o atendimento da NGINX quando precisar abrir um chamado de suporte.

Se você ainda não experimentou o NGINX Plus, recomendamos que o teste – para segurança, balanceamento de carga e gateway de API, ou como um servidor web com suporte completo e APIs avançadas de monitoramento e gerenciamento. Você pode começar hoje mesmo com uma avaliação gratuita de 30 dias. Veja por si mesmo como o NGINX Plus pode ajudar você a disponibilizar e escalar suas aplicações.

Sobre o autor

Liam CrillyDiretor Sênior de Gestão de Produtos

Mais publicações de Liam Crilly