• ポリシーを操作したり、既存のアプリケーション ワークスペースを表示したり、新しいワークスペースを作成したりするには、次の手順を実行します。

  ウィンドウの左側にあるナビゲーションバーから [防御（Defend）] > [セグメンテーション（Segmentation）] を選択します。

• 特定のワークスペースを表示するには、次の手順を実行します。

  [ワークスペース（Workspaces）] ページの左側にある範囲のリストで、ワークスペースに関連付けられている範囲に移動し、ワークスペースをクリックします。現在アクティブなワークスペースがリストで強調表示されます。

• ワークスペースを表示しているときに、ワークスペースのリストに戻るには、次の手順を実行します。

  表示しているページの左側付近にある [ワークスペース（Workspaces）] リンクをクリックします。

範囲のポリシーを作成するには、まずその範囲のワークスペースを作成します。

ワークスペースを作成するには、次の手順を実行します。

1. ナビゲーションメニューで、[防御（Defend）] > [セグメンテーション（Segmentation）] の順に選択します。

2. ページにある範囲のリストで、ポリシーを作成する範囲を検索するか、その範囲までスクロールします。

3. 範囲にカーソルを合わせ、青いプラス記号が表示されたらクリックします。

4. フォームに入力し、完了したら [作成（Create）] をクリックします。

範囲のワークスペースが存在する場合、追加のワークスペースがセカンダリワークスペースとして作成されます。

範囲ごとに、1 つのプライマリワークスペースと複数のセカンダリワークスペースを作成できます。

適用は、プライマリワークスペースのみで可能です。プライマリワークスペースでのみ使用できるその他の機能には、コンシューマとプロバイダーが異なる範囲に存在するポリシーを管理する機能、ライブポリシー分析、コンプライアンスレポート、およびコラボレーティブ セキュリティ ポリシー定義があります。

プライマリワークスペースの既存のポリシーを保持する場合は、セカンダリワークスペースを使用してポリシーを試します。

ワークスペースをプライマリまたはセカンダリに変更するには、次の手順を実行します。

ページ上部のワークスペース名の横にあるメニューアイコンをクリックし、[プライマリの切り替え（Toggle Primary）] を選択することで、いつでもワークスペースをプライマリからセカンダリに、またはその逆に切り替えることができます。

ワークスペース名を変更するには、次の手順を実行します。

ページの上部付近に表示されるワークスペースタイプ（[プライマリ（Primary）] または [セカンダリ（Secondary）]）の横にある をクリックし、[ワークスペースの更新（Update Workspace）] を選択します。

セカンダリ（プライマリではない）ワークスペースのみ削除できます。ワークスペースをセカンダリに切り替えるには、プライマリおよびセカンダリワークスペースを参照してください。

ワークスペースを削除するには、次の手順を実行します。

1. [防御（Defend）] > [セグメンテーション（Segmentation）] を選択します。

2. ページの左側にある範囲のリストで、削除するワークスペースが含まれている範囲に移動して、その範囲をクリックします。

3. 削除するワークスペースをクリックします。

4. [セカンダリ（Secondary）] の横にある をクリックし、[ワークスペースの削除（Delete Workspace）] を選択します。

   

ワークスペース内のワークロードまたはクラスタが、提供されるサービスの結果として別のワークスペース内のポリシーによって参照されている場合、依存ワークスペースは削除できず、依存関係のリストが返されます。この情報を使用して、依存関係を修正できます。

まれに、ワークスペース A がワークスペース B のクラスタに依存し、ワークスペース B がワークスペース A のクラスタに依存する相互依存関係が発生することがあります。この場合、個々のポリシーや公開されたポリシーバージョン（p*）を削除する必要があります。「削除制限」エラーでは、すべてのポリシーへのリンクが表示されるため、この削除を実行できます。

p* バージョンを削除するには、分析されたポリシーバージョンの表示、比較、および管理または適用されたポリシーバージョンの表示、比較、および管理を参照してください。

ポリシーテンプレートを使用して、同様のポリシーセットを複数のワークスペースに適用します。

