Sysdig Secure : ネットワーク(ネットワークセキュリティポリシーツール)

By 清水 孝郎 - SEPTEMBER 20, 2021

SHARE:

本文の内容は、2021年9月21日現在における、docs.sysdig.com上のNetworkを元に日本語に翻訳・再構成した内容となっております。

ネットワーク

2021年6月より、Sysdig Secure SaaSでは、ネットワークセキュリティポリシーツールがポリシーから独立し、独自のメニューとなりました。



ネットワークセキュリティポリシーツール

デフォルトでは、Kubernetesクラスター内のすべてのポッドは、何の制限もなく相互に通信できます。Kubernetesのネットワークポリシーは、マイクロサービスアプリケーションを相互に隔離し、影響範囲を限定して全体のセキュリティ態勢を向上させるのに役立ちます。

ネットワークセキュリティポリシーツールを使用すると、Sysdig Secure内でKubernetesネットワークポリシーを作成し、微調整することができます。このツールを使用して、観測されたネットワークトラフィックと追加のユーザーアセスメントの両方を取り入れた、ワークロードを保護するための「最小特権」ポリシーを生成できます。Sysdig Secureは、ファイアウォールやインラインコネクションプロキシーを追加することなく、Kubernetesに既に存在する機能を活用します。

ベネフィット

本ツールは、マイクロサービスの通信を深く理解し、観測されたトラフィックに基づいてネットワークポリシーを自動的に記述することで、時間と労力を節約し、ユーザーが適切なポリシーを作成できるようにします。

具体的には、以下のような仕組みがあります：
  • アプリケーションやサービス間のネットワークトラフィックをすぐに確認でき、通信内容の特定に役立つトポロジー・マップも表示されます。
  • ベースラインのネットワークポリシーは、ユーザーが希望する宣言的な状態に合うように、直接改良および修正することができます。
  • ネットワーク通信のベースライン＋ユーザ定義の調整に基づいたKNPの自動生成。
  • Least-Privilege（最小特権）：KNPは許可制モデルに従っており、明示的に許可されていない通信はすべて禁止されます。
  • エンフォースメントはKubernetesのコントロールプレーンに委ねられ、追加の計測やホストのネットワーク構成を直接いじることは避けられます。

前提条件

Sysdigエージェント・バージョン10.7以上

サポートされているOrchestratorのディストリビューションとCNIプラグイン
  • Vanilla Kubernetes（kops、kube-admin）、Calico、Weave、またはcilliumを使用
  • OVSを使用したOpenShift 4.x
  • Google GKE  Calico、Weave、またはcilliumを使用
  • Amazon EKS  Calico、Weave、またはcilliumを使用
  • Rancher Kubernetes Calico、Weave、またはcilliumを使用
  • Azure  Calico CNIを使用

ネットワークセキュリティポリシーツールを利用する

ネットワークセキュリティポリシーツールを使用するには、以下の基本的な手順に従います。
  • お使いの環境が「前提条件」を満たしていることを確認します。
  • Sysdig Secureにログインし、[Network]を選択します。クラスターとネームスペースを選択するプロンプトが表示され、[ネットワークセキュリティポリシー]ページに移動します。





  • スコープを設定します。(どの期間のどのエンティティを分析するか?)
  • Ingress/Egressテーブルを確認し、必要に応じて検出された通信を編集する。
  • トポグラフィーマップですべてを視覚的に確認する。
  • Generated Policyをクリックし、生成されたファイルをダウンロードします。
  • オプション ツールの設定で微調整します。

スコープの設定

最初に、通信を集約するKubernetesのエンティティと時間枠を定義します。

集約の理解：通信はKubernetesのメタデータを使用して集約され、ポリシー作成に関係のない追加エントリを持たないようにします。たとえば、デプロイメントAのポッドAがデプロイメントBのポッドBと複数回通信した場合、インターフェイスには1つのエントリしか表示されません。あるいは、デプロイメントAの下にあるpod A1とpod A2が両方ともpod Bと通信している場合、デプロイメントAはそのすべてのpodを代表することになります。

  • Sysdig Secure UIで、左メニューの「Network」を選択します。
  • ドロップダウンメニューから「Cluster」と「Namespace」を選択します。
  • ポリシーを作成したいKubernetesエンティティの種類を選択します。
    • Service
    • Deployment
    • Daemonset
    • Stateful Set
    • CronJob: 過剰な数のエントリを生成する可能性のあるジョブではなく、CronJob（スケジューラ）レベルに集約されたコミュニケーションを見るには、CronJobを選択してください。
    • Job: Jobを選択すると、JobがCronJobの親を持たないエントリを見ることができます。
  • タイムスパンを選択してください。つまり、エンティティのために観測されたコミュニケーションを集約するために、どのくらいの時間をさかのぼるかです。インターフェースは、そのKubernetesエンティティとタイムフレームのIngress / Egressテーブルを表示します。

IngressとEgressの管理

Ingress/Egressテーブルは、選択されたエンティティ（ポッドオーナー）と時間枠に対して観測された通信を詳細に表示します。

