Anunciando o NGINX Plus R14

Liam CrillyDiretor Sênior de Gestão de Produtos

Temos o prazer de anunciar que o NGINX Plus Release 14 (R14) já está disponível para nossos assinantes do NGINX Plus. O NGINX Plus é o único balanceador de carga, cache de conteúdo e servidor web completo. Ele é baseado no NGINX Open Source e acrescenta recursos exclusivos, além de suporte 24 horas premiado. O NGINX Plus R14 inclui novos aprimoramentos de segurança e clustering.

Com o NGINX Plus, você pode aplicar controles de acesso usando JSON Web Tokens (JWTs). O NGINX Plus R14 adiciona suporte a declarações JWT aninhadas, permitindo conceder ou negar acesso com base em informações de associação a grupos aninhadas em um JWT. O suporte nativo à autenticação JWT, introduzido pela primeira vez no NGINX Plus R10, permite que o NGINX Plus seja usado como gateway de autenticação para suas APIs e aplicações.

Outros recursos do NGINX Plus R14 incluem:

• Suporte ampliado a clustering (prévia da tecnologia) – Convidamos você a testar uma prévia da nova funcionalidade de compartilhamento de informações de estado entre as instâncias do NGINX Plus em um cluster. Nesta prévia, o estado do método de persistência de sessão sticky learn é compartilhado. Em versões futuras, ampliaremos o suporte a clustering para outros recursos do NGINX Plus.
• Tamanhos maiores de chave JWT – Além do suporte a declarações JWT aninhadas e dados de matriz, agora os algoritmos de assinatura JWT são compatíveis com chaves maiores (de até 512 bits). Isso proporciona mais segurança e flexibilidade na validação de JWTs.
• Armazenamento de chave-valor e API para fluxos – O poderoso armazenamento de chave-valor e a API introduzidos na versão 13 para aplicações HTTP agora estão disponíveis também para aplicações TCP e UDP no contexto stream.
• Aprimoramentos no módulo JavaScript do NGINX – O módulo, que permite executar código JavaScript no NGINX Plus, agora oferece suporte adicional da linguagem ao objeto JSON. [O módulo era anteriormente chamado de nginScript.] Isso permite analisar e extrair nativamente informações de respostas JSON recebidas de APIs de backend e usar métodos no estilo do Node.js para acessar seu sistema de arquivos. Agora, o módulo também fornece rastreamentos de pilha para uma ampla variedade de objetos de exceção e erro quando eles ocorrem, facilitando a depuração e a solução de problemas.
• Mais recursos – O NGINX Plus também conta com um painel atualizado de monitoramento de atividades em tempo real, uma nova variável SSL e a desativação gradual de servidores upstream.

Alterações de comportamento

• A API do NGINX Plus foi atualizada para a versão 2. Consulte a documentação de compatibilidade da API se estiver pensando em usar os novos recursos da API do NGINX Plus.
• As APIs nos módulos Upstream-Conf e Status estendido (habilitadas com as diretivas upstream_conf e status) foram descontinuadas a partir do NGINX Plus R13. Elas foram substituídas pela nova API do NGINX Plus, usada pelo painel de monitoramento de atividades em tempo real atualizado incluído no R14.
• O NGINX Plus agora está disponível para o Ubuntu 17.10 (Artful Aardvark).
• O NGINX Plus não é mais compatível com o Debian 7 (Wheezy).

Recursos do NGINX Plus R14 em detalhes

Aprimoramentos de JWT

Os responsáveis pela implantação de APIs e microsserviços estão adotando o padrão JSON Web Token (JWT, pronunciado “jot”) devido à sua simplicidade e flexibilidade. Um JWT é um meio compacto e altamente portátil de trocar informações de identidade. É possível obter JWTs de diversos emissores, incluindo Okta, OneLogin e soluções desenvolvidas internamente. O NGINX Plus pode então conceder ou negar acesso com base na apresentação ou não de um JWT válido pelo usuário ou cliente da API.

O NGINX Plus R14 adiciona suporte a declarações JWT aninhadas e dados de matriz, bem como a chaves mais longas para algoritmos de assinatura JWT. Isso proporciona mais flexibilidade e maior segurança na validação de JWTs.

Suporte a declarações JWT aninhadas e dados de matriz

Um payload JWT pode conter informações adicionais “aninhadas” sobre o usuário, como a associação a grupos, que podem ser usadas para autorizar o acesso a um recurso. Isso ajuda a evitar a necessidade de consultar um banco de dados várias vezes para autorizar as solicitações do usuário.

Considere o seguinte payload JWT:

{  "exp": 1513429677,
  "sub": "xample@example.com",
  "aud": "nginx",
  "attributes": {
    "name": "Xavier Ample",
    "room": "A123",
    "dept": "Demonstrations"
  },
  "groups": [
    "Administrator",
    "Foobar",
    "Bazpub"
  ]
}