Cisco Secure Workload には、いくつかの事前定義されたテンプレートが含まれています。また、独自のテンプレートを作成することもできます。

ポリシーテンプレートには、ルート範囲の範囲所有者機能が必要です。

自動ポリシー検出は、ポリシー検出とも呼ばれ、以前はアプリケーション依存関係マッピング（ADM）と呼ばれていました。自動ポリシー検出は既存のトラフィックフローとその他のデータを使用して、次の処理を実行します。

• 既存の正常に完了したネットワークアクティビティに基づいて、一連の「許可」ポリシーを提案します。

  これらのポリシーの目的は、組織が必要とするトラフィックを識別し、他のすべてのトラフィックをブロックすることです。

• コンピューティング動作の類似性に基づいて、ワークロードをクラスタにグループ化します。

  たとえば、アプリケーションに複数の Web サーバーが含まれている場合、それらは一緒にクラスタ化される可能性があります。

  詳細については、「クラスタ」を参照してください。

各範囲のポリシーを検出できます。通常、範囲のポリシーは、範囲ツリーの最下位付近（アプリケーションレベルなど）に表示されます。ただし、初期展開では、より上位の範囲でポリシーを検出することで、より改善されたポリシーを作成しながら、一般的で一時的なポリシーを使用することもできます。

必要に応じて何度でもポリシーを検出し、追加情報に基づいて推奨されるポリシーを改善することができます。

提案されたポリシーとクラスタの変更や承認を手動で行うことができます。これにより、ポリシーとクラスタは引き継がれ、後続のポリシー検出が実行されても変更されません。

手動で作成したポリシーと検出されたポリシーの両方を、ワークスペースに含めることができます。

ポリシーを検出したら、適用する前に確認および分析します。

ポリシーの検出を開始するには、ポリシーを自動的に検出する方法を参照してください。

詳細については、ポリシー検出の詳細を参照してください。

エージェントが各プラットフォームでポリシーを適用する方法に関する重要な詳細については、エージェントによるポリシーの適用を参照してください。Kubernetes/OpenShift については、コンテナへの適用を参照してください。

トラフィック処理は、次の影響を受けます。

• 範囲内のポリシーの優先順位、および

• ポリシーのグローバルな順序付けと競合の解決

ポリシーで指定されたコンシューマとプロバイダーによって、次のことが決まります。

• ポリシーを受信する Secure Workload エージェントを含む一連のワークロード。

• インストールされているファイアウォールルールの影響を受ける一連の IP アドレス。

デフォルトでは、これらは同じです。

ただし、ポリシーを受信するワークロードの IP アドレスとは異なる IP アドレスのグループを、ファイアウォールルールで指定する必要が生じることがあります（以下の例を参照してください）。

このニーズに対処するために、有効なコンシューマや有効なプロバイダーを設定できます。

例：有効なコンシューマまたは有効なプロバイダー

この例では、仮想 IP（VIP）の背後にある一連のワークロードのポリシーを設定します。これは、キープアライブや Windows フェールオーバー クラスタリング ソリューションと似ています。有効なコンシューマや有効なプロバイダーを使用して、フェールオーバーイベント中にトラフィックが中断されないようにします。

IP アドレス（172.21.95.5 および 172.21.95.7）を持ち、VIP - 6.6.6.6 の背後でサービスを提供する一連のワークロードについて考えてみます。この VIP はフローティング VIP であり、任意の時点で 1 つのワークロードのみが VIP を所有します。目標は、フリート内のすべてのワークロードでファイアウォールルールをプログラムし、6.6.6.6 へのトラフィックを許可することです。

このセットアップでは、フリートを表すワークロードのクラスタ（172.21.95.5 および 172.21.95.7）と VIP（6.6.6.6）を含む範囲と対応するワークスペースがあります。

以下に示すように、VIP は提供サービスとしてこのワークスペースで公開されます。