粒度とグローバルな割り当て：また、ドロップダウン式のグローバルルールオプションを使用して、一般的なルールを確立することもできます。

**未解決のIPの理解：**通信によっては、エンドポイントの1つをKubernetesのメタデータに解決できず、Service、Deploymentなどに分類できない場合があります。例えば、マイクロサービスが外部のWebサーバーと通信している場合、その外部IPはクラスター内のどのKubernetesメタデータにも関連付けられていません。UIでは、これらのエンティティは “未解決のIP “として表示されます。未解決のIPはKubernetesのネットワークポリシーからデフォルトで除外されますが、ingress/egressインターフェースを介して手動で追加することができます。



検出された通信を確認・編集するには、IngressまたはEgressを選択します。

  • 前述のようにスコープを選択します。
  • インクラスターエンティティの場合：必要に応じて、許可された通信を次のいずれかの方法で編集します。
    • 許可された通信の行を選択／選択解除する、または
    • General Ingress/Egress Rulesを選択する。「すべてをブロック」、「ネームスペース内ですべてを許可」、または「すべてを許可」。
  • 未解決のIPについて（該当する場合）：ツールが多くの未解決のIPを検出した場合、以下のことができます。
    • 任意のテキストで結果を検索し、特定のリスティングを見つける。
    • 結果を次の方法でフィルタリングします。
      • Internal：クラスター内で見つかったもの
      • External：クラスター外で見つかったもの
      • Aliased：任意のエイリアスを表示
      • Unknown：InternalまたはExternalの区別がつきません。
    • 不明なIPの扱いを微調整することができます（管理者のみ）。
    • エイリアスを割り当てたり、IPを「許可」ステータスにしたり、CIDR構成を追加したりして、IPが正しく分類され、ラベル付けされるようにします。
  • 他のテーブルでも同様の作業を行い、トポロジーの確認やポリシーの生成に進みます。

トポロジーの視覚化

トポロジービューを使用して、これが希望するポリシーであるか、または何かを変更する必要があるかを視覚的に検証します。トポロジービューは、ポッドオーナー、リスニングポート、サービス、ラベルなど、ハイレベルなKubernetesのメタデータを表示します。

このポリシーの適用を決定した場合に許可されない通信は、赤で色分けされています。



ポップアップ詳細ペイン：トポロジーの要素にカーソルを合わせると、エンティティと通信の両方に関連するすべての詳細が表示されます。

生成されたポリシーの確認とダウンロード

ルールとコミュニケーションラインに問題がなければ、「 Generated Policy」タブをクリックするだけで、すぐに生成されたファイルを入手できます。

生成されたYAMLファイルを確認し、ブラウザにダウンロードします。



設定の微調整

Sysdigは、エージェントがネットワークデータを前処理する方法を微調整したい管理者のために、設定パネルを導入しました。

このパネルには、以下の3つの領域があります。
  • ワークロードラベル
  • 未解決のIPアドレス
  • クラスターCIDR設定

アクセスするには：
  • Sysdig Secureに管理者としてログインします。
  • 左側のナビゲーションから「Network」を選択します。
  • 右上のConfigurationボタンをクリックします。



ワークロードラベル

Sysdigエージェントは、クラスター内のエンティティに使用されているラベルを自動的に検出します。時には、ネットワークセキュリティの目的のために必要な数以上のラベルが存在することがあります。このような場合には、最も意味のある2つまたは3つのラベルを選択し、include/excludeを使用することで、UIとネットワークセキュリティポリシーの両方で混乱を避けることができます。



未解決のIP設定

SysdigエージェントがIPをより高いレベルの構造（サービス、デプロイメント、デーモンセットなど）に解決できない場合、そのIPはingress/egressテーブルに「unresolved」と表示されます。



このようなIPまたはCIDRを設定パネルに手動で入力し、エイリアスでラベル付けし、オプションで「許可」ステータスに設定できるようになりました。なお、IPを単一のエイリアスでグループ化すると、Topographyビューがすっきりします。

クラスターCIDRの設定

未解決のIPは一覧表示され、「internal」（クラスター内）、「external」（クラスター外）、「unknown」（サブネット情報が不完全）に分類されます。不明の場合、Sysdigは解決の手助けとなるエラーメッセージを表示します）。

最も簡単な解決方法は、手動でクラスターとサービスのCIDRを指定することです。



サンプルユースケース

すべてのケースにおいて、エージェントが情報を収集できるように、アプリケーションを少なくとも12時間稼働させることから始めます。

ケース1：特定のIngress/Egress通信のみを許可する場合

開発者として、サービス/デプロイメントが、明示的に許可したingress/egressのネットワーク通信を確立することのみを許可するKubernetesネットワークポリシーを作成したいとします。

  • アプリケーションのクラスターネームスペースとデプロイメントを選択します。