No JWT acima, attributes é um objeto de “declaração aninhada” e groups é uma matriz. Você pode usar o trecho de configuração a seguir para passar o valor de name do objeto attributes para o backend e negar acesso aos usuários que não pertencem ao grupo Administrator.

auth_jwt_claim_set $jwt_groups groups; # Array value will join as comma-separated valuesauth_jwt_claim_set $jwt_real_name attributes name; # This value is two levels deep

map $jwt_groups $isAdmin {
	"~\bAdministrator\b" 1; # Appears within word boundaries (\b) of CSV list
	default              0;
}

server {
    listen 443 ssl;
    #ssl_*; # Config for SSL/TLS termination

    auth_jwt "closed site";
    auth_jwt_key_file jwk.json;

    location / {
        proxy_set_header X-RealName $jwt_real_name; # Pass real name as header
        proxy_set_header X-Subject  $jwt_claim_sub; # L1 claims set automatically
        proxy_pass http://my_backend;
    }
 
    location /admin {
        if ( $isAdmin = 0 ) {
            return 403; # Forbidden
        }
        proxy_pass http://my_backend;
    }
}

Veja mais detalhes sobre como essa configuração funciona:

• Usando a diretiva auth_jwt_claim_set, definimos a variável $jwt_groups do NGINX como a matriz groups definida no JWT. Os valores da matriz são separados por vírgulas e atribuídos a $jwt_groups.
• Usando a diretiva map, pesquisamos a palavra-chave Administrator na lista de grupos. Se ela estiver presente, o usuário será considerado um administrador e $isAdmin será definido como 1. Caso contrário, $isAdmin será definido como 0.
• O bloco location do URI /admin verifica a variável $isAdmin. Se o valor for 0, o NGINX retorna ao cliente o código de status 403 Forbidden.

Com o NGINX Plus R14, você também pode criar variáveis a partir de declarações JWT aninhadas. Em seguida, essas variáveis podem ser inseridas em cabeçalhos HTTP antes de as solicitações serem encaminhadas aos servidores de backend.

No exemplo acima, usamos a diretiva auth_jwt_claim_set para definir a variável $jwt_real_name do NGINX com o valor do objeto name dentro da declaração attributes. A diretiva proxy_set_header define o cabeçalho HTTP X-RealName com o valor do objeto name e encaminha a solicitação por proxy para my_backend.

Para obter mais informações sobre todas as diretivas de configuração disponíveis para autenticar JWTs com o NGINX Plus, consulte a documentação de referência.

Tamanhos de chave maiores para algoritmos de assinatura JWT

O NGINX Plus R14 agora oferece suporte a chaves de assinatura de 256, 384 e 512 bits, proporcionando uma validação de assinatura mais robusta e facilitando a integração com produtos de gerenciamento de identidades e acessos (IAM) que usam chaves de assinatura mais longas por padrão. As chaves de assinatura mais longas estão disponíveis para todos os algoritmos de assinatura compatíveis:

• HMAC com SHA‑2 (“HS”)
• RSA PKCS #1 com SHA‑2 (“RS”)
• Algoritmo de Assinatura Digital de Curva Elíptica (“ES”)

Por exemplo, você pode configurar o NGINX Plus R14 para aceitar apenas JSON Web Tokens assinados com o algoritmo RS512:

server {    listen 443 ssl;
    #ssl_*; # Config for SSL/TLS termination

    auth_jwt "closed site";
    auth_jwt_key_file jwk.json;

    location / {
        if ( $jwt_header_alg != RS512 ) {
            return 401;
        }
        proxy_pass http://my_backend;
    }
}

Nesse caso, o NGINX Plus não encaminha as solicitações por proxy se o JWT não tiver sido assinado com o algoritmo RS512 e retorna o código de status 401 Não autorizado ao cliente que emitiu a solicitação.

Observação: o suporte a JWT é exclusivo do NGINX Plus.

Armazenamento de chave-valor e API para o módulo Stream

O NGINX Plus R13 introduziu o módulo de armazenamento de chave-valor para HTTP, permitindo criar, modificar e remover dinamicamente pares de chave-valor em uma ou mais zonas de memória compartilhada. Um excelente caso de uso da API do armazenamento de chave-valor é utilizá-la com o fail2ban para criar uma lista dinâmica de bloqueio de IPs.

NGINX Plus R14 adiciona o módulo de armazenamento de chave-valor para Stream, disponibilizando para aplicações TCP e UDP os mesmos recursos de pares de chave-valor oferecidos às aplicações HTTP.

A reconfiguração dinâmica do armazenamento de chave-valor no contexto stream foi implementada no NGINX Plus R14 como parte da NGINX Plus API.

