BLOG | NGINX

Balanceamento de carga TCP/UDP aprimorado e configuração WAF com o NGINX Ingress Controller

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Amir Rawdat Miniatura
Amir Rawdat
Publicado em 31 de março de 2021

Embora o recurso padrão do Kubernetes Ingress seja ótimo para provisionar e configurar o balanceamento de carga básico do Ingress, ele não inclui o tipo de recursos de personalização necessários para tornar o Kubernetes de nível de produção . Em vez disso, os usuários não NGINX são deixados para usar anotações, ConfigMaps e modelos personalizados que são propensos a erros, difíceis de usar, não seguros e carecem de escopo detalhado. Os recursos do NGINX Ingress são nossa resposta para esse problema.

Os recursos do NGINX Ingress estão disponíveis para as versões NGINX Open Source e NGINX Plus do NGINX Ingress Controller. Eles fornecem um estilo de configuração nativo, seguro e recuado que simplifica a implementação do balanceamento de carga do Ingress. Neste blog, nos concentramos em dois recursos introduzidos no NGINX Ingress Controller 1.11.0 que facilitam a configuração de políticas de WAF e balanceamento de carga:

  • Recurso TransportServer – O recurso TransportServer define a configuração para balanceamento de carga TCP, UDP e TLS Passthrough. Adicionamos verificações de integridade, relatórios de status e trechos de configuração para melhorar o balanceamento de carga TCP/UDP.
  • Política de WAF do NGINX Ingress – Ao implantar o NGINX App Protect 3.0 com o NGINX Ingress Controller, você pode aproveitar os recursos do NGINX Ingress para aplicar políticas de WAF a serviços específicos do Kubernetes.

Melhorias no recurso TransportServer

O NGINX Ingress Controller 1.11.0 estende o recurso TransportServer (TS) nas seguintes áreas:

Observação:  As adições ao recurso TransportServer na versão 1.11.0 são uma prévia de tecnologia em desenvolvimento ativo. Eles serão graduados para um padrão de qualidade estável e pronto para produção em uma versão futura.

Fragmentos do TransportServer

No NGINX Ingress Controller , introduzimos snippets de configuração para os recursos VirtualServer e VirtualServerRoute (VS e VSR) que permitem estender nativamente as configurações do NGINX Ingress para clientes baseados em HTTP. A versão 1.11.0 apresenta snippets para recursos de TS, para que você possa aproveitar facilmente toda a gama de recursos do NGINX e do NGINX Plus para fornecer serviços baseados em TCP/UDP. Por exemplo, você pode usar snippets para adicionar diretivas de negação e permissão que usam endereços IP e intervalos para definir quais clientes podem acessar um serviço

apiVersão: k8s.nginx.org/v1alpha1kind: TransportServer
metadados:
nome: cafe
especificação:
host: cafe.example.com
serverSnippets: |
negar 192.168.1.1;
permitir 192.168.1.0/24;
upstreams:
-nome: tea
serviço: tea-svc
porta: 80

Verificações de integridade

Para monitorar a integridade de um cluster Kubernetes, o NGINX Ingress Controller não apenas considera as sondas do Kubernetes que são locais para pods de aplicativos, mas também monitora o status da rede entre serviços upstream baseados em TCP/UDP, com verificações de integridade passivas para avaliar a integridade das transações em andamento e verificações de integridade ativas (exclusivas do NGINX Plus) para sondar endpoints periodicamente com solicitações de conexão sintéticas.

As verificações de integridade podem ser muito úteis para interromper circuitos e lidar com erros de aplicativos. Você pode personalizar a verificação de integridade usando parâmetros no campo healthCheck do recurso TS que definem o intervalo entre as sondagens, o tempo limite da sondagem, os tempos de atraso entre as sondagens e muito mais.

Além disso, você pode definir o serviço upstream e a porta de destino das sondas de integridade do NGINX Ingress Controller. Isso é útil em situações em que a integridade do aplicativo upstream é exposta em um ouvinte diferente por outro processo ou subsistema que monitora vários componentes downstream do aplicativo.

Suporte a vários recursos do TransportServer com ingressClassName

