目次

ポリシーを作成する

Policiesは、Kubernetesクラスタでの実行を許可するルールを定義します。

保護するクラスタごとに1つのポリシーを定義し、クラスタ全体に適用される初期設定のルールセット(「ポリシー定義」とも呼ばれます)を使用します。クラスタに複数の名前空間が含まれている場合は、名前空間に対して個別のルールセットを定義することもできます。名前空間ルールは、クラスタ全体のルールよりも優先されます。

最初に、ログのみのルールを含むポリシーを作成することをお勧めします。ポリシーが想定どおりに機能していることを確認したら、ポリシーに違反するオブジェクトをブロックするようにルールを変更します。

クラスタのポリシーを定義する

  1. Trend Micro Cloud One console を開き、[Container Security]を選択します。
  2. Policiesアイコン [Policies] 画面に移動します。
  3. 次のいずれかを実行します。

    • 初めてのポリシーの場合は、[ + New policy] をクリックします。

      既存のポリシーがない場合にのみ表示される画面。

    • このポリシーが最初のポリシーでない場合は、[+ New] をクリックします。

      すべてのプロパティがログに記録されるように設定されたクラスタ全体のポリシー定義の例

  4. ポリシーの一意の Name を指定して、ポリシーの目的を特定し、必要に応じて Descriptionを追加します。

  5. [Cluster-Wide Policy Definition] で、このポリシーに適用するルールを設定します。3つの異なる種類のルールに対応する3つのタブがあります。

    • Deployment: これらのルールは、イメージのデプロイ時に適用されます。適用するルールのチェックボックスをオンにし、ドロップダウンを使用して、ルールに違反した場合の処理 (イベントのログへの記録およびデプロイメントの許可) またはデプロイメントのブロックを選択します。
    • Continuous: これらのルールは、ポッドの実行中に定期的にチェックされます。適用するルールのチェックボックスをオンにし、ドロップダウンを使用して、ルール違反時の処理を選択します。イベントをログに記録して、ポッドの実行を継続するか、ポッドのネットワークトラフィックを隔離するか、またはポッドを終了するかを選択します。
    • Runtime: このタブで、ポッドの実行中に適用するルールを含むルールセットを1つ以上追加します。ランタイムセキュリティを有効にしてルールセットを定義する方法については、 ランタイムセキュリティの構成 を参照してください。ルールセットは、実行時にポッドがルールに違反した場合に Container Security が実行する処理も定義します。ログにイベントを記録し、ポッドの実行を許可するか、ポッドのネットワークトラフィックを隔離するか、またはポッドを終了するかを選択します。

    ルールの詳細については、「ルールについて」を参照してください。

    デプロイメントルールと継続ルールは、特定の組み合わせで配信する必要があります。

    デプロイメントアクション 継続的な処理
    ログ ログ
    ブロック ログ
    ブロック 隔離
    ブロック 終了

    Container Security にも初期設定ルールがあります。詳細については、「 信頼済みの画像」を参照してください。

  6. ポリシーを確定するには、[ Create]を選択します。

クラスタにポリシーを割り当てる

このセクションでは、クラスタの追加 が完了していることを前提としています。

  1. Clusters アイコンClusters ページに移動します。
  2. ポリシーを適用するKubernetesクラスタを選択します。
  3. Policy リストからポリシーを選択します。
  4. [ Save ]を選択します。

名前空間のポリシー定義を追加する

クラスタに複数の名前空間が含まれている場合は、名前空間に対して個別のポリシー定義を作成できます。名前空間ポリシー定義は、クラスタ全体のポリシー定義よりも優先されます。

  1. Policies アイコンPolicies 画面で、既存のクラスタ全体のポリシーの名前を選択します。
  2. [ Policy Definitions ]セクションで、[ Cluster-Wide Policy Definition ]見出しの横にある[ +]を選択します。

    Policy Definitions インタフェースで、+ボタンが強調表示されている

  3. ページの一番下までスクロールし、追加した新しいセクションで展開アイコンを選択します。

  4. ポリシーの目的の識別に役立つ一意の Name を指定します。
  5. [ Namespaces ]領域で、この新しいポリシーで保護する1つ以上のKubernetes名前空間を追加します。
  6. 必要に応じて、対応するタブを使用してデプロイメントルール、継続ルール、およびランタイムルールを設定します。適用するルールのチェックボックスをオンにし、ドロップダウンを使用して、オブジェクトがルールに違反した場合の処理を選択します。ルールの詳細については、「 ルールについて」を参照してください。
  7. [ Save ]を選択します。

別の名前空間ルールセットを追加する場合は、 + を選択して新しい名前空間ポリシー定義セクションを追加します。

