主なコンセプト

• 名前空間：名前空間は、クラスタを複数の仮想サブクラスタに分割する論理的な方法です。

• ポッド：ポッドは、作成または展開できる Kubernetes オブジェクトモデルの最小ユニットです。ポッドは、クラスタ内で実行中のプロセスの単一インスタンスを表し、1 つ以上のコンテナを含めることができます。

• ノード：ノードは、コンテナでアプリケーションを実行する、クラスタ内の物理または仮想マシンです。各ノードは、Kubernetes コントロールプレーンによって管理されます。

• サービス：サービスは、ポッドにアクセスするためのポッドとポリシーの論理的なセットを定義します。サービスにより、依存ポッド間の分離が可能になり、マイクロサービス アーキテクチャの管理が容易になります。

• サイドカーコンテナ：Kubernetes のサイドカーコンテナは、同じポッド内のメイン アプリケーション コンテナとともに実行される追加のコンテナです。この設定により、サイドカーコンテナはネットワーク、ストレージ、およびライフサイクルをメインコンテナと共有でき、緊密に連携できます。

• サービスメッシュ：Kubernetes の Service Mesh は、マイクロサービス通信を管理し、高度なトラフィック管理およびモニタリング機能とともにセキュリティ、信頼性、およびオブザーバビリティを向上させます。

制御ペインコンポーネント

UI を介して Kubernetes コントロールパネルにアクセスするか、CLI から Kubectl コマンドを使用してアクセスできます。

• API サーバー：API サーバーは、Kubernetes API を公開する中央管理エンティティであり、内部および外部のすべての要求を処理し、コントロールプレーンのフロントエンドとして機能します。

• スケジューラ：スケジューラは、リソース要件、制約、および可用性に基づいて、ポッドをノードに割り当てる役割を担います。

• コントローラマネージャ：クラスタの望ましい状態が実際の状態と一致するようにクラスタの状態を調整するさまざまなコントローラを実行します。

• etcd：etcd は、Kubernetes がすべてのクラスタデータストレージのニーズに使用する分散 Key-Value ストアです。

ノードコンポーネント

• kubelet：kubelet は、ポッド内のコンテナが実行されていることを確認し、コントロールプレーンにそのステータスを報告する各ノードのエージェントです。

• kube-proxy：kube-proxy は、ネットワークルールを管理してトラフィックを分散する各ノード上のネットワークプロキシであり、サービスにアクセス可能で接続が適切なポッドに到達するようにします。

• コンテナランタイム：コンテナランタイムは、コンテナの実行を担当するソフトウェアです。

Cisco Secure Workload への Kubernetes/OpenShift の展開

展開は、次の 4 つの主要なコンポーネントで構成されています：

1. オンプレミスの Cisco Secure Workload クラスタ、または SaaS でホストされている Cisco Secure Workload テナントのいずれかにある [制御（Control）] ペインまたは [管理（Management）] ペイン

2. 管理プレーン内に確立される Cisco Secure Workload Orchestrator またはコネクタは、EKS、AKS、GKE、OpenShift、または管理対象外の Kubernetes の Kubernetes クラスタ API と連携します。この相互作用により、ポッドとサービスメタデータの可視性が向上し、ポッド ID、注釈、ラベルなどの詳細が提供されます。詳細については、「Kubernetes/OpenShift」を参照してください。

3. Kubernetes デーモンセットは、セキュリティ対策を目的として Kubernetes または OpenShift クラスタに展開されます。DaemonSet は、各 Kubernetes または OpenShift ノードでの Cisco Secure Workload エージェントまたはポッドの継続的な動作を保証します。詳細については、「優れた可視性と適用のための Kubernetes または OpenShift エージェントのインストール」を参照してください。

4. 脆弱性スキャナをアクティブにすると、Kubernetes ノード内のいずれかのポッドでスキャンが開始されます。このスキャナは、Kubernetes または OpenShift クラスタ内のすべてのコンテナイメージを監視し、識別された CVE をコントロールプレーンまたは管理プレーンに報告します。

オペレーティングシステムのサポート情報については、エージェントの OS サポートマトリックスを参照してください。

要件

• インストールスクリプトには、クラスタノードで特権エージェントポッドを起動するための Kubernetes または OpenShift 管理者のログイン情報が必要です。

• Cisco Secure Workload エンティティは、tetration 名前空間に作成されます。

• ノードまたはポッドのセキュリティポリシーは、特権モードのポッドを許可する必要があります。

• busybox:1.33 イメージは、事前にインストールされているか、Docker Hub からダウンロード可能である必要があります。

