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

Amir RawdatEngenheiro de Soluções

Embora o recurso Ingress padrão do Kubernetes seja excelente para provisionar e configurar o balanceamento de carga básico do Ingress, ele não inclui os recursos de personalização necessários para tornar o Kubernetes adequado para ambientes de produção. Em vez disso, os usuários que não utilizam o NGINX precisam recorrer a anotações, ConfigMaps e modelos personalizados, que são propensos a erros, difíceis de usar, inseguros e não oferecem um escopo granular. Os recursos Ingress do NGINX são a nossa solução para esse problema.

Os recursos do NGINX Ingress estão disponíveis tanto para a versão do NGINX Ingress Controller baseada no NGINX Open Source quanto para a baseada no NGINX Plus. Eles oferecem um estilo de configuração nativo, com tipagem segura e indentação, que simplifica a implementação do balanceamento de carga do Ingress. Neste blog, abordamos dois recursos introduzidos no NGINX Ingress Controller 1.11.0 que facilitam a configuração de políticas de WAF e de balanceamento de carga:

• Recurso TransportServer – O recurso TransportServer define a configuração do balanceamento de carga para TCP, UDP e passagem direta de TLS. Adicionamos verificações de integridade, relatórios de status e trechos de configuração para aprimorar 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 usar os recursos do NGINX Ingress para aplicar políticas de WAF a serviços específicos do Kubernetes.

Aprimoramentos no recurso TransportServer

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

• Trechos de código
• Verificações de integridade
• Suporte a múltiplos recursos de TS

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

Snippets 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 introduz snippets para recursos TS, permitindo que você aproveite facilmente toda a gama de recursos do NGINX e do NGINX Plus para disponibilizar serviços baseados em TCP/UDP. Por exemplo, você pode usar snippets para adicionar as diretivas deny e allow, que usam endereços IP e intervalos para definir quais clientes podem acessar um serviço

apiVersion: k8s.nginx.org/v1alpha1kind: TransportServer
metadata:
  name: cafe
spec:
  host: cafe.example.com
  serverSnippets: |
    deny  192.168.1.1;
    allow 192.168.1.0/24;
  upstreams:
  - name: tea
    service: tea-svc
    port: 80

Verificações de integridade

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

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

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

Compatibilidade com vários recursos TransportServer usando ingressClassName

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

Para exibir o status de um ou de todos os recursos TS, execute o comando kubectl get transportserver; a saída inclui o estado (Valid ou Invalid), o motivo da atualização mais recente e, no caso de um único TS, uma mensagem personalizada.

$ kubectl get transportserver  NAME      STATE   REASON           AGE
  dns-tcp   Valid   AddedOrUpdated   47m

$ kubectl describe transportserver dns-tcp
. . .
Status:
  Message:  Configuration for default/dns-tcp was added or updated
  Reason:   AddedOrUpdated
  State:    Valid

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

Definindo uma política de WAF com suporte nativo ao 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égio mais rigorosas aos usuários responsáveis pelas sub-rotas de aplicações, conforme definido nos recursos VirtualServerRoute (VSR). Ao conceder às equipes certas acesso aos recursos adequados do Kubernetes, os recursos do NGINX Ingress oferecem controle granular sobre os recursos de rede e reduzem possíveis danos às aplicações caso as contas dos usuários sejam comprometidas ou invadidas.

A versão 1.11.0 apresenta um firewall de aplicações Web (WAF) nativo, com um objeto Policy, para estender esses benefícios à configuração do NGINX App Protect em suas implantações do Kubernetes. A política utiliza os objetos APLogConf e APPolicy introduzidos na versão 1.8.0 e pode ser associada a recursos VirtualServer (VS) e VSR. Isso significa que os administradores de segurança podem controlar todo o escopo da configuração do Ingress com recursos VS e, ao mesmo tempo, delegar responsabilidades de segurança a outras equipes por meio de referências a recursos VSR.

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

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: webapp
spec:
  host: webapp.example.com
  policies:
  - name: waf-prod 
  tls:
    secret: app-secret
  upstreams:
  - name: webapp-prod
    service: webapp-svc
    port: 80
  routes:
  - path: /v2
    route: test/test
  - path: /v1
    action:
      pass: webapp-prod

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

apiVersion: k8s.nginx.org/v1kind: VirtualServerRoute
metadata:
  name: test 
  namespace: test
