Policiesは、Kubernetesクラスタでの実行を許可するルールを定義します。
保護するクラスタごとに1つのポリシーを定義し、クラスタ全体に適用される初期設定のルールセット (「ポリシー定義」とも呼ばれます) を使用します。クラスタに複数の名前空間が含まれている場合は、名前空間に対して個別のルールセットを定義することもできます。名前空間ルールは、クラスタ全体のルールよりも優先されます。
ヒント
ヒント
最初に、ログのみのルールを含むポリシーを作成することをお勧めします。ポリシーが想定どおりに機能していることを確認したら、ポリシーに違反するオブジェクトをブロックするようにルールを変更します。
関連情報

クラスタのポリシーを定義する 親トピック

手順

  1. Trend Micro Cloud Oneコンソールを開き、[Container Security]を選択します。
  2. icon-policies=d9358477-ccd2-4dd4-9c6a-119b9826f64d.png Policiesページに移動します。
  3. 次のいずれかを実行します。
    • このポリシーが最初のポリシーである場合は、[+ New policy] をクリックします。
      policy-first=655b430a-e6c0-4104-a786-54c2e281565e.png
    • このポリシーが最初のポリシーでない場合は、[+ New] をクリックします。
      policy-example-empty=9492d289-c2b2-45e7-8e03-64b67cd471a3.png
  4. ポリシーの一意の [名前] を指定して、ポリシーの目的を特定し、必要に応じて [説明]を追加します。
  5. [Cluster-Wide Policy Definition] で、このポリシーに適用するルールを設定します。3つの異なる種類のルールに対応する3つのタブがあります。
    • [Deployment:] これらのルールは、イメージのデプロイ時に適用されます。適用するルールのチェックボックスをオンにし、ドロップダウンを使用して、ルールに違反した場合の処理 (イベントのログへの記録およびデプロイメントの許可) またはデプロイメントのブロックを選択します。
    • [Continuous:] これらのルールは、ポッドの実行中に定期的にチェックされます。適用するルールのチェックボックスをオンにし、ドロップダウンを使用して、ルール違反時の処理を選択します。イベントをログに記録して、ポッドの実行を継続するか、ポッドのネットワークトラフィックを隔離するか、またはポッドを終了するかを選択します。
    • [Runtime:] このタブで、ポッドの実行中に適用するルールを含むルールセットを1つ以上追加します。ランタイムセキュリティを有効にしてルールセットを定義する方法については、ランタイムセキュリティの構成 を参照してください。ルールセットは、実行時にポッドがルールに違反した場合に Container Security が実行する処理も定義します。ログにイベントを記録し、ポッドの実行を許可するか、ポッドのネットワークトラフィックを隔離するか、またはポッドを終了するかを選択します。
    ルールの詳細については、ルールについてを参照してください。
    デプロイメントルールと継続ルールは、特定の組み合わせで配信する必要があります。
    デプロイメントアクション
    継続的な処理
    ログ
    ログ
    block (ブロック)
    ログ
    block (ブロック)
    隔離
    block (ブロック)
    終了
    Container SecurityにはデフォルトのRuleもあります。詳細については、信頼されたイメージを参照してください。
  6. ポリシーを確定するには、[Create]を選択します。

クラスタにポリシーを割り当てる 親トピック

注意
注意
このセクションでは、クラスターを追加したことを前提としています。

手順

  1. icon-clusters=a22bb538-bab2-4494-8f14-d6dba6b2f0da.pngClustersページに移動します。
  2. ポリシーを適用するKubernetesクラスタを選択します。
  3. [Policy]リストからポリシーを選択してください。
  4. [保存]を選択します。

名前空間のポリシー定義を追加する 親トピック

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

手順

  1. icon-policies=d9358477-ccd2-4dd4-9c6a-119b9826f64d.pngPoliciesページで、既存のクラスター全体のポリシーの名前を選択します。
  2. Policy Definitionsセクションで、[Cluster-Wide Policy Definition]見出しの横にある[+]を選択します。
    policy-add-namespace=3648169d-659a-41dd-9d00-df2383e264a7.png
  3. ページの一番下までスクロールし、新しく追加されたセクションでicon-expand=f50958af-e430-4892-97ed-45a64b0f2820.pngを選択してください。
  4. ポリシーの目的の識別に役立つ一意の [名前] を指定します。
  5. [Namespaces]領域で、この新しいポリシーで保護する1つ以上のKubernetes名前空間を追加します。
  6. 必要に応じて、対応するタブを使用してデプロイメントルール、継続ルール、およびランタイムルールを設定します。適用するルールのチェックボックスをオンにし、ドロップダウンを使用して、オブジェクトがルールに違反した場合の処理を選択します。ルールの詳細については、ルールについてを参照してください。
  7. [保存]を選択します。
    別の名前空間ルールセットを追加する場合は、[+] を選択して新しい名前空間ポリシー定義セクションを追加します。

名前空間を保護する 親トピック

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

手順

  1. 保護したいネームスペースのためにネームスペースのポリシーを作成します。
  2. Kubectlアクセスルールを有効にします。
    kubectl=f7e3d0c8-287f-41c7-9928-b530b2b0d7aa.png

ポリシーをテストする 親トピック

ポリシーを作成して設定したら、 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
    注意
    注意
    このポッドの定義では、securityContext は privileged = 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コンソールのicon-events=9cafd656-0809-4a99-b385-37f2bc34811a.png[イベント]ページに移動すると、対応するイベントが表示されます。
    event-block-deployment=9c2aaf4f-6793-496e-b352-1be1ddc2219a.png

ルールについて 親トピック

デプロイメントルール 親トピック