このサービスのクライアントからサービス VIP にポリシーを追加することにした場合、（デフォルトでは）VIP へのトラフィックを許可するファイアウォールルールは、VIP を所有するワークロードでのみプログラムされます。ただし、フェールオーバーイベントが発生すると、その後サービス VIP を所有する新しいワークロードが適切なファイアウォールルールを取得するまでに時間がかかり、トラフィックが短時間中断される場合があります。

この問題に対処するために、（以下の手順を使用して）有効なプロバイダーを設定します。具体的には、[有効なプロバイダー（Effective Provider）] の設定で、サービス VIP へのトラフィックを許可するファイアウォールルールのプログラミングが必要な一連のワークロードを指定します。これらのワークロードのいずれかが VIP を所有しているかどうかは関係ありません。

[有効なプロバイダー（Effective Provider）] が設定されている場合、ワークロードが VIP を所有していない場合でも、6.6.6.6 へのトラフィックを許可するファイアウォールルールがワークロード上でプログラムされていることを確認できます。サービスをサポートするすべてのワークロードをこれらのルールでプログラムする場合、新しいプライマリワークロード（VIP を所有）には必要なファイアウォールルールがプログラムされるため、フェールオーバーイベント中にトラフィックが中断されることはありません。

ワークスペースの [適用（Enforcement）] ページから単一のワークスペースにポリシーを適用する場合、ポリシー適用ウィザードでは次のことができます。

• ワークロードに導入する前にポリシーを確認する。

  これには、先祖範囲から継承されたポリシーが含まれます。

• 確認のためにポリシーの変更をダウンロードする。

• ポリシーバージョンを比較する。

• 適用するワークスペースの分析されたバージョンを選択する。

• 以前のバージョンにポリシーをロールバックする。

ポリシー適用ウィザードのステップ：

1. ポリシー更新の選択

   ワークロードに適用するポリシーのバージョンを選択でき、

   現在適用されているポリシーと選択したバージョンのポリシーの違いが表示されます。

   「ポリシーの差分」と同様に、ポリシーの変更をフィルタして確認し、CSV としてダウンロードすることができます。

2. 影響を受けるワークロード

   このステップでは、選択したポリシーの変更から生成された新しいファイアウォールルールの影響を受けるワークロードが表示されます。結果は、選択したポリシー変更のコンシューマまたはプロバイダーの結合内に適用エージェントが存在するすべてのワークロードを検索した結果です。

   影響を受ける可能性のあるワークロードの数は、範囲内のワークロードの総数を超えることはありませんが、[エージェント構成インテント（Agent Config Intents）] などの他の要因により、実際に影響を受けるワークロードは少なくなる可能性があります。

   

   インベントリ項目の表示、フィルタリング、ダウンロードの詳細については、Cisco Secure Workload のインベントリの管理を参照してください。

3. 影響を与えるポリシー

   先祖ワークスペースのポリシーは、現在のワークスペースのワークロードに影響を与える可能性があるため、先祖ワークスペースから必要な許可ポリシーが適用されていることを確認する必要があります。

   

4. 確認と同意

   この最後のステップでは、適用されるポリシー変更、影響を受ける可能性のあるワークロードの数、適用されるキャッチオールアクションの概要が示されます。[同意して適用（Accept and Enforce）] をクリックすると、ワークスペースのポリシーを使用して、関連するワークロードに設定される新しいファイアウォールルールが計算されます。

   後で参照できるように、新しく適用されたポリシーの名前、説明、およびアクションの理由を提供するオプションがあります。ロールバックの場合、過去のバージョンの名前と説明は変更できないため、理由のみを指定できます。

   

Kubernetes と OpenShift によって管理されるコンテナベースのワークロードでセグメンテーションを設定するために必要な手順の概要については、Kubernetes ベースのワークロードに対するマイクロセグメンテーションの設定を参照してください。

注目	Kubernetes や OpenShift ホストで稼働しているエージェントは、既存のルールを保持するように設定する必要があります。 Kubernetes によって追加された iptables ルールが適用によって干渉されないようにするには、[ルールの保持（Preserve Rules）] オプションが有効になっているプロファイルを使用してエージェントを設定する必要があります。「エージェント設定プロファイルの作成」を参照してください。

