Container Service for Kubernetes:Upgrade the NGINX Ingress controller

Alterações na configuração de segurança padrão

Versões afetadas: Versões anteriores à v1.12.6-release.1.

A partir da v1.12.6-release.1, o ingress-nginx reforçou as configurações de segurança padrão, incluindo:

• O nível padrão de annotations-risk-level foi reduzido de Critical para High. Essa alteração torna indisponíveis os recursos Ingress existentes com anotações de nível Critical, como anotações relacionadas a snippet.

• allow-cross-namespace-resources foi alterado de true para false. Essa configuração desativa, por padrão, a referência cruzada entre namespaces de recursos como ConfigMap e Secrets.

• strict-validate-path-type foi alterado de false para true. Essa configuração ativa a validação estrita de caminho por padrão. Isso significa que, para caminhos do tipo Exact e Prefix, apenas caminhos que começam com / e contêm apenas letras, números, -, _, ., e / adicionais são permitidos.

Se você utilizar recursos bloqueados por essas configurações de segurança, ative-os manualmente no ConfigMap kube-system/nginx-configuration após avaliar os riscos de segurança.

A validação nativa do NGINX está desativada por padrão

Versões afetadas: Versões anteriores à v1.11.5-aliyun.1.

Para corrigir a CVE-2025-1974, o controlador NGINX Ingress desativa a validação nativa do NGINX (a lógica nginx -t) por padrão a partir da v1.11.5-aliyun.1. O webhook de validação permanece ativado, mas não valida regras baseadas em snippet; apenas anotações que não sejam snippets são validadas por padrão. Para regras de snippet, verifique os logs de erro de runtime do NGINX. Consulte o Anúncio das Vulnerabilidades CVE-2023-1097, CVE-2023-1098, CVE-2023-1974, CVE-2023-24513, CVE-2023-24514.

Se você usar anotações de snippet, verifique nos logs do Pod do NGINX Ingress entradas relacionadas a Error sempre que alterar as regras de Ingress correspondentes:

kubectl logs -f <Nginx-ingress-pod-name> -n kube-system |grep Error

Para reativar a validação nativa do NGINX, adicione enable-nginx-native-validation: "true" ao ConfigMap kube-system/nginx-configuration após avaliar totalmente os riscos.

Anotações de snippet estão desativadas por padrão

Versões afetadas: Versões anteriores à v1.9.3-aliyun.1.

Por motivos de segurança, o controlador NGINX Ingress desativa todas as anotações de snippet por padrão a partir da v1.9.3-aliyun.1, incluindo:

• nginx.ingress.kubernetes.io/configuration-snippet

• nginx.ingress.kubernetes.io/server-snippet

• nginx.ingress.kubernetes.io/stream-snippet

• nginx.ingress.kubernetes.io/auth-snippet

• nginx.ingress.kubernetes.io/modsecurity-snippet

Devido aos riscos de segurança e estabilidade, prefira anotações alternativas ou opções de configuração diferentes.

Para usar anotações de snippet, adicione allow-snippet-annotations: "true" ao ConfigMap kube-system/nginx-configuration após avaliar totalmente os riscos.

Versões legadas de TLS não são suportadas

Versões afetadas: Versões anteriores à v1.7.0-aliyun.1.

Devido a problemas de segurança no TLS 1.1 e anteriores, as novas versões do NGINX Ingress não suportam mais TLS v1.1 e TLS v1.0 por padrão. Antes de atualizar, verifique se seus serviços não dependem de TLS v1.1 ou anterior e remova-os da sua configuração. As alterações no ConfigMap entram em vigor imediatamente.

Por exemplo, se o ConfigMap (kube-system/nginx-configuration) do controlador NGINX Ingress estiver configurado da seguinte forma:

ssl-protocols: SSLv3 SSLv2 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3

Após confirmar que seus serviços não serão afetados, remova esta linha para usar os padrões, ou remova SSLv3, SSLv2, TLSv1 e TLSv1.1 e altere a linha para:

ssl-protocols: TLSv1.2 TLSv1.3

Para impor métodos de criptografia TLS mais antigos, consulte Quais versões SSL/TLS são suportadas pelos Ingresses?.

Uso incompatível de nginx.ingress.kubernetes.io/rewrite-target

Versões afetadas: Versões anteriores à 0.22.0.

• A versão 0.22.0 alterou o uso da anotação nginx.ingress.kubernetes.io/rewrite-target. Nas versões 0.22.0 e posteriores, é necessário especificar explicitamente grupos de captura ao usar rewrite-target.

