Container Service for Kubernetes:NGINX Ingress コントローラーの更新

ネイティブ NGINX 検証チェックはデフォルトで無効になっています

影響を受けるバージョン： v1.11.5-aliyun.1 より前のバージョン

CVE-2025-1974 を修正するために、v1.11.5-aliyun.1 以降、NGINX Ingress コントローラーはデフォルトでネイティブ NGINX 構成検証（nginx -t ロジックと同等）を無効にします。コンポーネントの検証 Webhook は有効なままですが、スニペット アノテーションで定義された構成は検証されません。スニペット以外のアノテーションのみが検証されます。スニペット構成については、NGINX によって生成されたランタイム エラー ログを通じて有効性を検証する必要があります。脆弱性の詳細については、「脆弱性 CVE-2025-1097、CVE-2025-1098、CVE-2025-1974、CVE-2025-24513、および CVE-2025-24514 に関するセキュリティ アドバイザリ」をご参照ください。

スニペット アノテーションを使用する場合は、スニペットを変更するたびに次のコマンドを実行して、NGINX Ingress コントローラー ポッド ログで構成エラーを監視します。

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

ネイティブ NGINX 検証機能を保持するには、リスク評価を徹底的に行った後、enable-nginx-native-validation: "true" パラメーターを kube-system/nginx-configuration ConfigMap に手動で追加して有効にします。

スニペット アノテーションはデフォルトで許可されていません

影響を受けるバージョン： v1.9.3-aliyun.1 より前のバージョン。

セキュリティ上の理由から、NGINX Ingress コントローラー v1.9.3-aliyun.1 以降のバージョンでは、スニペット アノテーションは許可されていません。

• 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

セキュリティと安定性を確保するために、特定の機能を使用する場合は、スニペット アノテーションではなく、対応するアノテーションまたは設定を使用することをお勧めします。

スニペット アノテーションを使用する場合は、リスクを評価し、allow-snippet-annotations: "true" を kube-system/nginx-configuration ConfigMap に追加して、スニペット アノテーションを許可します。

以前の TLS バージョンとの非互換性

影響を受けるバージョン： v1.7.0-aliyun.1 より前のバージョン。

TLS 1.1 以前のバージョンにはセキュリティ上の問題があります。 NGINX Ingress コントローラーは、次の TLS バージョンをサポートしなくなりました： TLS 1.1 および TLS 1.0。 NGINX Ingress コントローラーを更新する前に、サービスが TLS 1.1 以前のバージョンに依存しておらず、TLS 1.1 以前のバージョンがサービスの TLS 設定から削除されていることを確認してください。 ConfigMap への変更はすぐに有効になります。

次の内容は、kube-system 名前空間の NGINX Ingress コントローラーの nginx-configuration ConfigMap の TLS 設定の例を示しています。

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

サービスが TLS 1.1 以前のバージョンに依存していないことを確認したら、この構成行を削除してデフォルトの TLS 設定を使用できます。また、TLS 設定から TLS 1.1、TLS 1.0、SSL 3.0、および SSL 2.0 を削除することもできます。例：

ssl-protocols: TLSv1.2 TLSv1.3

以前の TLS バージョンを使用する場合は、必要なドキュメントを参照して構成を完了してください。 詳細については、「Nginx Ingress FAQ」トピックの「Ingress でサポートされている SSL/TLS バージョンはどれですか？」セクションをご参照ください。

nginx.ingress.kubernetes.io/rewrite-target アノテーションに関連する非互換性の問題

影響を受けるバージョン： 0.22.0 より前のバージョン。

• NGINX Ingress コントローラー 0.22.0 では、nginx.ingress.kubernetes.io/rewrite-target アノテーションの使用方法が変更されています。 NGINX Ingress コントローラー 0.22.0 以降のバージョンでは、rewrite-target アノテーションを使用する場合、キャプチャ グループを明示的に指定する必要があります。

• 0.22.0 より前の NGINX Ingress コントローラー バージョンの rewrite-target アノテーションは、それ以降のバージョンの rewrite-target アノテーションと互換性がありません。 NGINX Ingress コントローラーを更新する前に、rewrite-target を configuration-snippet に置き換えてください。

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:
    # rewrite アノテーションを使用します。 /something は、末尾のスラッシュ（/）を除くパスを示します。
    # Ingress に複数のパスが含まれている場合は、同じ数の rewrite アノテーションを追加します。
    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/ # 以前のバージョンの Ingress のパスと同じ値を保持します。
        pathType: Prefix
        backend:
          service:
            name: http-svc
            port:
              number: 80
      - path: /something123/ # 以前のバージョンの Ingress のパスと同じ値を保持します。
        pathType: Prefix
        backend:
          service:
            name: http-svc-1
            port:
              number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    # 一致するコンテンツを参照します。
    nginx.ingress.kubernetes.io/rewrite-target: /$2
  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

NGINX Ingress コントローラーとワークロードの状態を確認する

ACK の監視機能に加えて、ACK では、Simple Log Service、Managed Service for Prometheus ダッシュボード、およびコンテナー ログを使用して NGINX Ingress コントローラーの状態を監視することもできます。上記のサービスをアクティブにするには、「nginx-ingress-controller のアクセスログの分析と監視」および「Managed Service for Prometheus の使用」をご参照ください。