コンテナにポリシーを適用すると、Secure Workload は Kubernetes および OpenShift のサービス抽象化をプロバイダーとして使用できるようにします。内部的には、サービス抽象化のポリシーは、プロバイダーポッドとそれらが実行されているノードのルールに変換されます。この変換は、Kubernetes および OpenShift サービスのタイプに依存し、API サーバーから変更を受け取るたびに動的に更新されます。

（注）	NodePort および KubeloadBalancer サービスの場合、フローはノードレベルでルーティングされるため、ノードが属するアプリケーション範囲のワークスペースでポリシーが作成されていることを確認します。作成されていない場合、ルールはノードで生成されません。

次の例は、この機能によって実現する柔軟性を示しています。db という名前の NodePort タイプの Kubernetes サービスに対して、ラベル environment = production を持つすべてのホストとポッドからのトラフィックを許可する次のポリシーについて考えます。このサービスは、一連のポッドで TCP ポート 27017 を公開しています。

このポリシーにより、次のファイアウォールルールが適用されます。

• environment = production のラベルが付けられたホストとポッドで、サービスが属するクラスタのすべての Kubernetes ノードへの発信接続を許可します。このルールでは、Kubernetes によってこのサービスに割り当てられたノードポートが使用されます。

• ラベルが environment = production のポッドで、Kubernetes によってこのサービスに割り当てられた ClusterIP への発信接続を許可します。このルールでは、サービスによって公開されているポートが使用されます（TCP 27017）。

• サービスが属するクラスタの Kubernetes ノードで、プロバイダーポッドへの発信接続を許可します。このルールでは、サービスによって公開されているターゲットポートが使用されます（TCP 27017）。

• サービスデータベースを提供するポッドでは、すべての Kubernetes ノード、およびコンシューマホストとポッドからのすべての着信接続を許可します。このルールでは、サービスによって公開されているターゲットポートが使用されます（TCP 27017）。

サービスのタイプ、ポート、および一連のプロバイダーポッドの変更は、Secure Workload のルールジェネレータによってすぐに取得され、生成されたファイアウォールルールを更新するために使用されます。

注意	Kubernetes や OpenShift インベントリを含むポリシーは、Kubernetes クラスタの内部操作との競合を避けるために慎重に設計する必要があります。 Secure Workload によってインポートされた Kubernetes や OpenShift 項目には、Kubernetes クラスタを構成するポッドとサービスが含まれます（例：kube-system 名前空間のポッド）。これにより、Kubernetes クラスタ自体を保護するために正確なポリシーを定義できますが、不適切に設計されたポリシーがクラスタの操作に影響を与える可能性もあります。

適用後にポリシーを変更する必要がある場合は、通常、同じプライマリワークスペースで変更を行います。次に、変更を慎重に確認し、ワークスペースを再度分析して、期待どおりの効果があることを確認します。変更によって目的の効果が得られることを確認したら、ページの右上にある [最新のポリシーの適用（Enforce Latest Policies）] ボタンをクリックします。

• 複数の範囲のポリシー適用を同時に無効にするには、次の手順を実行します。

  ポリシーの適用の有効化で説明されている、複数の範囲で同時にポリシーを適用する手順に従います。ウィザードの [バージョンを選択（Select Version）] ページで、[バージョンを選択してください（Select a version）] をクリックし、[適用の無効化（Disable Enforcement）] を選択します。

• 単一範囲のポリシー適用を無効にするには、次の手順を実行します。

  範囲のプライマリワークスペースの [ポリシー適用（Policy Enforcement）] ページに移動し、赤色の [ポリシー適用の停止（Stop Policy Enforcement）] ボタンをクリックします。これにより、先祖ワークスペースで適用されたポリシーに基づいて、範囲内のアセットに新しいファイアウォールルールが書き込まれます。「x」の付いたラベルフラグが時系列チャートに作成されます。

適用履歴には、適用されたワークスペースとそのバージョンのリストに対する変更のリストが表示されます。

適用履歴を表示するには、次の手順を実行します。

1. [セグメンテーション（Segmentation）] ページの右側にあるキャレット記号をクリックして [ツール（Tools）] メニューを展開します。