名前空間を保護する

Kubernetesの資格情報や不正な役割ベースのアクセス制御による攻撃を防ぐには、これらのコンテナへの特殊な権限でのアクセス試行をログに記録するかブロックするルールを設定することが重要です。trendmicro-system名前空間で有効にすることをお勧めします。

  1. 作成する名前空間のポリシー保護する名前空間の場合。
  2. Kubectlアクセスルールを有効にします。

    Kubectlアクセス

ポリシーをテストする

ポリシーを作成して設定したら、 Container Securityを使用してKubernetesクラスタを保護できます。

デプロイメント (kubectl、helmなど) は、デプロイメントコントローラによって確認されます。この例では、特権付きのbusyboxコンテナをデプロイします。

この例では、特権コンテナルールの処理として[ブロック]が選択されているものとします。

  1. busybox.yaml という名前のファイルを次の内容で作成します。

    apiVersion: v1
    kind: Pod
    metadata:
        name: busyboxpod
        labels:
            app: busyboxpod
    spec:
        containers:
        - image: busybox
          command:
              - sleep
              - "3600"
          imagePullPolicy: IfNotPresent
          name: busybox-container
          securityContext:
              privileged: true
        restartPolicy: Always

    このポッドの定義では、 securityContextprivileged = trueに設定されています。先に作成したポリシーでは、特権コンテナをブロックするようにポリシーを設定しているため、このポッドがブロックされます。

  2. kubectlコンテキストがクラスタに設定されていることを確認します。

  3. 次のコマンドを使用してポッドを作成します。

    $ kubectl apply -f busybox.yaml

  4. 要求が拒否されたことを確認します。

    $ kubectl apply -f busybox.yaml
    Error from server: error when creating "busybox.yaml": admission webhook "trendmicro-admission-controller.default.svc" denied the request:
    - containerSecurityContext violates rule privileged "true" in container(s) "busybox-container" (block).
  5. Container Security コンソールの イベントアイコンEvents ページに移動すると、対応するイベントが表示されます。

    blockPolicyというポリシーのブロック処理が表示されたイベント画面

ルールについて

デプロイメントルール

イメージがデプロイされようとしているとき、または処理が適用されようとしているときに、Deploymentタブのルールが適用されます。これらのルールに基づいて、Log (および許可) またはBlockのデプロイメントを選択できます。

ポッドのプロパティ

  • rootとして実行されるコンテナ
  • ホストネットワークの名前空間で実行されるコンテナ
  • ホストIPC名前空間で実行されるコンテナ
  • ホストPID名前空間で実行されるコンテナ

コンテナのプロパティ

  • rootとして実行されるコンテナ
  • 特権コンテナ
  • 権限昇格権限を持つコンテナ
  • ルートファイルシステムに書き込み可能なコンテナ
  • 事前定義されたポリシーに違反する機能を持つコンテナ

    使用可能な機能ポリシーは次のとおりです。

    • restrict-nondefaults: 初期設定のDocker機能のいずれかの機能を許可します。
    • baseline: 初期設定の機能は許可されますが、NET_RAW機能は許可されません。
    • Restricted:NET_BIND_SERVICE機能のみを許可します。
    • restrict-all: 機能を許可しません。

    NET_RAWは、RAWソケットとPACKETソケットの使用を許可する初期設定の機能です。この機能により、不正なユーザがパケットを偽造したり、MITM攻撃を実行したり、その他のネットワーク攻撃を実行したりする可能性があります。この権限は通常、特定のネットワークのニーズにのみ使用されるため、削除しても大部分のアプリケーションには影響しません。

    NET_BIND_SERVICEは、インターネットドメインの特権ポート(1024未満のポート番号)へのバインドを許可する初期設定の機能です。多くの場合、Webサーバで使用され、root以外のユーザにこれらのポートへのアクセス権を付与します。

    CIS Kubernetes Benchmarksでは、新しい機能を追加せず、少なくともNET_RAW機能を削除することをお勧めします。

    コンテナのニーズを考慮し、最小の権限の原則に沿って機能ポリシーを適用することをお勧めします。


    機能ポリシーとポッドセキュリティのベストプラクティスの詳細については、「Pod Security Standards」を参照してください。

イメージのプロパティ

  • 指定された条件を満たすレジストリのイメージ
  • 指定の条件を満たす名前のイメージ
  • 指定の条件を満たすタグが付いたイメージ

検索結果

次のルールは、 TMASDeep Security Smart Checkの両方でサポートされています。

  • 検索されていないイメージ
  • 重大度レベルの脆弱性を持つイメージ

