1.2. Service Mesh リリースノート

この機能強化により、アノテーションのコピーに加えて、OpenShift ルートの特定のラベルをコピーできます。Red Hat OpenShift Service Mesh は、Istio Gateway リソースに存在するすべてのラベルとアノテーション (kubectl.kubernetes.io で始まるアノテーションを除く) を管理対象の OpenShift Route リソースにコピーします。

このリリースでは、WasmPlugin API のサポートが追加され、ServiceMeshExtentionAPI が廃止されました。

このリリースでは、マルチクラスターフェデレーションを含む Red Hat OpenShift on AWS(ROSA) のサービスメッシュサポートが導入されています。

このリリースでは、istio-node DaemonSet の名前が istio-cni-node に変更され、アップストリーム Istio の名前と同じになりました。

Istio 1.10 は、デフォルトで lo ではなく eth0 を使用してトラフィックをアプリケーションコンテナーに送信するように Envoy を更新しました。

このリリースは、すべてのプラットフォームでの Service Mesh 1.1 に基づく Service Mesh コントロールプレーンのサポートの終了を示します。

Service Mesh 2.2 は Istio 1.12 に基づいており、新機能と製品の機能強化をもたらします。多くの Istio 1.12 機能がサポートされていますが、サポートされていない次の機能に注意する必要があります。

Kubernetes Gateway API は、デフォルトで無効になっているテクノロジープレビュー機能です。

この機能を有効にするには、ServiceMeshControlPlane で Istiod コンテナーに次の環境変数を設定します。

spec:
  runtime:
    components:
      pilot:
        container:
          env:
            PILOT_ENABLE_GATEWAY_API: true
            PILOT_ENABLE_GATEWAY_API_STATUS: true
            # and optionally, for the deployment controller
            PILOT_ENABLE_GATEWAY_API_DEPLOYMENT_CONTROLLER: true

ゲートウェイ API リスナーでのルート接続を制限するには、SameNamespace または All 設定を使用します。Istio は、listeners.allowedRoutes.namespaces のラベルセレクターの使用を無視し、デフォルトの動作 (SameNamespace) に戻します。

Red Hat OpenShift Service Mesh は、Service Mesh コントロールプレーンおよびアプリケーションネームスペースで多数の NetworkPolicies リソースを自動的に作成し、管理します。これは、アプリケーションとコントロールプレーンが相互に通信できるようにするために使用されます。

NetworkPolicies リソースの自動作成および管理を無効にする場合 (例: 会社のセキュリティーポリシーを適用する場合など) には、これを実行できます。ServiceMeshControlPlane を編集して spec.security.manageNetworkPolicy 設定を falseに設定できます。

サービスメッシュをフェデレーションできるように新規のカスタムリソース定義 (CRD) が追加されました。サービスメッシュは、同じクラスター内または異なる OpenShift クラスター間でフェデレーションすることができます。これらの新規リソースには以下が含まれます。

Service Mesh Federation は、Red Hat OpenShift Service on AWS (ROSA)、Azure Red Hat OpenShift (ARO)、または OpenShift Dedicated (OSD) のクラスター間ではサポートされていません。

OVN-Kubernetes Container Network Interface(CNI) は、以前は Red Hat OpenShift Service Mesh 2.0.1 のテクノロジープレビュー機能として導入されましたが、OpenShift Container Platform 4.7.32、OpenShift Container Platform 4.8.12、および OpenShift Container Platform 4.9 で使用できるように Red Hat OpenShift Service Mesh 2.1 および 2.0.x で一般提供されています。

ServiceMeshExtensions カスタムリソース定義 (CRD) は、最初に 2.0 でテクノロジープレビュー機能として導入され、今回のバージョンで一般公開されました。CRD を使用して独自のプラグインを構築できますが、Red Hat では独自に作成したプラグインはサポートしていません。

Mixer はサービスメッシュ 2.1 で完全に削除されました。Mixer が有効な場合は、Service Mesh 2.0.x リリースから 2.1 へのアップグレードは、ブロックされます。Mixer プラグインは WebAssembly 拡張に移植する必要があります。

Mixer が正式に削除されたため、OpenShift 3scale mixer アダプターは、Service Mesh 2.1 ではサポート対象外となっています。Service Mesh 2.1 にアップグレードする前に、Mixer ベースの 3scale アダプターと追加の Mixer プラグインを削除します。次に、ServiceMeshExtension リソースを使用して、新しい 3scale WebAssembly アダプターを Service Mesh 2.1+ で手動でインストールして設定します。

3scale 2.11 では、WebAssembly に基づく更新された Service Mesh の統合が導入されました。

Service Mesh 2.1 は Istio 1.9 をベースとしており、製品の新機能および機能拡張が数多く追加されました。Istio 1.9 の大半の機能がサポートされていますが、以下の例外に注意してください。

各 ServiceMeshControlPlane の調整の終了時に以前のリソースのプルーニングに使用する期間が短縮されました。これにより、ServiceMeshControlPlane のデプロイメントにかかる時間が短縮され、既存の SMCP に適用される変更がこれまでよりも早く有効になります。

Kiali 1.36 には、以下の機能と拡張機能が含まれています。