2. [適用履歴（Enforcement History）] をクリックします。

   各セクションで、イベントについて説明され、変更内容の概要が表示されています。

3. イベントをクリックすると、その時点で適用されていたすべてのポリシーに関する詳細が表示されます。

会話テーブルビューには、コンシューマポートが削除され、レコードが常に 1 つしかない自動ポリシー検出の期間からの集約されたフローを表示する簡単な方法が示されます。ポリシーはフィルタ間を移動し、会話は IP アドレス間を移動します。

[観察結果の参照（Explore Observations）] ボタンをクリックすると、チャートビューが有効になり、[平行座標（Parallel Coordinates）] チャートを介して高次元データをすばやく探索できます。最初は少し難しいかもしれませんが、関心のある次元のみを有効にする場合（[次元（Dimensions）] ドロップダウンの項目のチェックを外す）や、次元の順序を並べ替える場合、このチャートは役立ちます。このチャートの 1 本の線は 1 つの観測値を表し、その線がさまざまな軸と交差する場所は、その次元での観測値を示しています。チャートの下にある観測結果のリストにカーソルを合わせると、より明確になり、チャート内の観測結果を示す線が強調表示されます。

選択したフィルタを反映したカンバセーションに基づく上位のコンシューマまたはプロバイダーの数は、カンバセーションテーブルの上部にある 2 つのボタンから確認できます。それぞれのボタンをクリックすると、カンバセーション数の列と、各コンシューマおよびプロバイダーのアドレス、ホスト名、その他のユーザー注釈の列がある表を含むダイアログが表示されます。

VIP 仮想 IP：クライアントがサービス宛てのトラフィックを送信する IP。

SNIP SNAT IP：トラフィックをバックエンドホストに送信するためにロードバランサによって使用される IP。

BE バックエンドエンドポイント：バックエンドホストの IP。

HIP ヘルスチェック IP：ヘルスチェックトラフィックをバックエンドホストに送信するためにロードバランサが使用するソース IP。

（注）	HIP は、自動マップモードの SNIP と同じです。ただし、SNAT プールが設定されている場合、HIP と SNIP は異なる場合があります。

次のように、ロードバランサの VIP、SNIP、および HIP が lb 範囲の一部であり、BE が be 範囲の一部である展開を検討してください。範囲は次のように作成されます。

• クライアント（Client）

  クライアントの範囲には、ロードバランサと通信するクライアントが含まれます。上記の例では、クライアントの範囲のクエリは次のようになります。

  address eq 192.168.60.21 or address eq 192.168.60.22

• lb

  F5 外部オーケストレータは、ロードバランサによって使用される VIP、SNIP、HIP、および BE にラベルを付けます。これらのラベルを使用して範囲クエリを構築できます。ここで、orchestrator_system/service_name は、サービスの VIP、orchestrator_system/service_startpoint SNIP、orchestrator_system/service_healthcheck_startpoint HIP の選択に使用されます。上記の例では、サービス db の VIP、SNIP、および HIP を含む範囲クエリは次のとおりです。

  user_orchestrator_system/cluster_id eq 1234 and
  (user_orchestrator_system/service_name eq db or
  user_orchestrator_system/service_startpoint eq db or
  user_orchestrator_system/service_healthcheck_startpoint eq db)

（注）	SNIP と VIP は同じ範囲の一部である必要があります。

• BE

  user_orchestrator_system/service_endpoint は、サービスの BE を選択します。上記の例では、サービス db の BE を含む範囲クエリは次のとおりです。

  user_orchestrator_system/cluster_id eq 1234 and
  user_orchestrator_system/service_endpoint eq db

各サービスは、最大 4 つの検出済みクラスタを生成します。このうち、サービスクラスタのみがユーザーに表示されます。SNIP、HIP、および BE クラスタは、サービスクラスタの関連クラスタとして表示されます。HIP および BE クラスタは、lb 範囲に HIP と BE が存在する場合にのみ生成されます。

