Container Service for Kubernetes:NGINX Ingress コントローラーのアップグレード

デフォルトセキュリティ設定の変更

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

v1.12.6-release.1 以降、ingress-nginx はデフォルトのセキュリティ設定を強化しました。以下が含まれます。

• annotations-risk-level のデフォルトレベルが Critical から High に引き下げられました。この変更により、Critical レベルのアノテーション (snippet 関連のアノテーションなど) を持つ既存の Ingress リソースが使用できなくなります。

• allow-cross-namespace-resources が true から false に変更されました。この設定により、ConfigMap や Secrets などのリソースのクロス名前空間参照がデフォルトで無効になります。

• strict-validate-path-type が false から true に変更されました。この設定により、厳密なパス検証がデフォルトで有効になります。これは、Exact および Prefix タイプのパスの場合、/ で始まり、文字、数字、-、_、.、および追加の / のみを含むパスのみが許可されることを意味します。

これらのセキュリティ設定によってブロックされる機能を使用する場合は、セキュリティリスクを評価した後、ConfigMap kube-system/nginx-configuration で手動で有効にしてください。

ネイティブ NGINX 検証がデフォルトで無効

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

CVE-2023-1974 を修正するため、NGINX Ingress コントローラーは v1.11.5-aliyun.1 以降、デフォルトでネイティブ NGINX 検証 (nginx -t ロジック) を無効にします。検証 Webhook は有効のままですが、スニペットベースのルールは検証されません。デフォルトでは、非スニペットアノテーションのみが検証されます。スニペットルールについては、NGINX ランタイムエラーログを確認してください。詳細については、「脆弱性 CVE-2023-1097、CVE-2023-1098、CVE-2023-1974、CVE-2023-24513、CVE-2023-24514 のアナウンス」を参照してください。

スニペットアノテーションを使用する場合は、対応する Ingress ルールを変更するたびに、NGINX Ingress Pod ログで Error 関連のエントリを確認してください。

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

ネイティブ NGINX 検証を再度有効にするには、リスクを十分に評価した後、ConfigMap kube-system/nginx-configuration に enable-nginx-native-validation: "true" を追加してください。

スニペットアノテーションがデフォルトで無効

影響を受けるバージョン：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

セキュリティと安定性のリスクがあるため、代替アノテーションまたは設定オプションを優先してください。

スニペットアノテーションを使用するには、リスクを十分に評価した後、ConfigMap kube-system/nginx-configuration に allow-snippet-annotations: "true" を追加してください。

レガシー TLS バージョンのサポート終了

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

TLS 1.1 以前のセキュリティ問題のため、新しい NGINX Ingress バージョンではデフォルトで TLS v1.1 および TLS v1.0 をサポートしなくなりました。アップグレード前に、サービスが TLS v1.1 以前に依存していないことを確認し、設定から削除してください。ConfigMap の変更は即座に有効になります。

たとえば、NGINX Ingress コントローラーの ConfigMap (kube-system/nginx-configuration) が次のように設定されている場合:

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

サービスが影響を受けないことを確認した後、この行を削除してデフォルトを使用するか、SSLv3、SSLv2、TLSv1、TLSv1.1 を削除して次のように変更してください。

ssl-protocols: TLSv1.2 TLSv1.3

古い TLS 暗号化方式を強制するには、「Ingress ではどの SSL/TLS バージョンがサポートされていますか?」を参照してください。

nginx.ingress.kubernetes.io/rewrite-target の互換性のない使用方法

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

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

• 0.22.0 より前の rewrite-target の動作は、現在のバージョンと互換性がありません。アップグレード前に、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 は path フィールドのパスです (末尾のスラッシュなし)。
    # 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

  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

コンポーネントとサービスのステータスの確認

独自の監視ツールに加えて、ACK は NGINX Ingress を監視するために Simple Log Service ログ、Managed Service for Prometheus ダッシュボード、およびネイティブコンテナログを提供します。これらを有効にするには、「NGINX Ingress アクセスログの収集と分析」および「Managed Service for Prometheus への接続と設定」を参照してください。

NGINX Ingress コントローラーを特定のバージョンにアップグレードできますか? アップグレード成功後に以前のバージョンにロールバックできますか?

NGINX Ingress コントローラーは特定のバージョンへのアップグレードをサポートしていません。アップグレードは段階的に最新バージョンに進みます。アップグレード成功後にロールバックすることはできません。

検証フェーズまたはリリースフェーズ中に Pod の作成に失敗した場合はどうすればよいですか?

Deployment テンプレートのチェックが失敗した場合はどうすればよいですか?

デプロイテンプレートが事前チェックに失敗した場合、異常の原因 の横にあるリンクをクリックして、コンポーネント差分ページを開き、失敗したフィールドを表示します。

1. NGINX Ingress Controller のアップグレード ページで、事前チェック の下にある 詳細情報 をクリックします。

2. [チェックレポート] ページの [クラスターコンポーネントのチェック結果] セクションで、チェック結果をクリックします。次に、チェック結果 ページで [デプロイメントテンプレート] をクリックし、最後に 異常の原因 の横にあるリンクをクリックします。

3. [コンポーネントの差分] ページに移動して、チェックに失敗したフィールドを表示します。

   コンポーネントの差分ページでは、このバージョンの標準テンプレート (左側) と現在のクラスターテンプレート (右側) を比較し、互換性のある差分と互換性のない差分を強調表示します。また、クラスターコンポーネントが差分チェックに合格したかどうかを示し、互換性のないフィールドパスをリストします。

4. 異なるフィールドを変更します。

   ワークロード > デプロイメント を選択し、[NGINX Ingress コントローラー] コンポーネントを見つけ、詳細 > YAML の表示 を選択します。YAML の編集 ページで、args フィールドの --v=3 を --v=2 に変更します。

5. フィールドを変更した後、コンポーネントの差分ページを更新してください。ページに [コンポーネントは差分チェックに合格できます] と表示されたら、Deployment テンプレートのチェックは合格します。

   説明

   クラスター Deployment を変更すると、NGINX Ingress Pod が再起動します。オフピーク時に実行してください。