OKEがZero Trust Packet Routing (ZPR)をサポートすることを発表

※ 本記事は、Kay Singhによる”Announcing OKE support for Zero Trust Packet Routing (ZPR)“を翻訳したものです。

2026年8月18日

新機能

OCI Kubernetes Engineは、サポートされているクラスタ関連のOCIリソースに対してZero Trust Packet Routing (ZPR)をサポートするようになりました。このサポートにより、チームはこれらのリソースにZPRセキュリティ属性を割り当て、承認済みの通信パスを定義するZPRポリシーを作成できます。

ZPRとは?

Zero Trust Packet Routingは、OCIリソース向けのインテントベースのネットワーク・セキュリティ・モデルです。セキュリティ属性(サポートされているリソースに割り当てられたラベル)から開始します。ZPRポリシーは、これらの属性を参照して、ソースと宛先の間で許可されるパスを定義および適用します。ポリシーでは、そのパスをIPアドレス、サブネットまたはルート・シェイプのみで記述するのではなく、アプリケーション層がストレージ層に到達するなど、それらのリソースが果たすロールによって記述できます。たとえば、ポリシーは目的のパスを直接表すことができます:

in network:backend-vcn VCN allow app:orders-api endpoints to connect to storage:orders-fss endpoints

なぜZPR?

重要な考え方は分離です。多くのクラウド・ネットワークでは、同じ構成に到達可能性とセキュリティ意図という2つの懸念事項が含まれます。ネットワーク・オペレータは、トラフィックが流れるように、ルート、サブネット、NSGおよびセキュリティ・リストを管理します。セキュリティ・オペレータは、通信を許可するリソースを指定する必要があります。その意図がIPアドレス、CIDR範囲、およびネットワーク形状のみで表現されている場合、ネットワークの変更によって承認済みパスのレビューが困難になり、ネットワーク・パスに意図しない脆弱性が生じ、高額なネットワーク侵害につながる可能性があります。ZPRにより、セキュリティ運用チームはアプリケーション、環境、データ・ロールなどの属性を使用してその意図の一部を表現できるため、基盤となるネットワークが変更されても、ポリシーは意図されたパスに結び付いたままになります。

ZPRは既存のネットワーク制御を置き換えるものではありません。ルート・ルール、NSGおよびセキュリティ・リストは、ネットワークがトラフィックを伝送できるかどうかを引き続き決定します。ZPRは、属性リソースに対する属性ベースのポリシー決定を追加します。トラフィックにこれらのリソースの1つが含まれる場合、ネットワーク制御は到達可能性を許可し、ZPRポリシーは属性ソースと宛先を許可する必要があります。同じノード上のPod間トラフィックの場合、Kubernetes NetworkPolicyはPodレベルの制御のままです。

一般的なZPRモデルとその設計上の動機の詳細な説明については、「First Principles(第一原則): Zero Trust Packet Routingによる強力なデータ侵害保護」を参照してください。

これがKubernetesチームにとって重要な理由

OKEクラスタは、重要なアクセス・パスに配置されているOCIリソースに依存します。PodはノードVNICを介してトラフィックを送信し、クライアントはロード・バランサまたはイングレス・ロード・バランサを介してアプリケーションに到達し、管理者はKubernetes APIエンドポイントに接続し、ワークロードはFile Storageマウント・ターゲットを使用できます。Kubernetesチームは、VCN設計、ルート、NSG、セキュリティ・リスト、IAM、Kubernetes RBACおよびKubernetes NetworkPolicyを使用して、これらのリソースへのアクセスを制御できます。ZPRはこれらの管理策に取って代わるものではありません。クラスタで使用されるサポート対象のOCIリソースに対する個別のチェックが追加されるため、ネットワーク到達性の偶発的な変更が自動的にアクセス可能な状態につながることはありません。

リソースにZPRセキュリティー属性がある場合、ネットワークの到達可能性は十分ではありません。トラフィックは、ソースと宛先の関係を許可するZPRポリシーとも一致する必要があります。たとえば、セキュリティ・オペレータは、Orders APIのPodトラフィックがOrdersデータのFile Storageマウント・ターゲットに到達することを許可できます。その他の到達可能パスは、ZPRポリシーで明示的に許可されないかぎりブロックされたままです。

たとえば、セキュリティ・オペレータは、Orders APIのPodトラフィックがOrdersデータのFile Storageマウント・ターゲットに到達することや、イングレス・ロード・バランサが特定のアプリケーション・パスのトラフィックを受信することを定義できます。ルート・ルール、NSGおよびセキュリティ・リストは、引き続きネットワークの到達可能性を管理します。Kubernetes NetworkPolicyは、クラスタ内のPod間コントロールに引き続き使用できます。

ZPRビジュアライザは、セキュリティ属性、リソースおよびポリシーがグラフ・ビューでどのように接続されるかを示します。