上記の例では、自動ポリシー検出により、サービスの SNIP と HIP を含む lb 範囲に SNIP クラスタと HIP クラスタが生成されます。BE は lb 範囲の外にあるため、自動ポリシー検出でバックエンドクラスタは生成されませんが、代わりに db の関連クラスタのリストに be 範囲が追加されます。

クラスタは次のように生成されます。

• サービス

  サービスクラスタには、サービスの VIP が含まれます。サービスクラスタのクエリは次のとおりです。

  user_orchestrator_system/cluster_id eq 1234 and
  user_orchestrator_system/namespace eq common and
  user_orchestrator_system/service_name eq db

• SNIP

  サービスの SNIP は、SNIP クラスタに含まれています。SNIP クラスタのクエリは次のとおりです。

  user_orchestrator_system/cluster_id eq 1234 and
  user_orchestrator_system/service_startpoint eq db

• HIP

  サービスの HIP は、HIP クラスタに含まれています。HIP クラスタのクエリは次のとおりです。

  user_orchestrator_system/cluster_id eq 1234 and
  user_orchestrator_system/service_healthcheck_startpoint eq db

• バックエンド

  1 つ以上の BE が lb 範囲の一部である場合、サービスのバックエンドクラスタが生成されます。これは上記の例には当てはまらないため、lb 範囲ではバックエンドクラスタが生成されません。

VIP アドレス 192.168.60.100、SNIP アドレス 192.168.50.100 を持つサービス db があるとします。また、IP アドレス 192.168.50.11 を持つバックエンド VM がポート 10000 でリッスンしています。クライアント VM 192.168.60.21 から db へのトラフィックのポリシーは次のようになります。

• クライアントから VIP へのポリシー

  次のポリシーは、クライアント VM からサービス db へのアクセスを許可します。

  {
  "src": "<uuid of client scope>",
  "dst": "<uuid of service cluster>",
  "l4_params": [
  {
  "port": [
  10000,
  10000
  ],
  "proto": 6,
  }
  ]
  }