• O comportamento do rewrite-target anterior à 0.22.0 é incompatível com as versões atuais. Antes de atualizar, use a anotação configuration-snippet em vez de rewrite-target.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
  name: rewrite
  namespace: default
spec:
  rules:
  - host: rewrite.bar.com
    http:
      paths:
      - path: /something/
        pathType: Prefix
        backend:
          service:
            name: http-svc
            port:
              number: 80
      - path: /something123/
        pathType: Prefix
        backend:
          service:
            name: http-svc-1
            port:
              number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    # Use the rewrite directive, where /something is the path in the path field (without the trailing slash).
    # If the Ingress contains multiple paths, multiple rewrite directives are needed.
    nginx.ingress.kubernetes.io/configuration-snippet: |
      rewrite "(?i)/something(/|$)(.*)" /$2 break;
      rewrite "(?i)/something123(/|$)(.*)" /$2 break;
  name: rewrite
  namespace: default
spec:
  rules:
  - host: rewrite.bar.com
    http:
      paths:
      - path: /something/ # Keep the path consistent with the old Ingress resource.
        pathType: Prefix
        backend:
          service:
            name: http-svc
            port:
              number: 80
      - path: /something123/ # Keep the path consistent with the old Ingress resource.
        pathType: Prefix
        backend:
          service:
            name: http-svc-1
            port:
              number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    # Reference the matched content.
    nginx.ingress.kubernetes.io/rewrite-target: /$2
  name: rewrite
  namespace: default
spec:
  rules:
  - host: rewrite.bar.com
    http:
      paths:
      # Use a capture group.
      - path: /something(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: http-svc
            port:
              number: 80
      # Use a capture group.
      - path: /something123(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: http-svc-1
            port:
              number: 80

  apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    labels:
      ingress-controller: nginx
    name: test
    namespace: default
  spec:
    ingressClassName: nginx
    rules:
    - host: www.example.com
      http:
        paths:
        - backend:
            service:
              name: api-resources-svc
              port:
                number: 8080
          path: /api/resource

data:
  use-gzip: true

Verificar o status do componente e dos serviços

Além das suas próprias ferramentas de monitoramento, o ACK fornece logs do Simple Log Service, painéis do Managed Service for Prometheus e logs nativos de contêineres para monitorar o NGINX Ingress. Para ativá-los, consulte Coletar e analisar logs de acesso do NGINX Ingress e Conectar e configurar o Managed Service for Prometheus.

Posso atualizar o controlador NGINX Ingress para uma versão específica? Posso reverter para uma versão anterior após uma atualização bem-sucedida?

O controlador NGINX Ingress não suporta atualização para uma versão específica. As atualizações prosseguem em fases até a versão mais recente. Não é possível reverter após uma atualização bem-sucedida.

O que fazer se um Pod falhar ao ser criado durante a fase de verificação ou liberação?

O que fazer se a verificação do modelo do Deployment falhar?

Se o modelo do Deployment falhar na verificação prévia, clique no link ao lado de Cause of Error para abrir a página de diferenças do componente e visualizar os campos com falha.

1. Na página NGINX Ingress Controller Upgrade, em Precheck, clique em View Details.

2. Na página Check Report, na seção Cluster Component Check Results, clique na caixa vermelha em ① para visualizar os resultados da verificação. Em seguida, na página Check Result, clique em Deployment Template e, finalmente, clique no link ao lado de Cause of Error em ②.

   

3. Acesse a página Component Differences para visualizar os campos que falharam na verificação.

   A página de diferenças do componente compara o modelo padrão para esta versão (esquerda) com o modelo atual do cluster (direita), destacando diferenças compatíveis e incompatíveis. Ela também mostra se o componente do cluster passou na verificação de diferenças e lista os caminhos de campos incompatíveis.

   No exemplo abaixo, o campo divergente é .spec.template.spec.containers.(nginx-ingress-controller).args (parênteses indicam o nome do elemento do array). A comparação mostra que --v=2 em args foi alterado para --v=3, o que deve ser corrigido antes da atualização.

   

4. Modifique o campo divergente.

   Escolha Workloads > Deployments, localize o componente NGINX Ingress controller e escolha More > View YAML. Na página Edit YAML, altere --v=3 para --v=2 no campo args.

5. Após modificar o campo, atualize a página de diferenças do componente. Quando a página mostrar The component can pass the difference check, a verificação do modelo do Deployment será aprovada.

   Nota

   Modificar o Deployment do cluster reinicia os Pods do NGINX Ingress. Execute esta ação durante horários de baixa demanda.