Atualizando o controlador de entrada NGINX EOL com módulos integrados da Wallarm¶

Essas instruções descrevem as etapas para atualizar o Controlador de Entrada Wallarm em fim de vida (versão 3.6 e inferior) para a nova versão com o nó Wallarm 4.8.

Requisitos¶

• Versão da plataforma Kubernetes 1.24-1.27

• Gerenciador de pacotes Helm

• Compatibilidade dos seus serviços com o Controlador Ingress NGINX da comunidade versão 1.9.5

• Acesso à conta com a função de Administrador e autenticação de dois fatores desativada no Console Wallarm para a Nuvem US ou Nuvem EU

• Acesso a https://us1.api.wallarm.com para trabalhar com a Nuvem Wallarm US ou a https://api.wallarm.com para trabalhar com a Nuvem Wallarm EU

• Acesso a https://charts.wallarm.com para adicionar os gráficos Helm da Wallarm. Certifique-se de que o acesso não está bloqueado por um firewall

• Acesso aos repositórios Wallarm no Docker Hub https://hub.docker.com/r/wallarm. Certifique-se de que o acesso não está bloqueado por um firewall

• Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers

  US CloudEU Cloud

  34.96.64.17
  34.110.183.149
  35.235.66.155
  34.102.90.100
  34.94.156.115
  35.235.115.105
  

  34.160.38.183
  34.144.227.90
  34.90.110.226
  

Passo 1: Informe o suporte técnico da Wallarm que você está atualizando os módulos do nó de filtragem (apenas se atualizar o nó 2.18 ou inferior)¶

Se estiver atualizando o nó 2.18 ou inferior, informe o suporte técnico da Wallarm que você está atualizando os módulos do nó de filtragem para 4.8 e peça para ativar a nova lógica de listas de IP para sua conta Wallarm.

Quando a nova lógica de listas de IP estiver ativada, abra o Console Wallarm e certifique-se de que a seção Listas de IP está disponível.

Passo 2: Desative o módulo de verificação de ameaças ativas (apenas se atualizar o nó 2.16 ou inferior)¶

Se estiver atualizando o nó Wallarm 2.16 ou inferior, desative o módulo Threat Replay Testing no Console Wallarm → Vulnerabilities → Configure.

A operação do módulo pode causar falsos positivos durante o processo de atualização. Desativar o módulo minimiza este risco.

Passo 3: Atualize a porta da API¶

Começando com a versão 4.0, o nó de filtragem carrega dados para a nuvem usando os endpoints da API us1.api.wallarm.com:443 (NUvem EUA) e api.wallarm.com:443 (Nuvem EU) em vez de us1.api.wallarm.com:444 e api.wallarm.com:444.

Se você atualizar o nó da versão 3.x ou inferior e seu servidor com o nó implantado tiver acesso limitado aos recursos externos, e o acesso for concedido a cada recurso separadamente, então após a atualização a sincronização entre o nó de filtragem e a nuvem irá parar.

Para restaurar a sincronização, em sua configuração, altere a porta 444 para 443 para o endpoint da API para cada recurso.

Passo 4: Atualize o repositório de gráfico Helm da Wallarm¶

helm repo update wallarm

helm repo add wallarm https://charts.wallarm.com
helm repo update wallarm

Passo 5: Atualize a configuração values.yaml¶

Para migrar para Wallarm Ingress controller 4.8, atualize a seguinte configuração especificada no arquivo values.yaml:

• Configuração padrão do Community Ingress NGINX Controller

• Configuração do módulo Wallarm

Configuração padrão do Community Ingress NGINX Controller¶

1. Verifique as notas de lançamento sobre o Community Ingress NGINX Controller 0.27.0 e superior e defina as configurações que serão alteradas no arquivo values.yaml.

2. Atualize as configurações definidas no arquivo values.yaml.

Está a seguir configurações que provavelmente precisarão ser alteradas:

• Relatório adequado do endereço IP público do usuário final se as solicitações passarem por um balanceador de carga antes de serem enviadas para o controlador de entrada Wallarm.

  controller:
    config:
  -    use-forwarded-headers: "true"
  +    enable-real-ip: "true"
  +    forwarded-for-header: "X-Forwarded-For"
  