次のルールは、TMAS最新バージョンのDeep Security Smart Checkの両方でサポートされています。

  • CVSS攻撃元区分が vector で、重大度が 重大の脆弱性のあるイメージ

    攻撃元区分の詳細については、「CVSS仕様の攻撃元区分 (AV)」を参照してください。


    使用可能なベクターは次のとおりです。

    • ローカルまたは物理
    • 隣接
    • ネットワーク

    重大度は次のとおりです。

    • defcon 1
    • 重大以上
    • 高以上
    • 中以上
    • 低または高
    • 無視できる程度以上
    • 任意
  • CVSS攻撃の複雑さが 複雑 であり、重大度が 重大である脆弱性のある画像

    攻撃条件の複雑さの詳細については、「CVSS仕様の攻撃条件の複雑さ (AC)」を参照してください。


    考えられる複雑さは次のとおりです。

    重大度は次のとおりです。

    • defcon 1
    • 重大以上
    • 高以上
    • 中以上
    • 低または高
    • 無視できる程度以上
    • 任意
  • CVSSの可用性への影響が impact であり、重大度が 重大である脆弱性のあるイメージ

    可用性への影響については、CVSS仕様の可用性(A)を参照してください。


    考えられる影響は次のとおりです。

    重大度は次のとおりです。

    • defcon 1
    • 重大以上
    • 高以上
    • 中以上
    • 低または高
    • 無視できる程度以上
    • 任意

次のルールでは、 Deep Security Smart Checkが必要です。

  • 不正プログラムを含むイメージ
  • 重大度レベルの内容が検出されたイメージ
  • 重大度レベルのチェックリストを持つイメージ
  • チェックリストの種類がネガティブのチェックリストで、結果の重大度が重大であるイメージ

    Smart Check は、イメージを検索するときに、事前に定義されたルールセットに対してイメージを評価し、共通コンプライアンス標準(PCI-DSS v2、NIST 800-190、およびHIPAA)の遵守状況を判断します。Container Securityでは、関連付けられたイメージのチェックリストルールの検索結果が重大度しきい値を超えている場合、クラスタのデプロイメントをログに記録したりブロックしたりできます。


    チェックリスト機能は現在、 CentOS イメージと Red Hat イメージでのみサポートされています。


    使用可能なチェックリストは次のとおりです。

    • PCI-DSS v2:Trend Micro PCI-DSS v3コンテナイメージのコンプライアンス
    • NIST 800-190:Trend Micro NIST 800-190コンテナイメージのコンプライアンス
    • HIPAA:Trend Micro HIPAAコンテナイメージのコンプライアンス

    重大度は次のとおりです。

    • defcon1
    • 重大以上
    • 高以上
    • 中以上
    • 低または高
    • 無視できる程度以上
    • 任意

    一部のチェックリストには、これらの重大度レベルのすべてが含まれているわけではありません。たとえば、PCI-DSS v2チェックリストには現在、低から高の範囲のルールがあります。NIST 800-190チェックリストには、現在、重要度の高いルールのみが含まれています。HIPAAプロファイルには現在、中および高の重要度のルールがあります。

Kubectlアクセス

Container Securityなどの特殊な権限でコンテナを保護するには、これらのルールを使用して名前空間ポリシーを設定することをお勧めします。

  • コンテナへの実行の試み
  • コンテナでポート転送を確立しようとする試み

除外

Exceptions セクションを使用して、他のデプロイメントルールをオーバーライドする例外を追加します。たとえば、「dev」を含む名前のイメージをブロックするが、「devone」というイメージを許可するデプロイメントルールがある場合は、「名前がdevoneと等しいイメージ」の除外を追加します。


次のような例外が考えられます。

  • 指定された条件を満たす名前のレジストリのイメージを許可する
  • 指定された条件を満たす名前のイメージを許可する
  • 指定された条件を満たすタグを含む画像を許可します

継続ルール

Continuous タブのルールは、ポッドの実行中に定期的に確認されます。Log を選択して実行を継続するか、 Isolate するか、ルールに違反した場合はポッドを Terminate することもできます。

ポッドのプロパティ

  • rootとして実行されるコンテナ
  • ホストネットワークの名前空間で実行されるコンテナ
  • ホストIPC名前空間で実行されるコンテナ
  • ホストPID名前空間で実行されるコンテナ

コンテナのプロパティ

  • rootとして実行されるコンテナ
  • 特権コンテナ
  • 権限昇格権限を持つコンテナ
  • ルートファイルシステムに書き込み可能なコンテナ
  • 事前定義されたポリシーに違反する機能を持つコンテナ

    使用可能な機能ポリシーは次のとおりです。

    • restrict-nondefaults: 初期設定のDocker機能のいずれかの機能を許可します。
    • baseline: 初期設定の機能は許可されますが、NET_RAW機能は許可されません。
    • Restricted:NET_BIND_SERVICE機能のみを許可します。
    • restrict-all: 機能を許可しません。

    コンテナ機能ルールの詳細については、上記の「デプロイメントルールのコンテナプロパティ」にある対応するルールを参照してください。

