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:
root
). Esta solução totalmente suportada está alinhada à tendência crescente em direção a modelos de segurança de confiança zero.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.
proxy_cookie_flags
. O módulo será removido no NGINX Plus R26 . Para obter detalhes, consulte Método nativo para definir sinalizadores de cookies .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:
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:
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.)
Baixe o script e certifique-se de que ele é executável:
$ chmod +x ngxunprivanst.sh
‑c
e ‑k
estão incluídas em todos os comandos ngxunprivinst.sh
para identificá-los.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
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
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
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.
(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
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:
code_verifier
.code_verifier
chamada code_challenge
.auth_code
do usuário para o NGINX Plus.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.
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.
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:
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:
proxy_ssl_conf_command
comando grpc_ssl_conf
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.
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.
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):
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" }
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.
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 .
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.
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:
js_include
está obsoleta e foi substituída pela diretiva js_import
js_content
e js_set
podem referenciar uma função de móduloVerificaçõ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
.
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.
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."