• Configuração de IngressClasses. A versão da API do Kubernetes em uso foi atualizada no novo controlador de entrada, o que exige que IngressClasses seja configurado por meio dos parâmetros .controller.ingressClass, .controller.ingressClassResource e .controller.watchIngressWithoutClass.

  controller:
  +  ingressClass: waf-ingress
  +  ingressClassResource:
  +    name: waf-ingress
  +    default: true
  +  watchIngressWithoutClass: true
  

• Conjunto de parâmetros do ConfigMap (.controller.config) ConfigMap (.controller.config), por exemplo:

  controller:
  config:
  +  allow-backend-server-header: "false"
    enable-brotli: "true"
    gzip-level: "3"
    hide-headers: Server
    server-snippet: |
      proxy_request_buffering on;
      wallarm_enable_libdetection on;
  

• Validação da sintaxe do Ingress via "webhook de admissão" agora está habilitada por padrão.

  controller:
  +  admissionWebhooks:
  +    enabled: true
  

  Desativando a validação da sintaxe do Ingress

  É recomendável desativar a validação da sintaxe do Ingress apenas se destabilizar a operação de objetos Ingress.

• Formato de Label. Se o arquivo values.yaml define regras de afinidade de pod, altere o formato do rótulo nessas regras, por exemplo:

  controller:
    affinity:
      podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - podAffinityTerm:
          labelSelector:
              matchExpressions:
  -            - key: app
  +            - key: app.kubernetes.io/name
              operator: In
              values:
              - waf-ingress
  -            - key: component
  +            - key: app.kubernetes.io/component
              operator: In
              values:
  -              - waf-ingress
  +              - controller
  -            - key: release
  +            - key: app.kubernetes.io/instance
              operator: In
              values:
              - waf-ingress-ingress
          topologyKey: kubernetes.io/hostname
          weight: 100
  

Configuração do módulo Wallarm¶

Altere a configuração do módulo Wallarm definida no arquivo values.yaml como segue:

• Se estiver atualizando da versão 2.18 ou inferior, migre a configuração da lista de IP. Estes são os seguintes parâmetros que potencialmente devem ser excluídos de values.yaml:

  controller:
    wallarm:
      enabled: true
      - acl:
      -  enabled: true
      resources: {}
  

  Como a lógica central da lista de IP foi significativamente alterada no nó Wallarm 3.x, é necessário ajustar a configuração da lista de IP adequadamente.

• Certifique-se de que o comportamento esperado das configurações listadas abaixo corresponde à lógica alterada dos modos de filtragem off e monitoring:

  • Diretiva wallarm_mode
  • Regra de filtragem geral configurada no Console Wallarm
  • Regras de filtragem de baixo nível configuradas no Console Wallarm

  Caso o comportamento esperado não corresponda à lógica modificada do modo de filtragem, ajuste as anotações de Ingress e outras configurações para as alterações lançadas.

• Elimine a configuração do serviço de monitoramento explícita. Na nova versão do controlador Wallarm Ingress, o serviço de monitoramento é habilitado por padrão e não requer nenhuma configuração adicional.

  controller:
  wallarm:
    enabled: true
    tarantool:
      resources: {}
  -  metrics:
  -    enabled: true
  -    service:
  -      annotations: {}
  

• Se a página &/usr/share/nginx/html/wallarm_blocked.html configurada via ConfigMap era retornada para solicitações bloqueadas, ajuste sua configuração para as alterações lançadas.

  Na nova versão do nó, a página de bloqueio de amostra da Wallarm tem a UI atualizada sem logotipo e email de suporte especificado por padrão.

• Se você personalizou a detecção de ataque overlimit_res através das diretrizes NGINX wallarm_process_time_limit e wallarm_process_time_limit_block, por favor, transfira estas configurações para a regra e delete do arquivo values.yaml.

Passo 6: Transferir a configuração de detecção de ataque overlimit_res das diretivas à regra¶

A partir da versão 3.6, você pode ajustar com precisão a detecção de ataque overlimit_res usando a regra no Wallarm Console.

Anteriormente, as diretivas NGINX wallarm_process_time_limit e wallarm_process_time_limit_block foram usadas. As diretivas listadas são consideradas obsoletas com o lançamento da nova regra e serão excluídas em lançamentos futuros.

Se as configurações de detecção de ataque overlimit_res são personalizadas através das diretivas listadas, recomenda-se transferi-las para a regra da seguinte maneira:

1. Abra o Wallarm Console → Regras e prossiga para a configuração da regra Ajustar a detecção de ataque overlimit_res.

2. Configure a regra como feito através das diretivas NGINX:

   • A condição da regra deve corresponder ao bloco de configuração NGINX com as diretivas wallarm_process_time_limit e wallarm_process_time_limit_block especificadas.
   • O tempo limite para o nodo processar uma única solicitação (milissegundos): o valor de wallarm_process_time_limit.

   • Processamento de solicitação: a opção Parar o processamento é recomendada.

     Risco de esgotamento de memória do sistema

     O alto limite de tempo e/ou a continuação do processamento de solicitações após o limite ter sido excedido podem provocar exaustão de memória ou processamento de solicitação fora do tempo.

   • Registre o ataque overlimit_res: a opção Registrar e exibir nos eventos é recomendada.

     Se o valor de wallarm_process_time_limit_block ou process_time_limit_block for off, escolha a opção Não criar evento de ataque.

   • A regra não possui a opção equivalente explícita para a diretiva wallarm_process_time_limit_block. Se a regra define Registrar e exibir nos eventos, o nó irá bloquear ou passar o ataque overlimit_res dependendo do modo de filtragem do nó:

     • No modo monitoramento, o nó encaminha a solicitação original para o endereço da aplicação. A aplicação tem o risco de ser explorada pelos ataques incluídos nas partes da solicitação processadas e não processadas.
     • No modo bloqueio seguro, o nó bloqueia a solicitação se ela for originada do endereço IP listado em cinza. Caso contrário, o nó encaminha a solicitação original para o endereço da aplicação. A aplicação tem o risco de ser explorada pelos ataques incluídos nas partes da solicitação processadas e não processadas.
     • No modo bloqueio, o nó bloqueia a solicitação.

3. Exclua as diretivas NGINX wallarm_process_time_limit e wallarm_process_time_limit_block do arquivo de configuração values.yaml.

   Se a detecção de ataque overlimit_res for ajustada usando as diretivas e a regra, o nó irá processar as solicitações como a regra determina.

Passo 7: Verifique todas as mudanças dos manifestos K8s que estão por vir¶

Para evitar mudanças inesperadamente no comportamento do Controlador de Entrada, revise todas as mudanças dos manifestos K8s que estão por vir usando Helm Diff Plugin. Este plugin exibe a diferença entre os manifestos K8s da versão do Controlador de Entrada implantada e da nova.

Para instalar e rodar o plugin:

1. Instale o plugin:

   helm plugin install https://github.com/databus23/helm-diff
   

2. Execute o plugin:

   helm diff upgrade <RELEASE_NAME> -n <NAMESPACE> wallarm/wallarm-ingress --version 4.8.2 -f <PATH_TO_VALUES>
   

   • <RELEASE_NAME>: O nome da liberação Helm com o gráfico do Controlador de Entrada
   • <NAMESPACE>: O namespace onde o Controlador de Entrada está implantado
   • <PATH_TO_VALUES>: o caminho para o arquivo values.yaml que define as configurações do controlador de entrada 4.8

3. Certifique-se de que nenhuma mudança pode afetar a estabilidade dos serviços em execução e examine cuidadosamente os erros do stdout.

   Se a stdout estiver vazia, verifique se o arquivo values.yaml é válido.

Por favor, note as mudanças das seguintes configurações:

• Campo imutável, por exemplo, os seletores de implantação e/ou StatefulSet.

• Labels de pod. As mudanças podem levar à interrupção da operação do NetworkPolicy, por exemplo:

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  spec:
    egress:
    - to:
      - namespaceSelector:
          matchExpressions:
          - key: name
            operator: In
            values:
            - kube-system # ${NAMESPACE}
        podSelector:
          matchLabels: # RELEASE_NAME=waf-ingress
  -         app: waf-ingress
  +         app.kubernetes.io/component: "controller"
  +         app.kubernetes.io/instance: "waf-ingress"
  +         app.kubernetes.io/name: "waf-ingress"
  -         component: waf-ingress
  