• containerd ランタイムでは、config_path が設定されていない場合は、config.toml（デフォルトの場所：/etc/containerd/config.toml）を次のように変更します。

  
  ```
      [plugins."io.containerd.grpc.v1.cri".registry]
      config_path = "/etc/containerd/certs.d"
   ```

  containerd デーモンを再起動します。

• Kubernetes または OpenShift コントロールプレーンノードで実行するには、-toleration フラグを使用して、Secure Workload ポッドの容認を渡すことができます。通常渡される許容は、通常、ポッドがコントロールプレーンノードで実行されないようにする NoSchedule 容認です。

• Windows ワーカーノードの場合：

  • サポートされている Windows ワーカー ノード コンテナ ランタイム：ContainerD。

  • containerD の設定：次の containerd の変更を設定します。

    
    ```
        [plugins."io.containerd.grpc.v1.cri".registry]
        config_path = "/etc/containerd/certs.d"
     ```

    registry.mirrors の下の設定を削除します。デフォルト設定ファイルの場所は C:\Program Files\containerd\config.toml です。

    設定の変更後に、containerd デーモンを再起動します。

  • イメージ mcr.microsoft.com/oss/kubernetes/windows-host-process-containers-base-image:v1.0.0 は、Windows ワーカーノードに事前にインストールされているかダウンロード可能である必要があります。

  • 新しいバージョンにアップグレードする既存の Kubernetes エージェントには、Windows DaemonSet エージェントが自動的に含まれます。ただし、以前のスクリプトでは、Windows DaemonSet エージェントはアンインストールされません。Windows DaemonSet エージェントをアンインストールするには、最新のインストーラスクリプトをダウンロードしてください。

  • サポート対象：

    • Microsoft Windows Server 2022

    • Windows Server 2019

    • Kubernetes 1.27 以降

ポリシー適用の要件

IPVS ベースの kube-proxy モードは、OpenShift ではサポートされません。

これらのエージェントは、[ルールの保持（Preserve Rules）] オプションを有効にして設定する必要があります。詳細については、「エージェント設定プロファイルの作成」を参照してください。

適用が適切に機能するためには、インストールされている CNI プラグインが次の条件を満たす必要があります。

• すべてのノードとポッド間にフラットなアドレス空間（IP ネットワーク）を提供すること。クラスタ内通信のためにソースポッド IP をマスカレードするネットワークプラグインはサポートされていません。

• Secure Workload 適用エージェントが使用する Linux iptables ルールまたはマークに干渉しないこと（マークビット 21 および 20 は、NodePort サービスのトラフィックを許可および拒否するために使用されます）

次の CNI プラグインは、上記の要件を満たすことがテストされています。

• 次の Felix 設定を持つ Calico (3.13)：(ChainInsertMode: Append, Ipta- blesRefreshInterval: 0) または (ChainInsertMode: Insert, IptablesFilterAllowAction: Return, IptablesMangleAllowAction: Return, IptablesRefreshInterval: 0)。その他のオプションは、そのデフォルト値を使用します。

これらのオプションの設定に関する詳細については、Felix 設定リファレンスを参照してください。

サービスメッシュサイドカー

サービスメッシュは、アプリケーションコンテナとともに展開されたサイドカープロキシを使用して、ネットワークトラフィックを代行受信および管理します。アプリケーションと同じネットワーク名前空間を共有するこれらのサイドカーは、すべての着信および発信のネットワーク通信を仲介します。

トラフィックの適用

• サービスメッシュ対応アプリケーションのセグメンテーションポリシーを実装する場合、サイドカープロキシが使用する追加のポートを考慮することが重要です。これらのポートは、アプリケーションのネットワークトラフィックの管理と保護において重要な役割を果たします。

• サービスメッシュが失われず、利用可能な状態を維持するためには、セグメンテーションポリシーにサイドカープロキシによって使用されるポートのルールが明示的に含まれていることを確認してください。

サイドカープロキシでサポートされるポートとプロトコル

サービスメッシュ対応アプリケーションにセグメンテーションポリシーを適用するときに、次のポートを含めます。

（注）	上記のポートは、Envoy サイドカープロキシ通信のために Istio が使用するデフォルトのポートです。これらのポートが Istio グローバルサービスメッシュ構成の設定で更新されている場合は、アプリケーションで更新されたポートを使用します。

サービス メッシュ コントロール プレーンでサポートされるポートとプロトコル

コントロールプレーンをセグメント化する際は、次のポートとプロトコルを使用します。