ZPRの適用場所

OKEとともに使用する場合、ZPRは以下に示すサポート対象のOCIリソースに適用されます。各リソース・タイプには、セキュリティ属性用の独自のアタッチメント・ポイントがあります。

例: File StorageへのPodトラフィック

正確なセキュリティ属性名は、顧客のセキュリティ・モデルによって異なります。この例では、1つのOKEアプリケーション・パス(Orders APIからFile Storageマウント・ターゲットへのPodトラフィック)を使用します。

セキュリティ・オペレータは、承認されたパスをアプリケーション関係として表現できます。Orders API PodトラフィックはOrders File Storageに到達できます。ネットワーク・オペレータは、ネットワーク到達性を提供するルート、NSGおよびセキュリティ・リストのルールを維持します。OKEは、Podトラフィックに使用される管理対象ノードのセカンダリVNICにソース属性を適用し、CSIボリューム・プラグインはFile Storageマウント・ターゲットに宛先属性を適用します。

• ソース: app:orders-api
• 宛先: storage:orders-fss
• ポリシー・インテント: Orders API PodトラフィックがOrders File Storageに到達することを許可

ZPRポリシーの作成

既存のOKE関連リソースにセキュリティ属性を適用する前に、ZPRポリシーを作成します。このポリシーにより、app:orders-api ZPRセキュリティ属性を使用したPodトラフィックは、storage:orders-fss ZPRセキュリティ属性を使用してFile Storageマウント・ターゲットに接続できます。

in network:backend-vcn VCN allow app:orders-api endpoints to connect to storage:orders-fss endpoints

ソースZPRセキュリティ属性の適用: 管理対象ノードのセカンダリVNIC

管理対象ノード・プールの場合は、Podトラフィック・ソースとして使用されるセカンダリVNICにapp:orders-api ZPRセキュリティ属性を割り当てます(次に示す管理対象ノード・プール構成を使用)。異なるZPRセキュリティ属性を必要とするPodが異なるノード・プールで実行されるように、ワークロードの配置を計画します。

セキュリティ属性を割り当てると、チームはZPRポリシー評価に参加する必要があるOKE関連のVNICリソースを選択できます。

[
  {
    "displayName": "orders-api-pod-vnic",
    "nicIndex": 0,
    "createVnicDetails": {
      "subnetId": "<pod-subnet-ocid>",
      "nsgIds": ["<pod-nsg-ocid>"],
      "securityAttributes": {
        "app": {                    # ZPR security attribute namespace
          "workload": {             # ZPR security attribute key
            "value": "orders-api",  # ZPR security attribute value
            "mode": "enforce"       # Applies the attribute for ZPR policy evaluation
          }
        }
      }
    }
  }
]

oci ce node-pool update \ --node-pool-id <node-pool-ocid> \ --secondary-vnics file://secondary-vnics.json

管理対象ノード・プールのセキュリティ属性を更新すると、変更は新しいワーカー・ノードに適用されます。既存のワークロードで更新されたVNICセキュリティ属性が必要な場合は、既存のワーカー・ノードを置換します。

宛先ZPRセキュリティ属性の適用: File Storageマウント・ターゲット

File Storageの場合は、CSIボリューム・プラグインで使用されるStorageClassにsecurityAttributesパラメータを追加します。CSIボリューム・プラグインは、永続ボリューム要求のマウント・ターゲットを作成するときに属性を適用します。

この例のインライン・コメントは、securityAttributes値の各部分を示しています。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fss-secure
provisioner: <file-storage-csi-provisioner>
parameters:
  mountTargetSubnetOcid: ocid1.subnet.oc1..example
  securityAttributes: >-
    {
      "storage": {                # ZPR security attribute namespace
        "dataset": {              # ZPR security attribute key
          "value": "orders-fss",  # ZPR security attribute value
          "mode": "enforce"       # Applies the attribute for ZPR policy evaluation
        }
      }
    }

StorageClassパラメータは、File Storageリソースの作成時に適用されます。後でStorageClassを変更または再作成しても、CSIボリューム・プラグインがすでに作成したマウント・ターゲットは更新されません。

はじめに

ZPRはオプションです。機密性の高いワークロード、監査ドリブンな環境、プラットフォーム、ネットワーク、セキュリティ・チーム間で共有されるパスなど、より明確なコミュニケーション・ルールが最も重要であるクラスタまたはアプリケーション・パスから開始します。最初の有効範囲は、1つのクラスタ、1つのノード・プール、または明確なトラフィック要件とロールバック計画を持つ1つのアプリケーション・パスです。

クラスタがスコープ内にあることの確認

ZPRセキュリティ属性を割り当てる前に、この表をプリフライト・チェックとして使用します。スコープ内にあるOKE構成と、別の制御計画が必要なOKE構成を分離します。

