Anunciando o NGINX Plus R23

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 pode lidar com solicitações antes de enviá-las aumenta significativamente a confiabilidade.
• Suporte de instalação sem privilégios – O NGINX Plus agora pode ser instalado e atualizado por um usuário sem privilégios (não root ). Esta solução totalmente suportada está alinhada à tendência crescente em direção a modelos de segurança de confiança zero.
• Suporte ao OpenID Connect PKCE – O NGINX Plus R23 implementa a extensão Proof Key for Code Exchange (PKCE) para o fluxo do OpenID Connect Authorization Code. O PKCE previne vários tipos de ataques e permite trocas seguras de OAuth com clientes públicos.

Completando esta versão, há um controle mais refinado sobre SSL/TLS, um método nativo para definir sinalizadores de cookies e 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 NGINX JavaScript, o novo módulo dinâmico SPNEGO para Kerberos e aprimoramentos no módulo dinâmico Prometheus‑njs.

Mudanças importantes no comportamento

• Módulo obsoleto – O módulo Cookie-Flag de terceiros foi obsoleto 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 suportados :
  • Alpino 3.12 (x86_64, aarch64)
  • Debian 10 (aarch64; x86_64 tem suporte desde NGINX Plus R17 )
• Sistemas operacionais mais antigos removidos ou a serem removidos:
  • Alpine 3.9 não é mais suportado; a versão mais antiga suportada é 3.10
  • CentOS/Oracle Linux/RHEL 6.5+ não é mais suportado; a versão mais antiga suportada é 7.4
  • O Ubuntu 19.10 não é mais suportado
  • O Debian 9 será removido no NGINX Plus R24

Novos recursos em detalhes

Verificações de integridade do gRPC

Quando implantado como um balanceador de carga, o NGINX Plus pode monitorar a integridade dos servidores backend (upstream) realizando verificações de integridade ativas . O NGINX Plus R23 oferece suporte ao protocolo de verificação de integridade gRPC , permitindo testar com precisão se os servidores gRPC de backend são capazes de lidar com novas solicitações. Isso é particularmente valioso em ambientes dinâmicos e em contêineres. Ao criar novas instâncias de um serviço gRPC, é importante enviar solicitações somente quando o serviço estiver “totalmente ativo”. Isso requer uma verificação de integridade que vai além de olhar a porta TCP ou verificar a disponibilidade do URI HTTP – uma em que o próprio serviço indica se está pronto para receber solicitações.

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

Esta configuração balanceia 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. Serviços que respondem com SERVINDO são considerados saudáveis. O parâmetro obrigatório garante que, quando o NGINX Plus for inicializado ou um novo servidor for introduzido no grupo upstream, o tráfego não será encaminhado até que uma verificação de integridade seja aprovada (caso contrário, os novos serviços serão considerados íntegros por padrão).

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

Para serviços gRPC que não implementam o protocolo de verificação de integridade gRPC, podemos testar se o servidor upstream está pelo menos respondendo às solicitações gRPC, porque 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 código de status 12(NÃO IMPLEMENTADO) .

Também podemos verificar se um serviço gRPC é capaz de responder a solicitações recebidas sem precisar modificar o código de backend. Podemos usar esta abordagem para monitorar qualquer serviço gRPC:

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

Em versões anteriores, o NGINX Plus operava com um mínimo de processos em execução como 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 nginx root ...  9068 888 ?  Ss 21:44 0:00 nginx: processo mestre nginx nginx ...  9712 3572 ?  S 21:44 0:00 \_ nginx: processo de trabalho

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

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

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

Observação:  Se algum ouvinte do NGINX Plus estiver configurado em portas abaixo de 1024 (por exemplo, 80 ou 443), o processo mestre deverá ter privilégios de root (mas você ainda poderá instalar o NGINX Plus com uma conta de usuário sem privilégios).

Para usar o script de instalação, execute os seguintes comandos. (Para ver todos os comandos ngxunprivinst.sh disponíveis, execute o script sem um parâmetro de nome de comando ou veja o código do script no repositório do GitHub.)

1. Baixe o script e certifique-se de que ele é executável:

   $ chmod +x ngxunprivanst.sh

2. Copie seu certificado e chave do NGINX Plus ( nginx-repo.crt e nginx-repo.key ) para o diretório local. As opções ‑c e ‑k estão incluídas em todos os comandos ngxunprivinst.sh para identificá-los.