Ao atualizar e aplicar um recurso TS, é útil verificar se a configuração é válida e foi aplicada com sucesso à implantação correspondente do Ingress Controller. A versão 1.11.0 apresenta o campo ingressClassName e o relatório de status para o recurso TS. O campo ingressClassName garante que o recurso TS seja processado por uma implantação específica do Ingress Controller em ambientes onde você tem várias implantações.

Para exibir o status de um ou todos os recursos do TS, execute o comando kubectl get transportserver ; a saída inclui o estado ( Válido ou Inválido ), o motivo da atualização mais recente e (para um único TS) uma mensagem personalizada.

$ kubectl get transportserver NOME ESTADO MOTIVO IDADE dns-tcp Válido Adicionado ou Atualizado 47m $ kubectl describe transportserver dns-tcp . . .
Status:
  Mensagem:  A configuração para default/dns-tcp foi adicionada ou atualizada Motivo:   Estado AdicionadoOuAtualizado:    Válido

Se vários recursos TS competirem pelo mesmo host/ouvinte, o NGINX Ingress Controller selecionará o recurso TS com os registros de data e hora mais antigos, garantindo um resultado determinístico nessa situação.

Definindo uma política WAF com suporte nativo do NGINX App Protect

Os recursos do NGINX Ingress não apenas tornam a configuração mais fácil e flexível, como também permitem delegar o controle de tráfego a diferentes equipes e impor restrições de privilégios mais rígidas aos usuários que possuem sub-rotas de aplicativos, conforme definido nos recursos do VirtualServerRoute (VSR). Ao dar às equipes certas acesso aos recursos certos do Kubernetes, os recursos do NGINX Ingress oferecem controle refinado sobre os recursos de rede e reduzem possíveis danos aos aplicativos caso os usuários sejam comprometidos ou hackeados.

A versão 1.11.0 apresenta um objeto de política de firewall de aplicativo Web (WAF) nativo para estender esses benefícios à configuração do NGINX App Protect em suas implantações do Kubernetes. A política aproveita os objetos APLogConf e APPolicy introduzidos na versão 1.8.0 e pode ser anexada aos recursos VirtualServer (VS) e VSR. Isso significa que os administradores de segurança podem ter propriedade sobre todo o escopo da configuração do Ingress com recursos do VS, ao mesmo tempo em que delegam responsabilidades de segurança a outras equipes referenciando recursos do VSR.

No exemplo a seguir, a política waf-prod é aplicada aos usuários roteados para o upstream webapp-prod . Para delegar responsabilidades de segurança para a rota /v2 entre namespaces de propriedade de equipes diferentes, a diretiva de rota destacada faz referência a um recurso VSR.

apiVersão: k8s.nginx.org/v1kind: Metadados do VirtualServer: nome: webapp especificação: host: webapp.example.com políticas: - nome: waf-prod tls: segredo: app-secret upstreams: - nome: webapp-prod serviço: webapp-svc porta: 80 rotas: - caminho: /v2 rota: teste/teste - caminho: /v1 ação: senha: webapp-prod

As equipes que gerenciam o namespace de teste podem definir seus próprios parâmetros e políticas WAF usando recursos VSR nesse namespace.

apiVersão: k8s.nginx.org/v1kind: VirtualServerRoute
metadados:
nome: teste
namespace: teste
especificação:
host: webapp.example.com
upstreams:
-nome: webapp
serviço: webapp-test-svc
porta: 80
subrotas:
- caminho: /v2
políticas:
- nome: waf-test
ação:
senha: webapp

Este exemplo separa os locatários por namespace e aplica uma política WAF diferente para o serviço webapp-test-svc no namespace de teste . Ele ilustra como delegar recursos a diferentes equipes e encapsulá-los com objetos simplifica o teste de novas funcionalidades sem interromper os aplicativos em produção.

O que mais há de novo na versão 1.11.0?

Com o NGINX Ingress Controller 1.11.0, continuamos nosso compromisso de fornecer um controlador Ingress de nível de produção que seja flexível, poderoso e fácil de usar. Além das melhorias do WAF e do TS, a versão 1.11.0 inclui os seguintes aprimoramentos:

Validação de Mais Anotações

Com base nas melhorias na validação de anotações introduzidas na versão 1.10.0, agora estamos validando as seguintes anotações adicionais:

Anotação Validação
nginx.org/client-max-body-size Deve ser um deslocamento válido
nginx.org/fail-timeout Deve ser um horário válido
nginx.org/max-conns Deve ser um inteiro não negativo válido
nginx.org/max-fails Deve ser um inteiro não negativo válido
nginx.org/proxy-buffer-size Deve ser um tamanho válido
nginx.org/proxy-buffers Deve ser uma especificação de buffer de proxy válida
nginx.org/proxy-connect-timeout Deve ser um horário válido
nginx.org/proxy-max-temp-file-size Deve ser um tamanho válido
nginx.org/proxy-read-timeout Deve ser um horário válido
nginx.org/proxy-send-timeout Deve ser um horário válido
nginx.org/upstream-zone-size Deve ser um tamanho válido

Se o valor da anotação não for válido quando o recurso Ingress for aplicado, o Ingress Controller rejeitará o recurso e removerá a configuração correspondente do NGINX.

Informações de status sobre políticas

O comando kubectl get policy agora relata o estado da política ( Válido ou Inválido ) e (para um único TS) uma mensagem personalizada e o motivo da atualização mais recente.

$ kubectl get policy NOME ESTADO IDADE webapp-policy Válido 30s $ kubectl describe policy webapp-policy . . .
Status:
  Mensagem:  A configuração para default/webapp-policy foi adicionada ou atualizada Motivo:   Estado AdicionadoOuAtualizado:    Válido

Compatibilidade com Istio

O NGINX Ingress Controller agora pode ser usado como controlador Ingress para aplicativos executados dentro de uma malha de serviço Istio. Isso permite que os usuários continuem usando os recursos avançados que o NGINX Ingress Controller fornece em ambientes baseados em Istio sem recorrer a soluções alternativas. Essa integração envolve dois requisitos:

  • A injeção de um sidecar Istio na implantação do NGINX Ingress Controller
  • Apenas um cabeçalho HTTP Host é enviado para o backend

Para atender ao primeiro requisito, inclua os seguintes itens no campo de anotações do seu arquivo de implantação do NGINX Ingress.

anotações: traffic.sidecar.istio.io/includeInboundPorts: "" 
traffic.sidecar.istio.io/excludeInboundPorts: "80.443" tráfego.sidecar.istio.io/excludeOutboundIPRanges: "10.90.0.0/16,10.45.0.0/16" sidecar.istio.io/inject: 'verdadeiro'

O segundo requisito é alcançado por uma alteração no comportamento do campo requestHeaders . Em versões anteriores, com a seguinte configuração, dois cabeçalhos de Host eram enviados para o backend: $host e o valor especificado, bar.example.com .

apiVersão: k8s.nginx.org/v1kind: Metadados do VirtualServer: nome: foo especificação: host: foo.example.com upstreams: - nome: foo porta: 8080 serviço: backend-svc use-cluster-ip: true rotas: - caminho: "/" ação: proxy: upstream: foo requestHeaders: set: - nome: Valor do host: bar.example.com

Na versão 1.11.0 e posteriores, somente o valor especificado é enviado. Para enviar $host , omita completamente o campo requestHeaders .

Endereços IP de cluster para endpoints upstream

Os endpoints upstream na configuração do NGINX Ingress Controller agora podem ser preenchidos com endereços IP de serviço/cluster, em vez de endereços IP individuais de endpoints de pod. Para permitir que o NGINX Ingress Controller roteie o tráfego para serviços Cluster‑IP, inclua o campo use-cluster-ip: true na seção upstreams da sua configuração do VS ou VSR:

upstreams: - nome: serviço de chá: tea-svc porta: 80 use-cluster-ip: true - nome: serviço de café: coffee-svc porta: 80 use-cluster-ip: verdadeiro

Recursos

Para o changelog completo da versão 1.11.0, consulte as Notas de versão .

Para experimentar o NGINX Ingress Controller para Kubernetes com NGINX Plus e NGINX App Protect, comece seu teste gratuito de 30 dias hoje mesmo ou entre em contato conosco para discutir seus casos de uso .

Para testar o NGINX Ingress Controller com o NGINX Open Source, você pode obter o código-fonte da versão ou baixar um contêiner pré-criado do DockerHub .

Para uma discussão sobre as diferenças entre os controladores Ingress, confira Wait, Which NGINX Ingress Controller for Kubernetes Am I Using? no nosso blog.


"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."