属性を適用する前に、クラスタ・バージョン、Podネットワーキング・モード、セキュリティ属性ネームスペース、ZPRポリシーおよびIAM権限を確認します。クラスタがPodネットワーキングにflannelを使用する場合、この投稿で説明されているPodネットワーキング・パスではZPRセキュリティ属性はサポートされません。ワークロードに異なるZPRセキュリティ・プロファイルが必要な場合は、ノード・プールの VNIC属性を割り当てる前に、ノード・プール間の配置を計画してください。

ZPRが既存のコントロールにどのように適合するかの理解

ZPR属性が付与されたOKEリソースの場合、接続性は階層的に判定されます。

トラフィックは、既存のネットワーク・ルールおよび一致するZPRポリシーを満たす必要があります。ルート・ルール、NSG、またはセキュリティ・リストが経路をブロックしている場合、ZPRポリシーによってその経路が開放されることはありません。既存のネットワーク・ルールでパスが許可されていても、属性付きエンドポイントに一致するZPRポリシーが存在しない場合、ZPRはそのトラフィックをブロックします。

ポリシー詳細ビューは、属性リソース間の通信を許可するポリシー・ステートメントを表示するのに役立ちます。

Network Path Analyzerは、チームがこの階層化された意思決定を検査するのに役立ちます。ZPR統合により、選択したパスについて、ルーティング、NSG、セキュリティ・リストおよびZPRポリシーの評価を表示できます。これにより、以下に示すように、ルートの欠落、ブロックされたNSGルール、ZPRポリシーの欠落、セキュリティ属性の欠落など、問題を適切なレイヤーに絞り込むことができます。

Kubernetes NetworkPolicyは、同一ノード内のクラスタ内部におけるPod間制御として引き続き機能します。ZPRは、ZPRセキュリティ属性を持つサポート対象のOCIリソースに対して、OCIネットワーク・ファブリック内でネットワーク・アクセス・ポリシーを適用します。

ロールアウトの計画

順序は重要です。既存のリソースに属性を適用する前に、必要なZPRポリシーを作成してテストします。リソースにZPRセキュリティ属性があり、必要なトラフィックを許可する適切なZPRポリシーがない場合、NSGまたはセキュリティ・リスト・ルールで許可されていても、そのエンドポイントへのトラフィックはブロックされます。

1. 稼働し続ける必要があるトラフィック・パスをマッピングします。管理者によるKubernetes APIエンドポイントへのアクセス、ノードおよびPodのトラフィック、サービス・ロード・バランサ、イングレス・ロード・バランサ、およびストレージ・パスを含めます。
2. 必要なセキュリティ属性ネームスペースおよびセキュリティ属性を作成します。
3. セキュリティ属性を割り当てる必要があるユーザーおよびOKEコンポーネントのIAM権限を準備します。
4. 既存のリソースに属性を適用する前に、ZPRポリシーを作成してください。
5. 限定されたパイロット・スコープに属性を適用します。
6. サポートされている場合は、Network Path Analyzerで想定されるパスを検証します。ロールアウト前に、必要なパスが許可されていることを確認するために使用し、トラブルシューティング時には、ルーティング、NSG、セキュリティ・リスト、ZPRポリシー、またはセキュリティ属性がパスをブロックしているかどうかを確認するために使用します。
7. パイロットが安定した後、より多くのノード・プール、サービス、イングレス・パス、ストレージを使用するワークロードおよびクラスタに拡張します。

遷移ポリシーの処理

移行中、一部の宛先にはまだZPRセキュリティ属性がない場合があります。そのような場合、ZPRポリシーにより、属性付きエンドポイントから、サポートされているIPアドレス、CIDRブロック、またはサービス・エンドポイント式へのトラフィックを許可できます。

in network:backend-vcn VCN allow app:orders-api endpoints to connect to '10.0.2.5/32'

移行用のIPベースのポリシーは範囲を限定してください。宛先リソースがZPRモデルに移行し、属性ベースのポリシーが設定された後で、それらを削除します。検証後、残りのネットワーク構成で必要な接続が可能であり、セキュリティ要件を満たしている場合、チームは広範な移行用NSGルールまたはセキュリティ・リスト・ルールを簡素化することもできます。

最終的な要点

ZPRのOKEサポートにより、お客様はKubernetesクラスタで使用されるサポート対象のOCIリソースに対して、承認済みの通信パスを定義できます。1つのマッピングされたパスから開始し、まずポリシーを記述し、属性を慎重に適用して、拡張する前に検証します。

はじめに

• OCI Kubernetes Engineの概要
• OKEクラスタ関連リソースへのセキュリティ属性の追加およびZPRポリシーの適用
• First Principles(第一原則): Zero Trust Packet Routingによる強力なデータ侵害保護
• OCI Zero Trust Packet Routingの概要
• OCI Zero Trust Packet Routingのベスト・プラクティス