3. Liste as versões do NGINX Plus disponíveis no repositório NGINX Plus.

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

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

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

5. Instale os pacotes que você precisa (aqui estamos instalando o NGINX Plus e o NGINX JavaScript Module, 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

6. Inicie o NGINX, incluindo a opção ‑p para especificar o caminho, ‑c para nomear o arquivo de configuração e ‑e para nomear o log de erros.

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

   Incluímos a opção ‑e para suprimir a mensagem de aviso que, de outra forma, apareceria. Antes que o NGINX Plus leia 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 neste arquivo, resultando em um aviso. Depois que a configuração é lida, a diretiva error_log define o log de erros para um local onde o usuário sem privilégios pode gravar.

7. (Opcional) Para verificar se o NGINX Plus está sendo executado como um usuário não root , execute este comando:

   $ ps auxf | grep nginx nginxrun ...  9068 888 ?  Ss 21:55 0:00 nginx: processo mestre nginxrun ...  9712 3572 ?  S 21:55 0:00 \_ nginx: processo de trabalho

Suporte OpenID Connect PKCE

A Proof Key for Code Exchange ( 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 de 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. O PKCE se tornará obrigatório com o OAuth 2.1 .

A mudança específica é substituir client_secret por dois novos valores no desafio de código:

• desafio_de_código
• verificador_de_código

Para lidar com diferentes ataques, especialmente em dispositivos móveis, o desafio para um token (seja um token de acesso, ID ou atualização) foi ajustado da seguinte forma:

1. O NGINX Plus gera (e lembra) um code_verifier .
2. O NGINX Plus redireciona o usuário final para efetuar login na página de login do provedor de identidade (IdP) do OIDC. A solicitação inclui uma versão com hash do code_verifier chamada 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 encontrar o code_verifier gerado e enviar a solicitação para trocar o código de autorização por um conjunto de tokens do ponto de extremidade de token do IdP.

Antes de adicionar o PKCE, era suficiente que o NGINX Plus compartilhasse um segredo de cliente estático com o IdP.
Na implementação de referência OIDC atualizada, o NGINX Plus é capaz de manipular fluxos de código de autorização para PKCE e a metodologia de segredo do cliente.

Aqui está uma configuração de exemplo que habilita o fluxo de código de autorização estendido com PKCE:

A nova variável $oidc_pkce_enable atua como um switch para o fluxo PKCE. Se definido como1 para um domínio específico, o fluxo PKCE é usado. Se definido como0 (o padrão), o fluxo de Código de Autorização não PKCE é usado.

Outras melhorias no NGINX Plus R23

Controle refinado sobre conexões SSL/TLS

O TLS v1.3 permite uma segurança mais forte 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 controle refinado sobre o TLS v1.3.

Criando um servidor HTTPS padrão sem um certificado e chave

Em versões anteriores, o bloco de servidor padrão para tráfego HTTPS protegido por TLS tinha que incluir as diretivas ssl_certificate e ssl_certificate_key , exigindo que você criasse um certificado e uma chave autoassinados “fictícios”.

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

Configuração direta do OpenSSL

O NGINX Plus R23 oferece controle mais refinado sobre como o NGINX Plus lida com SSL/TLS com OpenSSL 1.0.2 e posteriores.

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

• Cifras ChaCha – O NGINX Plus usa 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 que o suportam.

• Configuração de cifra TLS v1.3 – Em versões anteriores, a diretiva ssl_ciphers era usada para definir a lista de cifras SSL/TLS preferenciais do NGINX Plus, como neste exemplo:

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

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

• Atualizando conexões proxy – Com base no mecanismo de configuração de cifra implementado pela diretiva ssl_conf_command , o NGINX Plus R23 oferece o mesmo controle sobre conjuntos de cifras para conexões proxy com estes protocolos:

  • HTTP e TCP – proxy_ssl_conf_command
  • gRPC – comando grpc_ssl_conf
  • uwsgi – comando uwsgi_ssl_conf

O exemplo a seguir mostra como configurar o NGINX Plus para atualizar solicitações de clientes que usam versões mais antigas do TLS para usar servidores de back-end conhecidos por oferecer suporte ao TLS v1.3.

O Gerenciador de Cache pode monitorar o espaço em disco disponível

Quando o NGINX Plus é configurado como um proxy de cache, o processo do gerenciador de cache garante que o tamanho do cache não exceda o limite definido pelo parâmetro max_size para a diretiva proxy_cache_path , removendo o conteúdo que foi acessado menos recentemente.

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 hospeda o cache e remover conteúdo quando o espaço disponível for menor que o novo parâmetro min_free para a diretiva proxy_cache_path .

Isso significa que, mesmo quando o cache compartilha o mesmo sistema de arquivos que outros processos, o NGINX Plus garante que o preenchimento do cache não encherá o disco inadvertidamente.

Método nativo para definir sinalizadores de cookies

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

Em versões anteriores, fornecemos a diretiva set_cookie_flag para essa finalidade, conforme implementado no módulo Cookie-Flag de terceiros disponível em nosso repositório de módulos dinâmicos. O NGINX Plus R23 introduz a diretiva proxy_cookie_flags para substituir essa diretiva e 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 em sua configuração e as substitua pela diretiva proxy_cookie_flags o mais rápido possível.

Aqui está uma configuração de exemplo para proxy para um aplicativo de backend simples que não define nenhum sinalizador de proteção de cookie:

Neste exemplo, estamos adicionando 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 a ferramenta 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< Servidor: nginx/1.19.4
< Data: Qui, 08 Dez 2020 14:46:12 GMT
< Tipo de conteúdo: application/octet-stream
< Comprimento do conteúdo: 9
< Conexão: keep-alive
< Definir-Cookie: appcookie=appserver1; Seguro; HttpOnly; SameSite=Strict
< Tipo de conteúdo: text/html

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

Definindo variáveis no módulo Stream

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

Aqui está um exemplo que constrói valores complexos e compostos a partir de múltiplas variáveis.

Um caso de uso mais sofisticado emprega a diretiva set para atualizar o armazenamento de chave-valor . Nessa configuração para balanceamento de carga de DNS, o armazenamento de chave-valor registra o momento em que cada endereço IP do cliente faz uma solicitação de DNS, retendo cada registro por 24 horas.

Você pode então 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 do ecossistema NGINX Plus

Melhorias no módulo JavaScript NGINX

O módulo JavaScript NGINX (njs) foi atualizado para0.5.0 . Esta versão apresenta o módulo Buffer , que é análogo ao módulo Buffer do Node.js. Objetos buffer facilitam o trabalho com dados binários, em vez de depender de strings.

Outras melhorias notáveis no módulo são o módulo Query String para fácil acesso aos pares chave-valor passados na URL e suporte a backtrace em nível de linha para depuração.

Alterações nos módulos dinâmicos

Novo SPNEGO para módulo Kerberos

O suporte para autenticação SPNEGO Kerberos agora está disponível no repositório de módulos dinâmicos NGINX Plus. Para obter instruções de instalação e dicas para 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 programado para remoção no NGINX Plus R26 . Se sua configuração incluir a diretiva set_cookie_flag , substitua-a por proxy_cookie_flags o mais breve possível.

Atualizações no módulo Prometheus-njs

O módulo Prometheus‑njs agora expõe métricas adicionais. Ele também foi atualizado para acomodar implantações que usam o módulo NGINX JavaScript (njs). Ao atualizar o Prometheus‑njs para a versão 1.3.1 e superior, é importante atualizar o arquivo de configuração do NGINX para evitar referências à configuração njs obsoleta:

• A diretiva js_include está obsoleta e foi substituída pela diretiva js_import
• As diretivas js_content e js_set podem referenciar uma função de módulo

Correção de bug notável

Verificações de integridade que usaram a diretiva require em um bloco de correspondência para testar 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 executando o NGINX Plus, recomendamos fortemente que atualize para o NGINX Plus R23 o mais rápido possível. Você também receberá diversas correções e melhorias adicionais, e isso ajudará o NGINX a ajudar você quando precisar abrir um tíquete de suporte.

Se você ainda não experimentou o NGINX Plus, recomendamos que experimente – para segurança, balanceamento de carga e gateway de API, ou como um servidor web totalmente suportado com APIs aprimoradas de monitoramento e gerenciamento. Você pode começar hoje mesmo com um teste gratuito de 30 dias . Veja você mesmo como o NGINX Plus pode ajudar você a entregar e dimensionar seus aplicativos.