ポリシーを作成する
Policies は、Kubernetesクラスターで実行できるものを制御するために使用されるルールを定義します。
保護するクラスタごとに1つのポリシーを定義し、クラスタ全体に適用される初期設定のルールセット(「ポリシー定義」とも呼ばれます)を使用します。クラスタに複数の名前空間が含まれている場合は、名前空間に対して個別のルールセットを定義することもできます。名前空間ルールは、クラスタ全体のルールよりも優先されます。
最初に、ログのみのルールを含むポリシーを作成することをお勧めします。ポリシーが想定どおりに機能していることを確認したら、ポリシーに違反するオブジェクトをブロックするようにルールを変更します。
クラスタのポリシーを定義する
- Trend Micro Cloud One console を開き、[ Container Security]を選択します。
Policies ページに移動します。
- 次のいずれかを実行します。
- これが最初のポリシーである場合は、[+ New policy]をクリックします。
- これが最初のポリシーでない場合は、[+ New]を選択します。
- これが最初のポリシーである場合は、[+ New policy]をクリックします。
- ポリシーの一意の Name を指定して、ポリシーの目的を特定し、必要に応じて Descriptionを追加します。
-
[ Cluster-Wide Policy Definition ]領域で、このポリシーに適用するルールを設定します。3つの異なる種類のルールに対応する3つのタブがあります。
- Deployment: これらのルールは、イメージを配信しようとしているときに適用されます。適用するルールのチェックボックスをオンにし、ドロップダウンを使用して、ルール違反時の処理を選択します。イベントをログに記録する(配信を許可する)か、配信をブロックするかを選択します。
- Continuous: これらのルールは、ポッドの実行中に定期的にチェックされます。適用するルールのチェックボックスをオンにし、ドロップダウンを使用して、ルール違反時の処理を選択します。イベントをログに記録して、ポッドの実行を継続するか、ポッドのネットワークトラフィックを隔離するか、またはポッドを終了するかを選択します。
- Runtime: このタブで、ポッドの実行中に適用するルールを含むルールセットを1つ以上追加します。ランタイムセキュリティを有効にしてルールセットを定義する方法については、 ランタイムセキュリティの構成 を参照してください。ルールセットは、実行時にポッドがルールに違反した場合に Container Security が実行する処理も定義します。ログにイベントを記録し、ポッドの実行を許可するか、ポッドのネットワークトラフィックを隔離するか、またはポッドを終了するかを選択します。
ルールの詳細については、「 ルールについて」を参照してください。
配信ルールと継続ルールは、特定の組み合わせで配信する必要があります。
配信処理 継続的な処理 ログ ログ ブロック ログ ブロック 隔離する ブロック 終了 Container Security にも初期設定ルールがあります。詳細については、「 信頼済みの画像」を参照してください。
-
ポリシーを確定するには、[ Create]を選択します。
クラスタにポリシーを割り当てる
このセクションでは、 がクラスターを追加していることを前提としています。
Clusters ページに移動します。
- ポリシーを適用するKubernetesクラスタを選択します。
- Policy リストからポリシーを選択します。
- [ Save ]を選択します。
名前空間のポリシー定義を追加する
クラスタに複数の名前空間が含まれている場合は、名前空間に対して個別のポリシー定義を作成できます。名前空間ポリシー定義は、クラスタ全体のポリシー定義よりも優先されます。
Policies 画面で、既存のクラスタ全体のポリシーの名前を選択します。
-
[ Policy Definitions ]セクションで、[ Cluster-Wide Policy Definition ]見出しの横にある[ +]を選択します。
-
ページの一番下までスクロールし、追加した新しいセクションで
を選択します。
- ポリシーの目的の識別に役立つ一意の Name を指定します。
- [ Namespaces ]領域で、この新しいポリシーで保護する1つ以上のKubernetes名前空間を追加します。
- 必要に応じて、対応するタブを使用して配信ルール、継続ルール、およびランタイムルールを設定します。適用するルールのチェックボックスをオンにし、ドロップダウンを使用して、オブジェクトがルールに違反した場合の処理を選択します。ルールの詳細については、「 ルールについて」を参照してください。
- [ Save ]を選択します。
別の名前空間ルールセットを追加する場合は、 + を選択して新しい名前空間ポリシー定義セクションを追加します。
名前空間を保護する
Kubernetesの資格情報や不正な役割ベースのアクセス制御による攻撃を防ぐには、これらのコンテナへの特殊な権限でのアクセス試行をログに記録するかブロックするルールを設定することが重要です。trendmicro-system名前空間で有効にすることをお勧めします。
- 作成する名前空間のポリシー保護する名前空間の場合。
-
Kubectlアクセスルールを有効にします。
ポリシーをテストする
ポリシーを作成して必要に応じて設定したら、 Container Security を使用してKubernetesクラスタを保護できます。
配信(kubectl、helmなど)は、配信コントローラによって確認されます。この例では、専用のbusyboxコンテナを配置します。
この例では、特権コンテナルールの処理として[ブロック]が選択されているものとします。
-
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
に設定されています。先に作成したポリシーでは、特権コンテナをブロックするようにポリシーを設定しているため、このポッドがブロックされます。 -
kubectlコンテキストがクラスタに設定されていることを確認します。
-
次のコマンドを使用してポッドを作成します。
$ kubectl apply -f busybox.yaml
-
要求が拒否されたことを確認します。
$ 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).
-
Container Security コンソールの
Events ページに移動すると、対応するイベントが表示されます。
ルールについて
配信ルール
イメージが配信されようとしているとき、または処理が適用されようとしているときに、Deploymentタブのルールが適用されます。これらのルールに基づいて、 Log (および許可)または Block の配信を選択できます。
ポッドのプロパティ
- rootとして実行されるコンテナ
- ホストネットワークの名前空間で実行されるコンテナ
- ホストIPC名前空間で実行されるコンテナ
- ホストPID名前空間で実行されるコンテナ
コンテナのプロパティ
- rootとして実行されるコンテナ
- 特権コンテナ
- 権限昇格権限を持つコンテナ
- ルートファイルシステムに書き込み可能なコンテナ
- 事前定義されたポリシーに違反する機能を持つコンテナ
使用可能な機能ポリシーは次のとおりです。
- 「restrict-nondefaults」:初期設定のDocker機能のいずれかの機能を許可します。
- ベースライン:初期設定の機能は許可されますが、NET_RAW機能は許可されません。
- Restricted:NET_BIND_SERVICE機能のみを許可します。
- すべて制限:機能を許可しません。
NET_RAWは、RAWソケットとPACKETソケットの使用を許可する初期設定の機能です。この機能により、不正なユーザがパケットを偽造したり、MITM攻撃を実行したり、その他のネットワーク攻撃を実行したりする可能性があります。この権限は通常、特定のネットワークのニーズにのみ使用されるため、削除しても大部分のアプリケーションには影響しません。
NET_BIND_SERVICEは、インターネットドメインの特権ポート(1024未満のポート番号)へのバインドを許可する初期設定の機能です。多くの場合、Webサーバで使用され、root以外のユーザにこれらのポートへのアクセス権を付与します。
CIS Kubernetes Benchmarksでは、新しい機能を追加せず、少なくともNET_RAW機能を削除することをお勧めします。
コンテナのニーズを考慮し、最小の権限の原則に沿って機能ポリシーを適用することをお勧めします。
機能ポリシーとポッドセキュリティのベストプラクティスの詳細については、Pod Security Standardsを参照してください。
イメージのプロパティ
- 指定された条件を満たすレジストリのイメージ
- 指定の条件を満たす名前のイメージ
- 指定の条件を満たすタグが付いたイメージ
検索結果
次のルールでは、 Deep Security Smart Checkが必要です。
- 検索されていないイメージ
- 不正プログラムを含むイメージ
- 重大度レベルの内容が検出されたイメージ
- 重大度レベルのチェックリストを持つイメージ
- 重大度レベルの脆弱性を持つイメージ
次のルールでは、 Deep Security Smart Checkの最新バージョンが必要です。
- CVSS攻撃ベクタが ベクタ で、重大度が 重大度の脆弱性のあるイメージ
Attack Vectorの詳細については、CVSS仕様のAttack Vector(AV)を参照してください。
使用可能なベクターは次のとおりです。
- ローカルまたは物理
- 隣接
- ネットワーク
重大度は次のとおりです。
- defcon 1
- 重大以上
- 高以上
- 中以上
- 低または高
- 無視できる程度以上
- 任意
- CVSS攻撃の複雑さが 複雑 であり、重大度が 重大である脆弱性のある画像
攻撃の複雑さの詳細については、CVSS仕様のAttack Attackity(AC)を参照してください。
考えられる複雑さは次のとおりです。
- 高
- 低
重大度は次のとおりです。
- defcon 1
- 重大以上
- 高以上
- 中以上
- 低または高
- 無視できる程度以上
- 任意
- CVSSの可用性への影響が の影響 であり、重大度が の重大である脆弱性のあるイメージ
可用性への影響については、CVSS仕様の可用性(A)を参照してください。
考えられる影響は次のとおりです。
- 高
- 低
重大度は次のとおりです。
- defcon 1
- 重大以上
- 高以上
- 中以上
- 低または高
- 無視できる程度以上
- 任意
- チェックリストの種類 がネガティブのチェックリストで、結果の重大度が 重大であるイメージ
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などの特殊な権限でコンテナを保護するには、これらのルールを使用して名前空間ポリシーを設定することをお勧めします。
- コンテナへの実行の試み
- コンテナでポート転送を確立しようとする試み
除外
除外 セクションを使用して、他の配信ルールをオーバーライドする例外を追加します。たとえば、「dev」を含む名前のイメージをブロックするが、「devone」というイメージを許可する配信ルールがある場合は、「名前がdevoneと等しいイメージ」の除外を追加します。
次のような例外が考えられます。
- 指定された条件を満たす名前のレジストリのイメージを許可する
- 指定された条件を満たす名前のイメージを許可する
- 指定された条件を満たすタグを含む画像を許可します
継続ルール
Continuous タブのルールは、ポッドの実行中に定期的に確認されます。Log を選択して実行を継続するか、 Isolate するか、ルールに違反した場合はポッドを Terminate することもできます。
ポッドのプロパティ
- rootとして実行されるコンテナ
- ホストネットワークの名前空間で実行されるコンテナ
- ホストIPC名前空間で実行されるコンテナ
- ホストPID名前空間で実行されるコンテナ
コンテナのプロパティ
- rootとして実行されるコンテナ
- 特権コンテナ
- 権限昇格権限を持つコンテナ
- ルートファイルシステムに書き込み可能なコンテナ
- 事前定義されたポリシーに違反する機能を持つコンテナ
使用可能な機能ポリシーは次のとおりです。
- 「restrict-nondefaults」:初期設定のDocker機能のいずれかの機能を許可します。
- ベースライン:初期設定の機能は許可されますが、NET_RAW機能は許可されません。
- Restricted:NET_BIND_SERVICE機能のみを許可します。
- すべて制限:機能を許可しません。
コンテナ機能ルールの詳細については、上記の「配信ルールのコンテナプロパティ」にある対応するルールを参照してください。
イメージのプロパティ
- 指定された条件を満たすレジストリのイメージ
- 指定の条件を満たす名前のイメージ
- 指定の条件を満たすタグが付いた画像
検索結果
次のルールでは、 Deep Security Smart Checkが必要です。
- 検索されていないイメージ
- 不正プログラムを含むイメージ
- 重大度レベルの内容が検出されたイメージ
- 重大度レベルのチェックリストを持つイメージ
- 重大度レベルの脆弱性を持つイメージ
次のルールでは、 Deep Security Smart Checkの最新バージョンが必要です。
- CVSS攻撃ベクタが ベクタ で、重大度が 重大度の脆弱性のあるイメージ
Attack Vectorの詳細については、CVSS仕様のAttack Vector(AV)を参照してください。
使用可能なベクターは次のとおりです。
- ローカルまたは物理
- 隣接
- ネットワーク
重大度は次のとおりです。
- defcon 1
- 重大以上
- 高以上
- 中以上
- 低または高
- 無視できる程度以上
- 任意
- CVSS攻撃の複雑さが の複雑 であり、重大度が の重大である脆弱性のある画像
攻撃の複雑さの詳細については、CVSS仕様のAttack Attackity(AC)を参照してください。
考えられる複雑さは次のとおりです。
- 高
- 低
重大度は次のとおりです。
- defcon 1
- 重大以上
- 高以上
- 中以上
- 低または高
- 無視できる程度以上
- 任意
- CVSSの可用性への影響が の影響 であり、重大度が 重大である脆弱性のあるイメージ
可用性への影響については、CVSS仕様の可用性(A)を参照してください。
考えられる影響は次のとおりです。
- 高
- 低
重大度は次のとおりです。
- defcon 1
- 重大以上
- 高以上
- 中以上
- 低または高
- 無視できる程度以上
- 任意
- チェックリストの種類 がネガティブのチェックリストで、結果の重大度が 重大であるイメージ
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と等しいイメージ」の除外を追加します。
次のような例外が考えられます。
- 指定された条件を満たす名前のレジストリのイメージを許可する
- 指定された条件を満たす名前のイメージを許可する
- 指定された条件を満たすタグを含む画像を許可します
ランタイムルール
[ランタイム]タブで、ポッドの実行中に適用するルールを含むルールセットを1つ以上追加します。ルールが適用されるポッドを制御するためのラベルを追加する方法など、ランタイムセキュリティを有効にしてルールセットを定義する方法については、 ランタイムセキュリティの構成 を参照してください。