• Configuração do Prometheus com novos labels, por exemplo:

   - job_name: 'kubernetes-ingress'
     kubernetes_sd_configs:
     - role: pod
       namespaces:
         names:
           - kube-system # ${NAMESPACE}
     relabel_configs: # RELEASE_NAME=waf-ingress
       # Selectors
  -    - source_labels: [__meta_kubernetes_pod_label_app]
  +    - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name]
         action: keep
         regex: waf-ingress
  -    - source_labels: [__meta_kubernetes_pod_label_release]
  +    - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_instance]
         action: keep
         regex: waf-ingress
  -    - source_labels: [__meta_kubernetes_pod_label_component]
  +    - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_component]
         action: keep
  -      regex: waf-ingress
  +      regex: controller
       - source_labels: [__meta_kubernetes_pod_container_port_number]
         action: keep
         regex: "10254|18080"
         # Replacers
       - action: replace
         target_label: __metrics_path__
         regex: /metrics
       - action: labelmap
         regex: __meta_kubernetes_pod_label_(.+)
       - source_labels: [__meta_kubernetes_namespace]
         action: replace
         target_label: kubernetes_namespace
       - source_labels: [__meta_kubernetes_pod_name]
         action: replace
         target_label: kubernetes_pod_name
       - source_labels: [__meta_kubernetes_pod_name]
         regex: (.*)
         action: replace
         target_label: instance
         replacement: "$1"
  

• Analisar todas as outras mudanças.

Passo 8: Atualize o Controlador de Entrada¶

Existem três maneiras de atualizar o controlador de entrada Wallarm. Dependendo de haver ou não um balanceador de carga implantado em seu ambiente, selecione o método de atualização:

• Implantação do controlador de entrada temporário

• Re-criação regular do lançamento do controlador de entrada

• Lançamento do controlador de entrada de criação sem afetar o balanceador de carga

Método 1: Implantação do controlador de entrada temporário¶

Usando este método, você pode implantar o Controlador de Entrada 4.8 como uma entidade adicional em seu ambiente e alternar o tráfego para ele gradualmente. Isso ajuda a evitar mesmo tempo de inatividade temporário de serviços e garante uma migração segura.

1. Copie a configuração IngressClass do arquivo values.yaml da versão anterior para o arquivo values.yaml para o controlador de entrada Wallarm 4.8.

   Com essa configuração, o controlador de entrada identificará os objetos Ingress, mas não processará seu tráfego.

2. Implantar o Controlador de Entrada 4.8:

   helm install <RELEASE_NAME> -n <NAMESPACE> wallarm/wallarm-ingress --version 4.8.2 -f <PATH_TO_VALUES>
   

   • <RELEASE_NAME>: O nome para a liberação Helm do gráfico do controlador de entrada.
   • <NAMESPACE>: O namespace para implantar o controlador de entrada.
   • <PATH_TO_VALUES>: o caminho para o arquivo values.yaml que define as configurações do controlador de entrada 4.8

3. Certifique-se de que todos os serviços funcionam corretamente.

4. Troque a carga para o novo controlador de entrada gradualmente.

Método 2: Re-criação regular do lançamento do controlador de entrada¶

Se o balanceador de carga e o controlador de entrada NÃO estiverem descritos no mesmo gráfico Helm, você pode simplesmente recriar o lançamento Helm. Levará alguns minutos e o controlador de entrada ficará indisponível durante esse tempo.

Para recriar o lançamento do Controlador de Entrada:

Método 3: Criação do lançamento do controlador de entrada sem afetar o balanceador de carga¶

Ao usar o balanceador de carga configurado pelo provedor de nuvem, recomenda-se atualizar o controlador de entrada com este método porque não afeta o balanceador de carga.

A recriação do lançamento levará alguns minutos e o controlador de entrada ficará indisponível durante esse tempo.

1. Obtenha os objetos a serem excluídos (exceto o balanceador de carga):

   helm get manifest <RELEASE_NAME> -n <NAMESPACE> | yq -r '. | select(.spec.type != "LoadBalancer") | .kind + "/" + .metadata.name' | tr 'A-Z' 'a-z' > objects-to-remove.txt
   

   Para instalar a utilidade yq, use as instruções.

   Os objetos a serem excluídos serão emitidos para o arquivo objects-to-remove.txt.