イメージのプロパティ

  • 指定された条件を満たすレジストリのイメージ
  • 指定の条件を満たす名前のイメージ
  • 指定の条件を満たすタグが付いた画像

検索結果

次のルールは、 TMASDeep Security Smart Checkの両方でサポートされています。

  • 検索されていないイメージ
  • 重大度レベルの脆弱性を持つイメージ

次のルールは、TMAS最新バージョンのDeep Security Smart Checkの両方でサポートされています。

  • CVSS攻撃元区分が vector で、重大度が 重大の脆弱性のあるイメージ

    攻撃元区分の詳細については、「CVSS仕様の攻撃元区分 (AV)」を参照してください。


    使用可能なベクターは次のとおりです。

    • ローカルまたは物理
    • 隣接
    • ネットワーク

    重大度は次のとおりです。

    • defcon 1
    • 重大以上
    • 高以上
    • 中以上
    • 低または高
    • 無視できる程度以上
    • 任意
  • CVSS攻撃の複雑さが の複雑 であり、重大度が の重大である脆弱性のある画像

    攻撃条件の複雑さの詳細については、「CVSS仕様の攻撃条件の複雑さ (AC)」を参照してください。


    考えられる複雑さは次のとおりです。

    重大度は次のとおりです。

    • defcon 1
    • 重大以上
    • 高以上
    • 中以上
    • 低または高
    • 無視できる程度以上
    • 任意
  • CVSSの可用性への影響が impact であり、重大度が 重大である脆弱性のあるイメージ

    可用性への影響については、CVSS仕様の可用性(A)を参照してください。

    考えられる影響は次のとおりです。

    重大度は次のとおりです。

    • defcon 1
    • 重大以上
    • 高以上
    • 中以上
    • 低または高
    • 無視できる程度以上
    • 任意

次のルールでは、 Deep Security Smart Checkが必要です。

  • 不正プログラムを含むイメージ
  • 重大度レベルの内容が検出されたイメージ
  • 重大度レベルのチェックリストを持つイメージ
  • チェックリストの種類 がネガティブのチェックリストで、結果の重大度が 重大であるイメージ

    Smart Check は、イメージを検索するときに、事前に定義されたルールセットに対してイメージを評価し、共通コンプライアンス標準(PCI-DSS v2、NIST 800-190、およびHIPAA)の遵守状況を判断します。Container Securityでは、関連付けられたイメージのチェックリストルールの検索結果が重大度しきい値を超えている場合、クラスタのデプロイメントをログに記録したりブロックしたりできます。


    チェックリスト機能は現在、 CentOS イメージと Red Hat イメージでのみサポートされています。


    使用可能なチェックリストは次のとおりです。

    • PCI-DSS v2:Trend Micro PCI-DSS v3コンテナイメージのコンプライアンス
    • NIST 800-190:Trend Micro NIST 800-190コンテナイメージのコンプライアンス
    • HIPAA:Trend Micro HIPAAコンテナイメージのコンプライアンス

    重大度は次のとおりです。

    • defcon1
    • 重大以上
    • 高以上
    • 中以上
    • 低または高
    • 無視できる程度以上
    • 任意

    一部のチェックリストには、これらの重大度レベルのすべてが含まれているわけではありません。たとえば、PCI-DSS v2チェックリストには現在、低から高の範囲のルールがあります。NIST 800-190チェックリストには、現在、重要度の高いルールのみが含まれています。HIPAAプロファイルには現在、中および高の重要度のルールがあります。

除外

除外 セクションを使用して、他の連続ルールをオーバーライドする除外を追加します。たとえば、「dev」を含む名前のイメージをブロックする継続ルールがあり、「devone」というイメージを許可する場合は、「名前がdevoneと等しいイメージ」の除外を追加します。

次のような例外が考えられます。

  • 指定された条件を満たす名前のレジストリのイメージを許可する
  • 指定された条件を満たす名前のイメージを許可する
  • 指定された条件を満たすタグを含む画像を許可します

ランタイムルール

[Runtime] タブで、ポッドの実行中に適用するルールを含むルールセットを 1 つ以上追加します。ルールを適用するPodを制御するラベルを追加する方法など、ランタイムセキュリティを有効にしてルールセットを定義する方法については、「ランタイムセキュリティの設定」を参照してください。