6.2. カスタムセキュリティーポリシー
デフォルトのポリシーを使用することに加えて、Red Hat Advanced Cluster Security for Kubernetes でカスタムポリシーを作成することもできます。
次の方法を使用してカスタムポリシーを作成できます。
-
RHACS ポータルで、Platform configuration
Policy management に移動し、Create policy をクリックします。 - RHACS ポータルで Risk に移動し、フィルターを使用してポリシーが使用する基準を選択します。Create policy をクリックします。
- ポリシーを Kubernetes カスタムリソース (CR) として保存し、Argo CD などの継続的デリバリーツールを使用してクラスターに適用し、policies as code を作成および管理します。
詳細は、以下のセクションを参照してください。
6.2.1. システムポリシービューからのセキュリティーポリシーの作成
システムポリシービューから新しいセキュリティーポリシーを作成できます。
手順
-
RHACS ポータルで、Platform Configuration
Policy Management に移動します。 - Create policy をクリックします。
- 以下のセクションでポリシー定義情報を設定します。
ポリシー情報を入力します。
Policy details セクションに、ポリシーに関する以下の情報を入力します。
- ポリシーの Name を入力します。
- このポリシーの Severity レベルを選択します。
- ポリシーのポリシーカテゴリーを選択します。これは必須フィールドです。
- Description フィールドに、ポリシーの詳細を入力します。
- Rationale フィールドにポリシーが存在する理由の説明を入力します。
- Guidance フィールドでこのポリシーの違反を解決するための手順を入力します。
MITRE ATT&CK セクションで、ポリシーに指定する tactics and the techniques を選択します。
- Add tactic をクリックし、ドロップダウンリストから調整を選択します。
- Add technique をクリックして、選択した戦略の手法を追加します。戦略には、複数の手法を指定できます。
- Next をクリックします。
ポリシーライフサイクルの設定
Lifecycle セクションで、次の手順を実行します。
ポリシーが適用される Lifecycle stages (Build、Deploy、または Runtime) を選択します。以下の選択肢から複数のステージを選択できます。
- ビルド時ポリシーは、CVE や Dockerfile 手順などのイメージフィールドに適用されます。
- デプロイ時のポリシーにはすべてのビルドタイムポリシー条件を含めることができますが、特権モードで実行したり、Docker ソケットをマウントするなど、クラスター設定からのデータを含めることもできます。
- ランタイムポリシーには、すべてのビルド時およびデプロイ時のポリシー条件を含めることができますが、ランタイム時のプロセス実行に関するデータを含めることもできます。
Runtime lifecycle stage を選択した場合は、以下の Event sources のいずれかを選択する必要があります。
- Deployment: イベントソースにプロセスおよびネットワークアクティビティー、Pod 実行、Pod ポート転送が含まれる場合、RHACS はポリシー違反をトリガーします。
- Audit logs: イベントソースが Kubernetes 監査ログレコードと一致すると、RHACS はポリシー違反をトリガーします。
- Next をクリックします。
ポリシールールおよび基準の設定
ポリシールールを設定するには、以下を実行します。
- Rules セクションで、ポリシーをトリガーする基準を設定します。ルールのタイトルを編集し、Add a new rule をクリックしてさらにルールを追加できます。
ルールごとに、ポリシーフィールドをクリックして Policy Section にドラッグし、ポリシーフィールドまたは基準を追加します。
注記利用可能なポリシーフィールドは、ポリシーに選択したライフサイクルステージによって異なります。たとえば、Kubernetes access policies または Networking の基準は、ランタイムライフサイクルのポリシーを作成するときに使用できますが、ビルドライフサイクルのポリシーを作成するときには使用できません。ポリシー条件の詳細 (条件に関する情報や、条件が使用可能なライフサイクルフェーズなど) は、「関連情報」セクションの「ポリシー条件」を参照してください。
フィールドごとに、フィールドに固有のオプションから選択できます。これらはフィールドの種類によって異なります。以下に例を示します。
- 文字列の値の動作はデフォルトで、ポリシーフィールドに対して照合します。フィールドの照合をさせない場合は、Not をクリックします。
-
一部のフィールドには、
true
またはfalse
のいずれかの値が含まれています。 - 一部のフィールドでは、ドロップダウンリストから値を選択する必要があります。
-
ブール値が
Read-Only Root Filesystem
の属性を選択すると、READ-ONLY
オプションおよびWRITABLE
オプションが表示されます。 環境変数
が複合値の属性を選択すると、Key
、Value
、およびValue From
フィールドの値を入力するオプションと、利用可能なオプションの他の値を追加するアイコンが表示されます。注記詳細は、「関連情報」セクションのポリシー基準を参照してください。
- 属性に複数の値を組み合わせるには、Add アイコンをクリックします。
- Next をクリックします。
ポリシースコープの設定
スコープを作成して、環境内のクラスターや namespace などのエンティティーからポリシーを制限または除外します。
- スコープを指定して制限するには、Add inclusion scope をクリックします。これにより、このポリシーを特定のクラスター、namespace、またはデプロイメントラベルにのみ適用できるようになります。複数のスコープを追加したり、namespaces とラベルの RE2 Syntax で正規表現を使用したりすることもできます。
特定のデプロイメント、クラスター、namespace、デプロイメントラベルをポリシーから除外する場合など、スコープ別に除外するには、Add exclusion scope をクリックします。ポリシーは、選択したエンティティーには適用されません。複数のスコープを追加したり、namespaces とラベルの RE2 Syntax で正規表現を使用したりすることもできます。ただし、デプロイメントの選択に正規表現を使用することはできません。
注記この機能は、デプロイおよびランタイムライフサイクルステージ用に設定されたポリシーでのみ使用できます。
ビルドライフサイクルステージ用に設定されたポリシーの場合、ポリシーからイメージを除外できます。Exclude images (Build lifecycle only) フィールドに、違反をトリガーしないイメージを入力します。
注記Excluded Images 設定は、Build ライフサイクルステージで継続的インテグレーションシステムでイメージを確認する場合にのみ適用されます。このポリシーを使用して、実行中のデプロイメント (Deploy ライフサイクルステージ) またはランタイムアクティビティー (Runtime ライフサイクルステージ) をチェックする場合、効果はありません。
- Next をクリックします。
ポリシーアクションの設定
ポリシーのアクティベーションの状態、適用、および通知を設定します。
- ポリシーのアクティベーションの状態を選択します。
適用方法を選択します。
- Inform: 違反を違反リストに含めます。
- Inform and enforce: アクションを適用します。このオプションを選択した場合は、ライフサイクル別に切り替えて、ポリシーの適用動作を選択する必要があります。選択できる適用動作は、ポリシー定義の Lifecycle セクションでポリシーごとに選択したライフサイクルステージによって異なります。ライフサイクルステージに応じて、以下の適用動作を利用できます。
- Build: イメージがポリシーの基準と一致すると、RHACS は継続的インテグレーション (CI) ビルドに失敗します。
Deploy: Deploy 段階では、RHACS アドミッションコントローラーが設定され実行されている場合、RHACS はポリシーの条件に一致するデプロイメントの作成と更新をブロックします。
- アドミッションコントローラーが適用されているクラスターでは、Kubernetes または OpenShift Container Platform サーバーがすべての非準拠のデプロイメントをブロックします。他のクラスターでは、RHACS は準拠していないデプロイメントを編集して、Pod がスケジュールされないようにします。
- 既存のデプロイメントの場合、ポリシーの変更は、Kubernetes イベントが発生したときに、基準が次に検出されたときにのみ適用されます。適用の詳細は、「デプロイステージのセキュリティーポリシーの適用」を参照してください。
Runtime: Pod 内のイベントがポリシーの基準に一致すると、RHACS はすべての Pod を削除します。
警告ポリシーの適用は、実行中のアプリケーションまたは開発プロセスに影響を与える可能性があります。適用オプションを有効にする前に、すべての利害関係者に通知し、自動適用アクションに対応する方法を計画してください。
ポリシーに通知機能を添付して、ポリシー違反をメールの受信者や、Jira、Splunk、Webhook を使用するその他のアプリケーションなどの外部ツールに送信します。
リストから通知機能を選択します。
注記通知が表示され、リストで選択できるようにするには、事前に通知を設定しておく必要があります。これらのインテグレーションは、Platform Configuration
Integrations ページの Notifier Integrations セクションで設定します。
- Next をクリックします。
ポリシーの確認および違反のプレビュー
設定したポリシー設定を確認します。
- ポリシー設定が正しいオプションで設定されていることを確認します。
Preview violations パネルには、ビルドフェーズまたはデプロイフェーズのデプロイメントにポリシー違反があるかどうかなどの追加情報が提供されます。
注記ランタイム違反は、今後のイベントに応じて生成されるため、このプレビューでは使用できません。
ポリシーを保存する前に、違反が正確であるかどうかを確認してください。
- Save をクリックします。
6.2.1.1. ポリシー条件への論理条件の追加
ドラッグアンドドロップポリシーフィールドパネルを使用して、ポリシー条件に論理条件を指定できます。
前提条件
- Red Hat Advanced Cluster Security for Kubernetes バージョン 3.0.45 以降を使用している。
手順
Policy Criteria セクションで、Add a new condition を選択して、新しいポリシーセクションを追加します。
- Edit アイコンをクリックして、ポリシーセクションの名前を変更できます。
- Drag out a policy field セクションには、複数のカテゴリーで利用可能なポリシー条件がリスト表示されます。これらのカテゴリーを展開したり折りたたんだりして、ポリシー条件属性を表示できます。
- policy セクションの Drop a policy field エリアに属性をドラッグします。
選択する属性のタイプに応じて、選択した属性の条件を設定するオプションが異なります。以下に例を示します。
-
ブール値が
Read-Only Root Filesystem
の属性を選択すると、READ-ONLY
オプションおよびWRITABLE
オプションが表示されます。 環境変数
が複合値の属性を選択すると、Key
、Value
、およびValue From
フィールドの値を入力するオプションと、利用可能なオプションの他の値を追加するアイコンが表示されます。- 属性に複数の値を組み合わせるには、Add アイコンをクリックします。
-
ポリシーセクションでリスト表示されている論理演算子
AND
またはOR
をクリックして、AND
演算子とOR
演算子を切り替えることもできます。演算子間の切り替えは、ポリシーセクション内でのみ機能し、2 つの異なるポリシーセクション間では機能しません。
-
ブール値が
-
これらの手順を繰り返して、複数の
AND
およびOR
条件を指定できます。追加した属性の条件を設定したら、Next をクリックしてポリシーの作成を続行します。
6.2.2. リスクビューからのセキュリティーポリシーの作成
リスク ビューで展開のリスクを評価しているときに、ローカルページフィルタリングを適用すると、使用しているフィルタリング条件をもとに新しいセキュリティーポリシーを作成できます。
手順
- RHACS ポータルに移動し、ナビゲーションメニューから Risk を選択します。
- ポリシーを作成するローカルページのフィルタリング条件を適用します。
- New Policy を選択し、必須フィールドに入力して新規ポリシーを作成します。
関連情報
6.2.3. 既存のセキュリティーポリシーの変更
作成したポリシーと、クローンした Red Hat Advanced Cluster Security for Kubernetes によって提供される既存のデフォルトポリシーを編集できます。
手順
-
RHACS ポータルで、Platform Configuration
Policy Management に移動します。 - Policies ページから、編集するポリシーを選択します。
Actions
Edit policy を選択します。 注記デフォルトのポリシーは編集できません。デフォルトポリシーを複製し、複製したポリシーを編集する必要があります。
- 変更するフィールドを編集し、Save をクリックします。
6.2.4. polices as code の管理
ポリシーを Kubernetes カスタムリソース (CR) として保存し、Argo CD などの Kubernetes ネイティブの継続的デリバリー (CD) ツールを使用してクラスターに適用することで、policies as code を作成および管理できます。
Policy as code はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat では、実稼働環境での使用を推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
RHACS では、デフォルトのポリシーの使用やシステム用のカスタムポリシーの作成が可能です。policy as code 機能を使用すると、カスタムポリシーをローカルで作成し、Argo CD などの継続的デリバリーツールを使用して、RHACS を実行しているクラスターに対して、ポリシーの追跡、管理、適用が可能になります。API を使用して、GitHub などの独自の GitOps リポジトリーへの接続を設定することもできます。ローカルでポリシーを作成するには、ポリシーの望ましい状態を表す CR を作成します。CR を作成または更新し、CI/CD ツールを使用して適用すると、RHACS データベースに保存されているポリシーが作成または更新されます。
policy as code は、RHACS ポータルを使用する代わりに、YAML または JSON でポリシーを作成する Kubernetes セキュリティーアーキテクトにとって便利です。GitOps ワークフローを使用して Kubernetes 設定をすでに管理している GitOps 管理者にとっても、これは便利です。
RHACS は、Central がインストールされている namespace (通常は stackrox
namespace) に新しい設定コントローラーをインストールします。Argo CD ワークフローでは、Kubernetes API を使用して、stackrox
namespace 内のこのコントローラーと通信するように Argo CD を設定します。この接続を設定すると、RHACS のコントローラーは、個別の Kubernetes CR ファイルとして管理される新規、更新、または削除されたポリシーに関する情報を Kubernetes API から受信します。RHACS は、ポリシー CR を RHACS データベースに保存されているポリシーと調整します。
Argo CD を使用しない GitOps ワークフローでは、RHACS API を介して RHACS の Central に接続するように GitOps リポジトリーを設定します。CR は使用されません。
6.2.4.1. ポリシードリフトについて
ポリシーは RHACS ポータルで編集、削除、および作成でき、外部からも作成できるため、ポリシーのドリフト が発生する可能性があります。ドリフトは、RHACS の Central のポリシーのバージョンが Kubernetes のポリシーのバージョンと一致しない場合に発生します。
ドリフトは、Kubernetes カスタムリソースを変更する代わりに、RHACS ポータルまたは API を使用して外部で管理されているポリシーに変更を適用したときに発生する可能性があります。RHACS はドリフトを防ぐことができず、(手動での変更は可能であるが) RHACS を使用した変更は推奨されません。ドリフトは、導入後 10 時間以内に自動的に解決されます。
6.2.4.2. RHACS ポータルを使用したコードでのポリシーの作成
RHACS ポータルを使用して既存のポリシーを YAML ファイルとして保存することで、コード内に新しいポリシーを作成できます。
前提条件
- RHACS リリース 4.6 以降がインストールされている。
マニフェストインストールメソッド (
roxctl
メソッドとも呼ばれます) を使用して RHACS をインストールした場合は、次のコマンドを使用して、helm/chart/crds/config.stackrox.io_securitypolicies.yaml
の .zip ファイルにあるconfig.stackrox.io
CRD を手動で適用する必要があります。$ kubectl create -f helm/chart/crds/config.stackrox.io_securitypolicies.yaml
手順
RHACS ポータルを使用して CR を作成し、コードで新しいポリシーを作成するには以下を実行します。
Policy Management ページで、新しいポリシーを作成するか、デフォルトポリシーのクローンを作成します。
注記デフォルトポリシーを CR として保存する前に、そのポリシーを複製する必要があります。
-
ポリシーが表示されている行のオーバーフローメニュー (
) をクリックしてから、Save as Custom Resource を選択します。複数のポリシーを一度に保存するには、それらを選択して、Bulk actions
Save as Custom Resources をクリックします。 ポリシーを編集した後、次のいずれかの方法で保存した CR を適用できます。
-
oc apply
またはkubectl apply
コマンドを使用して、Central がインストールされている Kubernetes namespace に CR を直接適用します。 - Argo CD または GitOps ツールを使用して、Central がインストールされている Kubernetes namespace に CR をプッシュします。
-
6.2.4.3. CR を構築することによるコードでのポリシーの作成
ポリシーの CR を構築することで、コード内に新しいポリシーを作成できます。
エディターを使用して、次の属性のポリシーの CR を作成します。
kind: SecurityPolicy apiVersion: config.stackrox.io/v1alpha1 metadata: name: short-name spec: policyName: A longer form name # ...
ヒントポリシー仕様を定義するために使用できるフィールドを理解するには、
kubectl explain securitypolicy.spec
などのコマンドを入力してオンラインドキュメントを使用します。次のいずれかを実行して、保存された CR を適用します。
-
oc apply
またはkubectl apply
コマンドを使用して、Central がインストールされている Kubernetes namespace に CR を直接適用します。 - Argo CD または GitOps ツールを使用して、Central がインストールされている Kubernetes namespace に CR をプッシュします。
-
6.2.4.4. policy as code 機能の無効化
policy as code 機能は、RHACS をインストールすると自動的に有効になりますが、無効にすることもできます。
手順
policy as code 機能を無効にするには、RHACS のインストールに使用した方法に応じて、次のいずれかのタスクを実行します。
-
Operator を使用して RHACS をインストールした場合は、
spec.configAsCode.configAsCodeComponent
フィールドをEnabled
に設定します。 -
Helm チャートを使用して RHACS をインストールした場合は、
values.yaml
ファイルのconfigAsCode.enabled
フィールドをtrue
に設定します。 マニフェストインストールメソッド (
roxctl
メソッドとも呼ばれます) を使用して RHACS をインストールした場合は、次のコマンドを実行してconfig-controller
デプロイメントを削除します。$ kubectl -n stackrox delete deployment config-controller 1
- 1
- OpenShift Container Platform の場合は、
kubectl
の代わりにoc
を使用します。