• SNIP から BE へのポリシー。

  SNIP から BE へのトラフィックを許可するポリシーは、設定に基づいて自動生成され、db の関連ポリシーとして表示されます。

  {
  "src": "<uuid of SNIP cluster>",
  "dst": "<uuid of be scope>",
  "l4_params": [
  {
  "port": [
  10000,
  10000
  ],
  "proto": 6,
  }
  ]

  lb 範囲から be 範囲へのポリシーコネクタは、次のポリシーをプッシュします。

  コンシューマ	プロバイダー	ポート	プロトコル	アクション
  SNIP	be	10000	TCP	許可

  これにより、BE ホスト 192.168.50.11 にファイアウォールルールが生成され、ポート 10000 の LB SNIP 192.168.50.100 からの着信トラフィックが許可されます。

• HIP から BE へのポリシー。

  HIP から BE へのトラフィックを許可するポリシーは、設定に基づいて自動生成され、db の関連ポリシーとして表示されます。

  {
  "src": "<uuid of HIP cluster>",
  "dst": "<uuid of be scope>",
  "l4_params": [
  {
  "port": [
  0,
  0
  ],
  "proto": ICMP,
  }
  ]
  }

  lb 範囲から be 範囲へのポリシーコネクタは、次のポリシーをプッシュします。

  コンシューマ	プロバイダー	ポート	プロトコル	アクション
  HIP	be	0	ICMP	許可

  これにより、BE ホスト 192.168.50.11 にファイアウォール ルールが生成され、LB HIP 192.168.50.2 からの着信 ICMP トラフィックが許可されます。

• 同じロードバランサインスタンスからの複数のサービスが同じ名前を持つ場合、これらのサービスのいずれかに対して生成されるバックエンドルールには、それらすべてのバックエンドプールが含まれます。つまり、ルールは必要以上に寛容になります。

次のソフトウェアパッケージは、Ubuntu 16.04 などの Linux システムにインストールされます。

• Java 8 JDK

• Apache Kafka クライアント：kafka-clients-1.0.0.jar

• プロトコルバッファコア：protobuf-java-3.4.1.jar

• Apache Log4j：log4j-1.2.17.jar

• Java 用のシンプルなロギングファサード：slf4j-api-1.7.25.jar, slf4j-log4j12-1.7.25.jar

• Java 用のシンプルなコンプレッサ/デコンプレッサ：snappy-java-1.1.4.jar

• 「所有者」のケーパビリティを持つユーザー ロールを作成し、選択したユーザーアカウントに割り当てます。

  

• 「ポリシーの適用」の説明に従って、ポリシーの適用を実行します。この最初のステップは、アクティブな範囲に関連付けられた Kafka トピックを作成するために必要です。

• [管理（Manage）] > [データタップ管理者（Data Tap Admin）]に移動します。

• [データタップ（Data Taps）] タブを選択し、[アクション（Actions）] 列のダウンロードボタンをクリックして、Kafka クライアント証明書をダウンロードします。ダウンロードダイアログで [Javaキーストア（Java Keystore）] フォーマットを選択してください。

  

• ダウンロードされたクライアント証明書ファイルには、通常、Policy-Stream-10-Policies-Subscription.jks.tar.gz のような名前が付いています。ディレクトリを作成し、作成したディレクトリの下に以下のように解凍します。

  
      mkdir Policy-Stream-10-Policies-Subscription
      tar -C Policy-Stream-10-Policies-Subscription -zxf Policy-Stream-10-Policies-Subscription.jks.tar.gz
  

Secure Workload バックエンドによって Kafka に公開されるネットワークポリシーは、Google Protocol Buffers 形式でエンコードされます。Linux システムにダウンロードしてインストールする方法については、こちらのガイドを参照してください。

Secure Workload ネットワークポリシーの proto ファイルは、こちらからダウンロードできます。

下の図は、Kafka に接続されている Secure Workload エンティティの簡略化された UML ダイアグラムを示しています。

protobuf でモデル化された Secure Workload ネットワークポリシーは、InventoryGroups のリスト、Intents のリスト、および CatchAll ポリシーで構成されます。各ポリシーには、1 つのルート範囲に属するすべての項目が含まれています。InventoryGroup には、単一のネットワーク ドレス、サブネット、またはアドレス範囲など、ネットワークアドレスを指定することによってサーバーやアプライアンスなどの Secure Workload エンティティを表す InventoryItems のリストが含まれます。Intent は、ネットワークフローが特定のコンシューマの InventoryGroup、プロバイダーの InventoryGroup、およびネットワークプロトコルとポートと一致するときに実行されるアクション（許可または拒否）を記述します。CatchAll は、Secure Workload 内部のルート範囲に対して定義されたキャッチオールアクションを表します。適用が有効になっているワークスペースがルート範囲に存在しない場合、デフォルトポリシーである ALLOW が生成されたポリシーに書き込まれます。

ユーザーまたはインベントリグループの変更によって適用がトリガーされると、Secure Workload バックエンドは、定義されたネットワークポリシーの完全なスナップショットを、KafkaUpdates として表される一連のメッセージとして Kafka に送信します。これらのメッセージを完全なスナップショットに再構築する方法と、エラー状態を処理する方法の詳細については、tetration_network_policy.proto ファイル内の KafkaUpdate のコメントを参照してください。

KafkaUpdate メッセージのサイズが 10MB を超える場合、Secure Workload バックエンドはこのメッセージをそれぞれのサイズが 10MB の複数のフラグメントに分割します。複数のフラグメントがある場合は、最初のフラグメントのみに TenantNetworkPolicy の ScopeInfo フィールドがあります。ScopeInfo は、KafkaUpdate メッセージの残りのフラグメントで nil に設定されます。

実装とデモクライアントをコンパイルして実行する方法については、Java で tnp-enforcement-client を参照してください。

この実装により、Kafka のみを介して Secure Workload ポリシーストリームからネットワークポリシーを読み取るための共通コードが提供されます。実際のポリシーをネットワークデバイスにプログラムするベンダー固有のコードは、必要なインターフェイス PolicyEnforcementClient を実装することでプラグインできます。