2. Exclua os objetos listados e recrie o lançamento:

   cat objects-to-remove.txt | xargs kubectl delete --wait=false -n <NAMESPACE>    && \
   helm upgrade <RELEASE_NAME> -n <NAMESPACE> wallarm/wallarm-ingress --version 4.8.2 -f `<PATH_TO_VALUES>`
   

   Para diminuir o tempo de inatividade do serviço, NÃO é recomendável executar comandos separadamente.

3. Garanta que todos os objetos são criados:

   helm get manifest <RELEASE_NAME> -n <NAMESPACE> | kubectl create -f -
   

   A saída deve dizer que todos os objetos já existem.

Estão os seguintes parâmetros passados nos comandos:

• <RELEASE_NAME>: O nome do lançamento Helm com o gráfico do Controlador de Entrada.

• <NAMESPACE>: O namespace onde o controlador de entrada está implantado.

• <PATH_TO_VALUES>: O caminho para o arquivo values.yaml definindo as configurações do controlador de entrada 4.8.

Passo 9: Teste o controlador de entrada atualizado¶

1. Verifique se a versão do gráfico Helm foi atualizada:

   helm ls
   

   A versão do gráfico deve corresponder a wallarm-ingress-4.8.2.

2. Obtenha a lista de pods especificando o nome do controlador de entrada Wallarm em <INGRESS_CONTROLLER_NAME>:

   kubectl get pods -l release=<INGRESS_CONTROLLER_NAME>
   

   Cada status do pod deve ser STATUS: Running ou READY: N/N. Por exemplo:

   NAME                                                              READY     STATUS    RESTARTS   AGE
   ingress-controller-nginx-ingress-controller-675c68d46d-cfck8      3/3       Running   0          5m
   ingress-controller-nginx-ingress-controller-wallarm-tarantljj8g   4/4       Running   0          5m
   

3. Envie a solicitação com o teste Path Traversal ataque ao endereço do controlador de entrada Wallarm:

   curl http://<INGRESS_CONTROLLER_IP>/etc/passwd
   

   Se o nó de filtragem estiver funcionando no modo block, o código 403 Forbidden será retornado em resposta à solicitação e o ataque será exibido no Console Wallarm → Eventos.

Passo 10: Ajuste as anotações do Ingress para as mudanças lançadas¶

Ajuste as seguintes anotações do Ingress para as mudanças lançadas no controlador de entrada 4.8:

1. Se estiver atualizando a partir da versão 2.18 ou inferior, migre a configuração da lista de IPs. Como a lógica principal da lista de IPs foi significativamente alterada no nó Wallarm 3.x, é necessário ajustar a configuração da lista de IPs adequadamente, alterando as anotações do Ingress (se aplicável).

2. Certifique-se de que o comportamento esperado das configurações listadas abaixo corresponde à lógica alterada dos modos de filtragem off e monitoring:

   • Diretiva wallarm_mode
   • Regra de filtragem geral configurada no Console Wallarm
   • Regras de filtragem de baixo nível configuradas no Console Wallarm

   Caso o comportamento esperado não corresponda à lógica modificada do modo de filtragem, ajuste as anotações de Ingress para as alterações lançadas.

3. Se o Ingress estiver anotado com nginx.ingress.kubernetes.io/wallarm-instance, renomeie esta anotação para nginx.ingress.kubernetes.io/wallarm-application.

   Apenas o nome da anotação mudou, sua lógica permanece a mesma. A anotação com o nome anterior será descontinuada em breve, então recomenda-se renomeá-la antes.

4. Se a página &/usr/share/nginx/html/wallarm_blocked.html configurada via anotações do Ingress é retornada para solicitações bloqueadas, ajuste sua configuração para as alterações lançadas.

   Nas novas versões do nó, a página de bloqueio de amostra da Wallarm tem a IU atualizada sem logotipo e email de suporte especificado por padrão.

Passo 11: Reative o módulo de verificação de ameaça ativa (apenas se atualizar o nó 2.16 ou inferior)¶

Conheça a recomendação sobre a configuração do módulo de verificação de ameaças ativas e reative-o se necessário.

Depois de um tempo, garanta que a operação do módulo não cause falsos positivos. Se descobrir falsos positivos, por favor, entre em contato com o suporte técnico da Wallarm.

Was this page helpful?

How can we improve this article? (Optional)

Information is unclear or confusing

Insufficient information

Outdated or incorrect information

0/240

Send