既知の問題

プレフィックス マッチングの違いは、さまざまなバージョンの NGINX Ingress コントローラーに存在する可能性があり、サービス アクセスの問題につながる可能性があります。

• 0.44 より前のバージョンでは、プレフィックス マッチングルールは緩やかです。たとえば、プレフィックス /aaa/bbb は、リクエスト URL の /aaa/bbbbb と一致する可能性があります。

• 更新後、プレフィックス マッチングルールはより厳格になり、正確なリクエスト URL のみに一致します。上記の例では、リクエスト URL の /aaa/bbbbb は一致しません。代わりに、状態コード 404 が返されます。

影響範囲

v0.44 より前の NGINX Ingress コントローラーが影響を受けます。リリースノートの詳細については、「NGINX Ingress コントローラー」をご参照ください。関連するプルリクエスト情報については、「kubernetes/ingress-nginx #6443」を参照してください。

サンプル構成

次の YAML テンプレートを使用して、0.22.0.5-552e0db-aliyun（以前のバージョン）や 1.2.1-aliyun.1+（以降のバージョン）など、異なるバージョンの NGINX Ingress コントローラーによってレンダリングされた NGINX 構成を比較できます。

  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

• 以前のバージョン

  0.22.0.5-552e0db-aliyun などのバージョンでは、NGINX 構成は次のとおりです。

  Location /api/resource   # パスはスラッシュ（/）で終わりません。

  上記の構成では、パス /api/resource を使用すると、以前のバージョンの NGINX で http://www.example.com/api/resource からアクセスできます。

  説明

  実際のリクエスト パスは resources であり、resource ではありません。

• 以降のバージョン

  NGINX Ingress コントローラーが 1.2.1-aliyun.1+ などの以降のバージョンに更新されると、NGINX 構成は次のようになります。

  Location /api/resource/  # パスはスラッシュ（/）で終わります。
  {
  }
  ...
  Location = /api/resource  # 正確なマッチングのために別の場所が追加されます。
  {
  }

  http://www.example.com/api/resources にアクセスしようとすると、HTTP 状態コード 404 が返されます。

NGINX Ingress コントローラーを特定のバージョンに更新できますか？更新が成功した後、以前のバージョンにロールバックできますか？

NGINX Ingress コントローラーを特定のバージョンに更新することはできません。 NGINX Ingress コントローラーは段階的に更新され、最新バージョンにのみ更新できます。更新が完了すると、ロールバックできません。

検証フェーズとリリース フェーズでポッドの作成に失敗した場合はどうすればよいですか？

デプロイメント テンプレートがチェックに合格しない場合はどうすればよいですか？

デプロイメント テンプレートがチェックに合格しない場合は、[原因] の右側のハイパーリンクをクリックして、[コンポーネントの比較] ページに移動します。チェックに合格しなかったコンポーネント パラメーターを表示できます。

1. [NGINX Ingress コントローラーの更新] ページで、[事前チェック] の下の [詳細の表示] をクリックします。

2. [クラスタコンポーネントの結果] セクションの [レポート] ページで、① でマークされた赤いボックス内の結果をクリックします。[結果] タブで、[デプロイメントテンプレート] をクリックします。次に、② でマークされた [原因] の右側のハイパーリンクをクリックします。

   

3. [コンポーネントの比較] ページで、チェックに合格しなかったコンポーネント パラメーターを表示できます。

   [コンポーネントの比較] ページでは、標準コンポーネント テンプレートが左側に表示され、現在のコンポーネント テンプレートが右側に表示されます。 [コンポーネントの比較] ページには、互換性のあるパラメーターと互換性のないパラメーターを含むテンプレート間の違いが表示され、ページの下部に違いがリストされます。 [コンポーネントの比較] ページには、コンポーネントがチェックに合格したかどうかと、違いの原因となっているパラメーターも表示されます。

   次の図では、テンプレート間に相違点があり、その相違点の原因となっているパラメーターは .spec.template.spec.containers.(nginx-ingress-controller).args です。nginx-ingress-controller は、パラメーターが属するコンテナーの名前です。比較結果から、標準テンプレートの args パラメーターには --v=2 が指定されているのに対し、現在のテンプレートの args パラメーターには --v=3 が指定されていることがわかります。コンポーネントを更新する前に、args パラメーターを変更する必要があります。

   

4. 違いの原因となっているパラメーターを変更します。

   左側のナビゲーションウィンドウで、[ワークロード] > [デプロイメント] を選択します。[デプロイメント] ページで、NGINX Ingress コントローラーを見つけて、[アクション] 列の [詳細] > [YAML で表示] を選択します。[YAML の編集] ダイアログボックスで、args パラメーターの値を --v=3 から --v=2 に変更します。

5. args パラメーターを変更した後、[コンポーネントの比較] ページをリフレッシュして、差異が修正されたかどうかを確認できます。[コンポーネントの比較チェックに合格しました。] がページの下部に表示されている場合、デプロイメント テンプレートはチェックに合格しています。

   説明

   システムは、NGINX Ingress コントローラーのポッドを再起動して、デプロイメントへの変更を適用します。関連する操作は、オフピーク時に実行することをお勧めします。