事前計算されたingressとegressのテーブルが表示されるはずです。また、アプリケーションが外部のIPとingressとegressの通信を行わないため、未解決のIPが表示されないことが確認できます。トポロジーマップにも同じ情報が表示されています。
  • ルールの変更：アプリケーションが通信しているあるサービスが廃止されたと判断します。egressテーブルのその行のチェックを外します。
  • トポロジーマップを確認します。通信はまだ存在しますが、赤で表示されます。これは、現在のKubernetesネットワークポリシー（KNP）を使用して通信が禁止されていることを意味します。
  • 生成されたポリシーコードを確認します。計画通りになっているか確認してください。
    • ingress/egressのraw IPがない
    • 明示的に除外したサービスのエントリがない
  • 生成されたポリシーをダウンロードして、Kubernetes環境にアップロードします。
  • アプリケーションが、トポロジーで黒くマークされ、テーブルでチェックされたサービスとのみ通信できることを確認します。その後、ポリシーを生成してダウンロードし、適用します。

ケース2：プロキシの静的IPへのアクセスを許可する

開発者として、アプリケーションがスタティックIPを持つプロキシを使用していることを知っており、アプリケーションがプロキシへのアクセスを許可するポリシーを設定したいと考えています。
  • インターフェイスの Egress セクションでプロキシ IP を確認します。
  • Allow Egress to IP maskを使用して、これらのIPを特に許可する手動ルールを作成する
  • ingressテーブルとegressテーブルの他のすべてのエントリの選択を解除する。
  • トポロジーマップを見て、これらの外部IPへの通信のみが黒で表示され、他のサービス/デプロイメントとのその他の通信が赤で表示されていることを確認します。
  • 生成されたKubernetesのネットワークポリシーをダウンロードして適用します。

ケース3：ネームスペース内の通信のみ許可する

アプリケーションの通信は、ingressもegressもネームスペースの中だけで行われるべきだと考えています。
  • 一般的なルールを用いてネームスペース内でのingressを許可します。
  • 一般的なルールを使用してネームスペース内のegressを許可する
  • ポリシーを生成して確認します：特定のサービス/デプロイメントを指定することなく、ネームスペース内のすべてのものが許可されていることを確認してから適用します。

ケース 4: 特定のネームスペースへのアクセスを許可し、Egressのみを許可する

アプリケーション デプロイメント A は、別のネームスペースにあるデプロイメント B のアプリケーションとしか通信しません。その通信に必要なのは egress トラフィックだけで、ingress トラフィックは必要ありません。
  • Kubernetesエンティティとraw IPの両方について、ingressテーブルが空であることを確認します。
  • Egressテーブルにリストされている唯一の通信が、デプロイメントBとの通信であることを確認します。
  • 自動生成されたポリシーをダウンロードして適用し、検証します。
    • アプリケーションは、Aのネームスペース内の他のエンティティと通信できない
    • アプリケーションはクラスターDNS サーバに連絡して他のエンティティを解決できる。

ケース5: デプロイメントがラベル変更されたときにアクセスを許可する

開発者として、サービス/デプロイメントが明示的に許可されたネットワーク通信のingressとegress 確立することのみを許可するポリシーを作成し、変更を加える必要があります。
  • アプリケーションを数時間実行した後、このポリシーに関連するすべてのネームスペースにタグ付けしていないことに気付きます。
  • ビューの上部に「このネームスペースにラベルを割り当てる必要があります」というメッセージが表示されます。
  • 異なるビューで状況を確認します：
    • 生成されたポリシーには、その通信に関するエントリがないはずです。
    • トポロジーマップには、その通信が赤い線で表示されているはずです。
  • ラベルがなかったネームスペースにラベルを付けます。数分後、更新された情報が行に表示されます。
  • その接続を適切にホワイトリストに登録します。
  • ポリシーを生成してダウンロードし、それを適用します。

トラブルシューティング

一般的なエラーメッセージを解決するためのヒントです。

Error message: Namespaces without labels

問題：KNPがingress/egressルールを定義するためには、ネームスペースがラベル付けされている必要があります。対象となる通信でラベル付けされていないネームスペースが検出されると、「Namespaces without labels」というエラーメッセージがUIに表示されます。



解決方法： 該当するネームスペースにラベルを割り当てて、システムの自動検出が追いつくまで数分待ってください。

Error Message: Cluster subnet is incomplete

問題：未解決のIPをクラスターの内側または外側に分類するために、エージェントはどのCIDR範囲がクラスターに属するかを知る必要があります。デフォルトでは、エージェントは、kube-apiserverおよびkube-controller-managerプロセスのコマンドライン引数を調べることで、範囲を発見しようとします。

クラスターサブネットを自動検出できない場合は、「cluster subnet is incomplete」というエラーメッセージがUIに表示されます。



解決方法：
  • 好ましい方法：Configurationパネルを使用して、CIDRエントリーを追加します。
  • まれに、デフォルトのkube-apiserver、kube-controller-managerプロセス以外の他のプロセスでCIDRレンジを探すようにエージェントを設定する必要がある場合があります。その場合は、エージェントのconfigmapに以下を追加します。
network_topology:
  pod_prefix_for_cidr_retrieval:
[<PROCESS_NAME>, <PROCESS_NAME>]