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

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

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

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

• annotations-risk-level のデフォルトレベルが Critical から High に引き下げられました。この変更により、snippet 関連のアノテーションなど、Critical レベルのアノテーションを持つ既存の 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 v1.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 は Simple Log Service のログ、Managed Service for Prometheus のダッシュボード、およびネイティブコンテナーログを提供して NGINX Ingress を監視します。これらを有効にするには、「NGINX Ingress アクセスログの収集と分析」および「Managed Service for Prometheus への接続と設定」をご参照ください。

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

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

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

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

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

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

2. [チェックレポート] ページの [クラスターコンポーネントのチェック結果] セクションで、① の赤いボックスをクリックしてチェック結果を表示します。次に、チェック結果 ページで [Deployment テンプレート] をクリックし、最後に ② の 異常の原因 の横にあるリンクをクリックします。

   

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

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

   以下の例では、異なるフィールドは .spec.template.spec.containers.(nginx-ingress-controller).args です (括弧は配列要素名を示します)。比較から、args の --v=2 が --v=3 に変更されており、アップグレード前に修正する必要があることがわかります。

   

4. 異なるフィールドを変更してください。

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

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

   説明

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