spec:
  host: webapp.example.com
  upstreams:
  - name: webapp 
    service: webapp-test-svc
    port: 80
  subroutes:
  - path: /v2
    policies:
    - name: waf-test
    action:
      pass: webapp

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

Quais são as outras novidades da versão 1.11.0?

Com o NGINX Ingress Controller 1.11.0, reafirmamos nosso compromisso de fornecer um controlador Ingress pronto para ambientes de produção, flexível, avançado e fácil de usar. Além das melhorias no WAF e no TS, a versão 1.11.0 inclui os seguintes aprimoramentos:

• Validação de mais anotações – Evite mais erros de configuração
• Informações de status da política – Exiba o status dos objetos Policy antes que sejam aplicados à configuração do Ingress
• Compatibilidade com o Istio – Aproveite os recursos avançados do NGINX Ingress Controller em um ambiente Istio
• Endereços IP de cluster para endpoints upstream – Preencha os endpoints upstream na configuração do NGINX Ingress Controller com endereços IP de serviço/cluster

Validação de mais anotações

Com base nas melhorias na validação de anotações introduzidas na versão 1.10.0, agora também validamos as seguintes anotações:

Validação de anotaçõesnginx.org/client-max-body-size Deve ser um deslocamento válidonginx.org/fail-timeout Deve ser um período válidonginx.org/max-conns Deve ser um número inteiro não negativo válidonginx.org/max-fails Deve ser um número inteiro não negativo válidonginx.org/proxy-buffer-size Deve ser um tamanho válidonginx.org/proxy-buffers Deve ser uma especificação de buffer de proxy válidanginx.org/proxy-connect-timeout Deve ser um período válidonginx.org/proxy-max-temp-file-size Deve ser um tamanho válidonginx.org/proxy-read-timeout Deve ser um período válidonginx.org/proxy-send-timeout Deve ser um período válidonginx.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á do NGINX a configuração correspondente.

Informações de status sobre políticas

O comando kubectl get policy agora informa o estado da política (Valid ou Invalid) e, para um único TS, uma mensagem personalizada e o motivo da atualização mais recente.

$ kubectl get policy  NAME              STATE   AGE
  webapp-policy     Valid   30s

$ kubectl describe policy webapp-policy
. . .
Status:
  Message:  Configuration for default/webapp-policy was added or updated
  Reason:   AddedOrUpdated
  State:    Valid

Compatibilidade com o Istio

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

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

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

annotations:   traffic.sidecar.istio.io/includeInboundPorts: "" 
  traffic.sidecar.istio.io/excludeInboundPorts: "80,443"         
  traffic.sidecar.istio.io/excludeOutboundIPRanges: "10.90.0.0/16,10.45.0.0/16"     sidecar.istio.io/inject: 'true'

O segundo requisito é atendido por uma alteração no comportamento do campo requestHeaders. Nas versões anteriores, com a configuração a seguir, dois cabeçalhos Host eram enviados ao backend: $host e o valor especificado, bar.example.com.

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: foo 
spec:
  host: foo.example.com
  upstreams:
  - name: foo
    port: 8080
    service: backend-svc
    use-cluster-ip: true
  routes:
  - path: "/"
    action:
      proxy:
        upstream: foo
        requestHeaders: set: - name: Host value: 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 do 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 dos endereços IP individuais dos endpoints dos pods. Para permitir que o NGINX Ingress Controller encaminhe o tráfego para serviços Cluster-IP, inclua o campo use-cluster-ip: true na seção upstreams da configuração do VS ou VSR:

upstreams:  - name: tea
    service: tea-svc
    port: 80
    use-cluster-ip: true
  - name: coffee
    service: coffee-svc
    port: 80
    use-cluster-ip: true

Recursos

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

Para experimentar o NGINX Ingress Controller para Kubernetes com o NGINX Plus e o NGINX App Protect, inicie sua avaliação gratuita de 30 dias hoje mesmo ou entre em contato conosco para conversar sobre seus casos de uso.

Para experimentar 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é-compilado do DockerHub.

Para saber mais sobre as diferenças entre os controladores Ingress, confira o artigo Espera aí, qual NGINX Ingress Controller para Kubernetes estou usando? em nosso blog.

Sobre o autor

Amir RawdatEngenheiro de Soluções

Mais publicações de Amir Rawdat