イメージがデプロイされようとしているとき、または処理が適用されようとしているときに、[展開]タブのルールが適用されます。これらのルールに基づいて、[Log] (および許可) または[ブロック]のデプロイメントを選択できます。
プロパティ
説明
Podプロパティ
  • rootとして実行されるコンテナ
  • ホストネットワークの名前空間で実行されるコンテナ
  • ホストIPC名前空間で実行されるコンテナ
  • ホストPID名前空間で実行されるコンテナ
コンテナプロパティ
  • rootとして実行されるコンテナ
  • 特権コンテナ
  • 権限昇格権限を持つコンテナ
  • ルートファイルシステムに書き込み可能なコンテナ
  • 事前定義されたポリシーに違反する機能を持つコンテナ
    使用可能な機能ポリシーは次のとおりです。
    • restrict-nondefaults: [初期設定のDocker機能](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) のいずれかの機能を許可します。
    • 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機能を削除することをお勧めします。
    Trend Microは、コンテナのニーズを考慮し、最小の権限の原則に沿って機能ポリシーを適用することをお勧めします。
    機能ポリシーとポッドセキュリティのベストプラクティスの詳細については、[Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) を参照してください。
イメージプロパティ
  • レジストリのイメージ指定された条件を満たす
  • 指定の条件を満たす名前のイメージ
  • 指定の条件を満たすタグが付いた画像
検索結果
以下のルールはトレンドマイクロArtifact Scanner (TMAS)によってサポートされています:
  • 検索されていないイメージ
  • 不正プログラムを含むイメージ
  • 重大度レベルの脆弱性を持つイメージ
  • CVSS攻撃元区分が vector で、重大度が severityの脆弱性のあるイメージ
    攻撃元区分の詳細については、CVSS仕様の攻撃元区分 (AV)を参照してください。
    使用可能なベクターは次のとおりです。
    • ローカルまたは物理
    • 隣接
    • ネットワーク
    重大度は次のとおりです。
    • 重大以上
    • 高以上
    • 中以上
    • 低または高
    • 無視できる以上
    • 任意
  • CVSS攻撃の複雑さが 複雑 であり、重大度が 重大である脆弱性のある画像
    攻撃条件の複雑さの詳細については、[CVSS仕様の攻撃条件の複雑さ (AC)](https://www.first.org/cvss/specification-document#2-1-2-Attack-Complexity-AC) を参照してください。
    考えられる複雑さは次のとおりです。
    • 高
    • 低
    重大度は次のとおりです。
    • 重大以上
    • 高以上
    • 中以上
    • 低または高
    • 無視できる以上
    • 任意
  • CVSSの可用性への影響が impact であり、重大度が 重大である脆弱性のあるイメージ
    可用性への影響については、CVSS仕様の可用性 (A)を参照してください。
    考えられる影響は次のとおりです。
    • 高
    • 低
    重大度は次のとおりです。
    • デフコン1
    • 重大以上
    • 高以上
    • 中以上
    • 低または高
    • 無視できる以上
    • 任意
Kubectlアクセス
これらのルールを使用して名前空間ポリシーを設定し、Container Securityなどの特殊な権限を持つコンテナを保護することをお勧めします。
  • コンテナへの実行の試み
  • コンテナでポート転送を確立しようとする試み
除外
[除外] セクションを使用して、他のデプロイメントルールをオーバーライドする除外を追加します。たとえば、「dev」を含む名前のイメージをブロックするが、「devone」というイメージを許可するデプロイメントルールがある場合は、「名前がdevoneと等しいイメージ」の除外を追加します。
次のような例外が考えられます。
  • 指定された条件を満たす名前のレジストリのイメージを許可する
  • 指定された条件を満たす名前のイメージを許可する
  • 指定された条件を満たすタグを含む画像を許可します

継続ルール 親トピック

[Continuous] タブのルールは、ポッドの実行中に定期的に確認されます。[Log] を選択して実行を継続するか、 [Isolate] するか、ルールに違反した場合はポッドを [Terminate] することもできます。
   
Podプロパティ
  • rootとして実行されるコンテナ
  • ホストネットワークの名前空間で実行されるコンテナ
  • ホストIPC名前空間で実行されるコンテナ
  • ホストPID名前空間で実行されるコンテナ
コンテナプロパティ
  • rootとして実行されるコンテナ
  • 特権コンテナ
  • 権限昇格権限を持つコンテナ
  • ルートファイルシステムに書き込み可能なコンテナ
  • 事前定義されたポリシーに違反する機能を持つコンテナ
    使用可能な機能ポリシーは次のとおりです。
    • restrict-nondefaults: [初期設定のDocker機能](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) のいずれかの機能を許可します。
    • baseline: 初期設定の機能は許可されますが、NET_RAW機能は許可されません。
    • Restricted: NET_BIND_SERVICE機能のみを許可します。
    • restrict-all: 機能を許可しません。
    コンテナ機能ルールの詳細については、上記のデプロイメントルールのコンテナプロパティにある対応するルールを参照してください。
イメージプロパティ
  • レジストリのイメージ指定された条件を満たす
  • 指定の条件を満たす名前のイメージ
  • 指定の条件を満たすタグが付いた画像
除外
[除外] セクションを使用して、他の連続ルールをオーバーライドする除外を追加します。たとえば、「dev」を含む名前のイメージをブロックする継続ルールがあり、「devone」というイメージを許可する場合は、「名前がdevoneと等しいイメージ」の除外を追加します。
次のような例外が考えられます。
  • 指定された条件を満たす名前のレジストリのイメージを許可する
  • 指定された条件を満たす名前のイメージを許可する
  • 指定された条件を満たすタグを含む画像を許可します

ランタイムルール 親トピック

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