Red Hat OpenShift Service Mesh には、リモートで悪用可能な脆弱性 CVE-2021-39156 が含まれており、URI パスにフラグメント (URI の末尾が # 文字で始まるセクション) を含む HTTP リクエストが Istio URI パスベースの認証ポリシーを無視する可能性があります。たとえば、Istio 認証ポリシーは URI パス /user/profile に送信される要求を拒否します。脆弱なバージョンでは、URI パス /user/profile#section1 のリクエストは、deny ポリシーと、(正規化された URI path /user/profile%23section1 を使用する) バックエンドへのルートを無視するため、セキュリティーのインシデントにつながる可能性があります。

DENY アクションおよび operation.paths、または ALLOW アクションおよび operation.notPaths で認可ポリシーを使用する場合は、この脆弱性の影響を受けます。

軽減策により、リクエストの URI の断片部分が、承認とルーティングの前に削除されます。これにより、URI のフラグメントを持つ要求が、フラグメントの一部のない URI をベースとする承認ポリシーが無視できなくなります。

軽減策の新しい動作からオプトインするには、URI の fragment セクションが保持されます。ServiceMeshControlPlane を設定して URI フラグメントを保持することができます。

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  techPreview:
    meshConfig:
      defaultConfig:
        proxyMetadata: HTTP_STRIP_FRAGMENT_FROM_PATH_UNSAFE_IF_DISABLED: "false"

Istio はホスト名自体とすべての一致するポートの両方にホスト名を生成します。たとえば、httpbin.foo のホストの仮想サービスまたはゲートウェイは、httpbin.foo and httpbin.foo:*に一致する設定を生成します。ただし、完全一致許可ポリシーは、hosts または notHosts フィールドに指定された完全一致文字列にのみ一致します。

ルールの正確な文字列比較を使用して hosts または notHosts を決定する AuthorizationPolicy リソースがある場合、クラスターは影響を受けます。

完全一致ではなく接頭辞一致を使用するように、認証ポリシー ルール を更新する必要があります。たとえば、最初の AuthorizationPolicy の例で hosts: ["httpbin.com"] を hosts: ["httpbin.com:*"] に置き換えます。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        namespaces: ["dev"]
    to:
    - operation:
        hosts: [“httpbin.com”,"httpbin.com:*"]

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: default
spec:
  action: DENY
  rules:
  - to:
    - operation:
        hosts: ["httpbin.example.com:*"]

Istio にはリモートで悪用可能な脆弱性があり、複数のスラッシュまたはエスケープされたスラッシュ文字 (%2F または %5C) を持つ HTTP リクエストパスが、パスベースの認証ルールが使用される場合に Istio 認証ポリシーを無視する可能性があります。

たとえば、Istio クラスター管理者が、パス /admin での要求を拒否する認証 DENY ポリシーを定義すると仮定します。URL パス //admin に送信される要求は、認証ポリシーによって拒否されません。

RFC 3986 に応じて、複数のスラッシュを持つパス //admin は、/admin とは異なるパスとして処理される必要があります。ただし、一部のバックエンドサービスは、複数のスラッシュを単一のスラッシュにマージして URL パスを正規化することを選択します。これにより、認証ポリシーがバイパスされ (//admin は /admin に一致しません)、ユーザーはバックエンドのパス (/admin) でリソースにアクセスできます。これにより、セキュリティーのインシデントを示されます。

ALLOW action + notPaths フィールドまたは DENY action + paths field パターンを使用する認証ポリシーがある場合、クラスターはこの脆弱性の影響を受けます。これらのパターンは、予期しないポリシーのバイパスに対して脆弱です。

以下の場合、クラスターはこの脆弱性の影響を受けません。

Istio 認証ポリシーは、HTTP リクエストの URL パスをベースとする場合があります。URI の正規化として知られる パスの正規化 は、正規化されたパスを標準の方法で処理できるように、受信要求のパスを変更し、標準化します。構文の異なるパスは、パスの正規化後と同一になる場合があります。

Istio は、認証ポリシーに対して評価し、要求をルーティングする前の、要求パスでの以下の正規化スキームをサポートします。

正規化アルゴリズムは以下の順序で実行されます。

Envoy がバックエンドサービスの期待値に一致するように要求パスを正規化することは、システムのセキュリティーを保護する上で非常に重要です。以下の例は、システムを設定するための参考として使用できます。正規化された URL パス、または NONE が選択されている場合は元の URL パスは以下のようになります。

Red Hat OpenShift Service Mesh のパスの正規化を設定するには、ServiceMeshControlPlane で以下を指定します。設定例を使用すると、システムの設定を判断するのに役立ちます。

spec:
  techPreview:
    global:
      pathNormalization: <option>

環境によっては、大文字と小文字を区別しない場合の比較用に 2 つのパスを認証ポリシーに用意すると便利な場合があります。たとえば、https://myurl/get と https://myurl/GeT を同等なものとして扱います。このような場合には、以下に示されている EnvoyFilter を使用できます。このフィルターは、比較用に使用されるパスとアプリケーションに表示されるパスの両方を変更します。この例では、istio-system が Service Mesh コントロールプレーンプロジェクトの名前です。

EnvoyFilter をファイルに保存して、以下のコマンドを実行します。

$ oc create -f <myEnvoyFilterFile>

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: ingress-case-insensitive
  namespace: istio-system
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
            subFilter:
              name: "envoy.filters.http.router"
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.lua
        typed_config:
            "@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua"
            inlineCode: |
              function envoy_on_request(request_handle)
                local path = request_handle:headers():get(":path")
                request_handle:headers():replace(":path", string.lower(path))
              end