Observação: O armazenamento de chave-valor e a API são exclusivos do NGINX Plus.

Aprimoramentos no módulo JavaScript do NGINX

O módulo NGINX JavaScript (anteriormente chamado de nginScript) é uma linguagem de script baseada em JavaScript para o NGINX Plus. No NGINX Plus R14, os recursos do NGINX JavaScript foram ampliados para aprimorar ainda mais a capacidade de programação. O pacote atualizado do módulo dinâmico NGINX JavaScript oferece as novas melhorias a seguir.

Suporte a objetos JSON

O objeto JSON do JavaScript agora está disponível como um objeto nativo no NGINX JavaScript. Isso oferece uma maneira mais prática de gerenciar estruturas de dados complexas e também permite que o NGINX JavaScript analise e manipule respostas JSON recebidas de APIs de backend.

O exemplo de shell a seguir do njs demonstra como analisar e extrair dados JSON usando a sintaxe de objeto integrada.

$ njsinteractive njscript

v.<Tab> -> the properties and prototype methods of v.
type console.help() for more information

>> var my_data = '{"colors":[{"name":"red","fancy":"brick dust"}, {"name":"blue","fancy":"sea spray"}]}';
>> var my_object = JSON.parse(my_data);
>> my_object.colors[1].fancy;
sea spray
>>

Acesso ao sistema de arquivos

O Node.js, a implementação de JavaScript do lado do servidor mais popular, fornece métodos integrados para acessar o sistema de arquivos do sistema operacional (o JavaScript do lado do cliente não permite acesso ao sistema de arquivos). Com o NGINX Plus R14, agora você pode usar os métodos de sistema de arquivos do Node.js no NGINX JavaScript para ler e gravar arquivos, permitindo personalizar o fluxo de trabalho de entrega da sua aplicação. As seguintes operações são permitidas:

• Leitura – fs.readFile, fs.readFileSync
• Gravação – fs.writeFile, fs.writeFileSync
• Anexar – fs.appendFile, fs.appendFileSync

Este exemplo de shell do NGINX JavaScript mostra como o NGINX JavaScript pode ser usado para ler o conteúdo de um arquivo e armazená-lo em uma variável.

$ njsinteractive njscript

v.<Tab> -> the properties and prototype methods of v.
type console.help() for more information

>> var fs = require('fs');
>> var tz = fs.readFileSync('/etc/timezone');
>> tz
Europe/London
>>

Objetos de erro e rastreamentos de pilha

Para ajudar ainda mais os desenvolvedores na depuração e na solução de problemas, agora está disponível uma ampla variedade de objetos de erro:

• Erro
• EvalError
• InternalError
• RangeError
• ReferenceError
• SyntaxError
• TypeError
• URIError

Além disso, o NGINX JavaScript agora fornece rastreamentos de pilha para erros e exceções. A entrada a seguir do log de erros mostra um rastreamento de pilha simples de uma operação do sistema que falhou.

2017/12/12 01:52:08 [error] 43441#43441: *10 js exception: Error: No such file or directory    at native (native)
    at my_function (:1)
    at main (native)
, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", host: "localhost:80"

Saiba como começar a usar o NGINX JavaScript<.htmla> em nosso blog.

Painel do NGINX Plus usando a API do NGINX Plus

O NGINX Plus R13 introduziu a API do NGINX Plus, que fornece acesso a monitoramento e métricas em tempo real no formato JSON. No NGINX Plus R14, o painel integrado de monitoramento de atividades em tempo real agora usa a API do NGINX Plus, fornecendo ao usuário mais de 80 métricas de monitoramento em tempo real.

As APIs de reconfiguração dinâmica e de status estendido usadas pelo painel em versões anteriores do NGINX Plus foram descontinuadas. As APIs ainda estão disponíveis nesta versão e serão incluídas no NGINX Plus R15. Elas serão totalmente removidas no NGINX Plus R16, portanto, recomendamos que você atualize suas configurações agora.

A configuração do painel obsoleto é semelhante a esta:

location /status { # DEPRECATED    status;        # DEPRECATED
    # directives controlling access, such as 'allow' and 'deny'
}

location = /status.html {       # DEPRECATED
    root /usr/share/nginx/html; # DEPRECATED
}

Para migrar suas instâncias existentes do NGINX Plus para o novo painel do NGINX Plus, substitua o trecho anterior por este:

location /api {    api write=on;
    # directives controlling access, such as 'allow' and 'deny'
}

location = /dashboard.html {
    root /usr/share/nginx/html;
}

# Redirect requests made to the old dashboard
location = /status.html {
    return 301 /dashboard.html;
}

Conforme mostrado nos trechos de código, recomendamos enfaticamente que você restrinja o acesso à API, por exemplo, usando as diretivas allow e deny. Migre os controles de acesso existentes do local /status para o local /api.

