Container Service for Kubernetes:Mettre à niveau le contrôleur NGINX Ingress

Modifications de la configuration de sécurité par défaut

Versions concernées : Versions antérieures à v1.12.6-release.1.

À partir de la v1.12.6-release.1, ingress-nginx a renforcé les paramètres de sécurité par défaut, notamment :

• Le niveau par défaut de annotations-risk-level est abaissé de Critical à High. Cette modification rend indisponibles les ressources Ingress existantes avec des annotations de niveau Critical, telles que les annotations liées à snippet.

• allow-cross-namespace-resources passe de true à false. Cette configuration désactive par défaut le référencement inter-namespace de ressources telles que ConfigMap et Secrets.

• strict-validate-path-type passe de false à true. Cette configuration active la validation stricte des chemins par défaut. Cela signifie que pour les chemins de type Exact et Prefix, seuls les chemins commençant par / et contenant uniquement des lettres, des chiffres, -, _, . et des / supplémentaires sont autorisés.

Si vous utilisez des fonctionnalités bloquées par ces paramètres de sécurité, activez-les manuellement dans le ConfigMap kube-system/nginx-configuration après avoir évalué les risques de sécurité.

La validation native NGINX est désactivée par défaut

Versions concernées : Versions antérieures à v1.11.5-aliyun.1.

Pour corriger la CVE-2025-1974, le contrôleur NGINX Ingress désactive la validation native NGINX (la logique nginx -t) par défaut à partir de la v1.11.5-aliyun.1. Le webhook de validation reste activé mais ne valide pas les règles basées sur des snippets ; seules les annotations non-snippet sont validées par défaut. Pour les règles snippet, vérifiez les journaux d'erreur d'exécution NGINX. Consultez l'Annonce de vulnérabilité CVE-2023-1097, CVE-2023-1098, CVE-2023-1974, CVE-2023-24513, CVE-2023-24514.

Si vous utilisez des annotations snippet, vérifiez les journaux des Pods NGINX Ingress pour les entrées liées aux erreurs chaque fois que vous modifiez les règles Ingress correspondantes :

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

Pour réactiver la validation native NGINX, ajoutez enable-nginx-native-validation: "true" au ConfigMap kube-system/nginx-configuration après avoir pleinement évalué les risques.

Les annotations Snippet sont désactivées par défaut

Versions concernées : Versions antérieures à v1.9.3-aliyun.1.

Pour des raisons de sécurité, le contrôleur NGINX Ingress désactive toutes les annotations snippet par défaut à partir de la v1.9.3-aliyun.1, notamment :

• 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

En raison des risques de sécurité et de stabilité, privilégiez d'autres annotations ou options de configuration.

Pour utiliser des annotations snippet, ajoutez allow-snippet-annotations: "true" au ConfigMap kube-system/nginx-configuration après avoir pleinement évalué les risques.

Les anciennes versions de TLS ne sont pas prises en charge

Versions concernées : Versions antérieures à v1.7.0-aliyun.1.

En raison de problèmes de sécurité dans TLS 1.1 et versions antérieures, les nouvelles versions de NGINX Ingress ne prennent plus en charge TLS v1.1 et TLS v1.0 par défaut. Avant la mise à niveau, vérifiez que vos services ne reposent pas sur TLS v1.1 ou une version antérieure et retirez-les de votre configuration. Les modifications du ConfigMap prennent effet immédiatement.

Par exemple, si le ConfigMap (kube-system/nginx-configuration) du contrôleur NGINX Ingress est configuré comme suit :

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

Après avoir confirmé que vos services ne sont pas affectés, supprimez cette ligne pour utiliser les valeurs par défaut, ou retirez SSLv3, SSLv2, TLSv1 et TLSv1.1 et modifiez la ligne comme suit :

ssl-protocols: TLSv1.2 TLSv1.3

Pour appliquer d'anciennes méthodes de chiffrement TLS, consultez Quelles versions SSL/TLS sont prises en charge par les Ingresses ?.

Utilisation incompatible de nginx.ingress.kubernetes.io/rewrite-target

Versions concernées : Versions antérieures à 0.22.0.

• La version 0.22.0 a modifié l'utilisation de l'annotation nginx.ingress.kubernetes.io/rewrite-target . Dans les versions 0.22.0 et ultérieures, vous devez spécifier explicitement les groupes de capture lorsque vous utilisez rewrite-target.

• Le comportement de rewrite-target avant la version 0.22.0 est incompatible avec les versions actuelles. Avant la mise à niveau, utilisez l'annotation configuration-snippet au lieu 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

Vérifier l'état du composant et des services

Outre vos propres outils de surveillance, ACK fournit les journaux Simple Log Service, les tableaux de bord Managed Service for Prometheus et les journaux natifs des conteneurs pour surveiller NGINX Ingress. Pour les activer, consultez Collecter et analyser les journaux d'accès NGINX Ingress et Se connecter et configurer Managed Service for Prometheus.

Puis-je mettre à niveau le contrôleur NGINX Ingress vers une version spécifique ? Puis-je revenir à une version précédente après une mise à niveau réussie ?

Le contrôleur NGINX Ingress ne prend pas en charge la mise à niveau vers une version spécifique. Les mises à niveau s'effectuent par étapes vers la dernière version. Vous ne pouvez pas revenir en arrière après une mise à niveau réussie.

Que faire si un Pod ne parvient pas à être créé pendant la phase de vérification ou de déploiement ?

Que faire si la vérification du modèle de Deployment échoue ?

Si le modèle de Deployment échoue à la vérification préalable, cliquez sur le lien à côté de Cause of Error pour ouvrir la page des différences de composants et afficher les champs ayant échoué.

1. Sur la page NGINX Ingress Controller Upgrade, sous Precheck, cliquez sur View Details.

2. Sur la page Check Report, dans la section Cluster Component Check Results, cliquez pour afficher les résultats de la vérification. Ensuite, sur la page Check Result, cliquez sur Deployment Template, puis enfin sur le lien à côté de Cause of Error.

3. Accédez à la page Component Differences pour afficher les champs ayant échoué à la vérification.

   La page des différences de composants compare le modèle standard pour cette version (à gauche) avec le modèle actuel du cluster (à droite), en mettant en évidence les différences compatibles et incompatibles. Elle indique également si le composant du cluster a réussi la vérification des différences et répertorie les chemins de champs incompatibles.

4. Modifiez le champ différent.

   Choisissez Workloads > Deployments, trouvez le composant NGINX Ingress controller, et choisissez More > View YAML. Sur la page Edit YAML, changez --v=3 en --v=2 dans le champ args.

5. Après avoir modifié le champ, actualisez la page des différences de composants. Lorsque la page affiche The component can pass the difference check, la vérification du modèle de Deployment réussira.

   Remarque

   La modification du Deployment du cluster redémarre les Pods NGINX Ingress. Effectuez cette opération pendant les heures creuses.