Para mais informações sobre a nova API do NGINX Plus, consulte o anúncio do NGINX Plus R13.

Observação: o painel integrado é exclusivo do NGINX Plus.

Drenagem de servidores upstream no arquivo de configuração

Ao retirar um servidor de operação, você pode melhorar a experiência do usuário permitindo que as sessões existentes sejam concluídas e, ao mesmo tempo, impedindo que novas sessões sejam estabelecidas. O servidor só fica offline quando não há mais nenhuma sessão ativa. Esse processo é chamado de drenagem do servidor. Você pode fazer isso dinamicamente com a API do NGINX Plus enviando uma solicitação PATCH que inclua {"drain":true} ao recurso da API correspondente ao servidor em questão.

O NGINX Plus R14 estende essa funcionalidade à configuração baseada em arquivo ao fornecer um parâmetro drain para a diretiva server do upstream.

upstream my_backend {        server  10.0.0.1;
        server  10.0.0.2;
        server  10.0.0.3 drain;
}

Quando você recarrega a configuração do NGINX Plus, o servidor upstream com o IP 10.0.0.3 entra no modo de drenagem. Posteriormente, você pode desativar completamente o servidor removendo a diretiva server correspondente ou substituindo o parâmetro draining por down.

Suporte a clustering para Sticky Learn (prévia da tecnologia)

Com o NGINX Plus R14, temos o prazer de anunciar uma prévia tecnológica de um futuro recurso para o compartilhamento de estado em um cluster de instâncias do NGINX Plus. A prévia tecnológica implementa o método sticky learn de persistência de sessão para demonstrar os benefícios do compartilhamento de dados de sessão que, de outra forma, seriam gerenciados individualmente por cada instância.

A prévia da tecnologia é fornecida como um pacote instalável separado e está disponível mediante solicitação. Entre em contato com seu representante de vendas da NGINX para obter acesso.

Observações:

1. A funcionalidade de clustering do sticky learn está em versão prévia e, portanto, não é adequada para uso em produção. Se o compartilhamento de estado em um cluster for um requisito importante para o seu ambiente, recomendamos que você teste a versão prévia da tecnologia e forneça feedback à NGINX sobre o quanto ela atende às suas necessidades.
2. Os pacotes de prévia da tecnologia estão disponíveis para CentOS/RHEL/Oracle Linux 7, Debian 8 e 9 e Ubuntu 16.04, 16.10 e 17.10.

Observação: O suporte a clustering e a persistência de sessão sticky‑learn são recursos exclusivos do NGINX Plus.

Recursos adicionais

NGINX Plus R14 também inclui as seguintes melhorias:

• Persistência do estado do resolvedor entre recarregamentos – Uma maneira de reconfigurar dinamicamente o conjunto de servidores em um grupo upstream é usar um nome de host ou domínio como parâmetro da diretiva server; o DNS resolve o nome periodicamente, e o NGINX Plus usa automaticamente o conjunto atualizado de servidores (consulte o Guia de Administração do NGINX Plus). Agora, o NGINX Plus mantém os registros DNS do nome de host ou domínio após um recarregamento do NGINX Plus. Anteriormente, era necessário resolver o nome novamente após um recarregamento, o que impedia o atendimento das solicitações recebidas antes da conclusão da resolução.
• Nova variável de certificado de cliente SSL – A variável $ssl_client_escaped_cert é uma nova variável incorporada do NGINX que oferece uma maneira segura e prática de codificar seus certificados de cliente em um cabeçalho HTTP para que você possa enviá-los aos seus aplicativos de backend. A variável é codificada para URL.

Atualize ou experimente o NGINX Plus

O NGINX Plus R14 inclui recursos aprimorados de autenticação para seus aplicativos clientes, recursos adicionais de clustering, melhorias no NGINX JavaScript e correções de bugs importantes. Especificamente, o NGINX Plus R13 introduziu um bug nas verificações ativas de integridade que poderia fazer com que um processo de trabalho antigo executasse verificações de integridade indefinidamente. Esse problema foi resolvido no NGINX Plus R14.

Se você estiver usando o NGINX Plus, recomendamos enfaticamente que atualize para a versão 14 o mais rápido possível. Você terá acesso a diversas correções e melhorias, e a atualização ajudará a NGINX a oferecer suporte quando você precisar abrir um chamado. As instruções de instalação e atualização estão disponíveis no portal do cliente.

Antes de prosseguir com a atualização, analise cuidadosamente os novos recursos e as mudanças de comportamento descritos nesta publicação do blog.

Se você ainda não experimentou o NGINX Plus, recomendamos que o experimente para aceleração da Web, balanceamento de carga e entrega de aplicações, ou como um servidor Web com suporte completo e APIs avançadas de monitoramento e gerenciamento. Comece hoje mesmo gratuitamente com uma avaliação 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