第5章 ポリシーを使用したセキュリティーの提供


5.1. RHACS のポリシーについて

Red Hat Advanced Cluster Security for Kubernetes (RHACS) は、堅牢なポリシーエンジンとアドミッションコントローラーを使用することで、コンテナーインフラストラクチャーのセキュリティー確保を支援します。RHACS を使用すると、適切なセキュリティーガードレールを確立し、ポリシー違反について通知して、セキュアでない状況を防ぐためにポリシーを選択的に適用することができます。

具体的には、RHACS は、ビルドステージで CI パイプラインを失敗させ、デプロイメントステージでデプロイメントがデプロイされるのを拒否し、ランタイムポリシーに違反する実行中のデプロイメントをシャットダウンするのに役立ちます。RHACS は、次のセクションで説明するポリシー管理および違反管理ツールも提供します。

5.1.1. RHACS ポリシー評価エンジンについて

RHACS ポリシーエンジンは、ポリシー基準に基づいて作成したポリシーを評価します。ビルド、デプロイ、ランタイムの各ステージで動作が異なります。

ビルドステージ

RHACS は、roxctl CLI を使用して、リクエストに応じてポリシールールを評価できます。ビルド段階でポリシーに違反すると、違反テキストとエラーコードによって開発者は何が失敗したのか、そしてどのように修正すればよいのかを知ることができます。パイプラインを失敗させるエラーコードを設定できます。このステージでは、RHACS はスタンドアロンイメージとデプロイメントの両方を適用可能なポリシーに照らして評価できます。ビルドステージからの違反は、通知機能を使用して保存またはルーティングされません。

デプロイ段階

RHACS は、デプロイメントの試行中にワークロードを検査するときに、デプロイメントステージポリシーを使用します。これらのポリシーは、次のようなワークロード基準で構成されます。

  • 環境変数や特権を含むコンテナー設定
  • 必須または許可されていないアノテーションやラベルなどのデプロイメントメタデータ
  • ボリューム名やマウント設定などのストレージボリューム情報
  • ポート公開と Ingress または Egress ポリシーなどのネットワーク設定
  • サービスアカウント設定やロールベースのアクセス制御 (RBAC) 権限などの基準で構成される Kubernetes アクセス設定

デプロイステージポリシーをビルドするときに、イメージレジストリー、イメージコンテンツ、CVE データなどのイメージ基準を含めることもできます。これは、パイプラインのビルドとデプロイメントの試行の両方で同じ要件を評価する場合に役立ちます。これにより、イメージとワークロードの両方の基準を含むポリシーを作成し、それをビルドステージとデプロイステージの両方で使用できるため、ポリシーを重複させる必要がなくなります。

RHACS は、Kubernetes または OpenShift Container Platform が、ポリシーの基準に一致するデプロイメント、デーモンセット、ジョブなどのワークロードが作成または更新されないようにします。これは、ビルドが成功した場合でも、重大な問題のあるデプロイメントをシャットダウンする場合に役立ちます。

ランタイムステージ

RHACS は、デプロイメントが実行された後も、適用可能なポリシーに対してデプロイメントを継続的に評価します。ランタイムポリシーは、Kubernetes クラスター内で実行中の Pod を監視し、許可されていないワークロードアクティビティー、ベースラインからの逸脱、または禁止されている Kubernetes リソース操作を報告または防止するために使用されます。RHACS は、安全でない Kubernetes リクエストを監視し、API を使用してそれらを選択的にブロックできます。たとえば、RHACS は config map またはシークレットへのアクセス試行をブロックできます。

ランタイムポリシーでは、次の 2 つのイベントソースを検査できます。

  • デプロイメントイベント: 実行中の Pod、Pod 内のプロセスアクティビティー、ネットワークまたはプロセスのベースラインからの逸脱、ポート転送やポート実行アクションなどのユーザーと Pod の相互作用などのリアルタイムイベント
  • 監査ログイベント: 機密性の高い Kubernetes リソースへのアクセスなどのアクションを検査できるログ

ランタイムポリシーには、次の理由により、ビルドステージとデプロイステージの基準も含めることができます。

  • これらの基準は、ランタイムとワークロード/イメージの基準を組み合わせて、リスクの高い状況を識別するために使用できます。
  • これらの基準により、ビルド段階やデプロイ段階での要件が、ランタイムにおいても確実に満たされるようにすることができます。たとえば、新しい脆弱性が発見された場合や、新たな要件が導入された場合などです。

監査ログポリシーは、シークレットや ClusterRoleBinding などの機密性の高い Kubernetes リソースに関連するアクションについて Kubernetes 監査ログを検査するために使用されます。これには、次のような特徴があります。

  • 監査ログポリシーは、監査ログ基準のみで構成されます。
  • イメージやデプロイメントとは関連付けられていません。このため、監査ログポリシーはランタイムライフサイクルステージにのみ関連付けることができます。
  • 監査対象のアクションはすでに発生しているため、これらのポリシーは適用できません。

5.1.2. ポリシーの適用について

RHACS でポリシーを設定する場合、セキュリティーポリシーに違反する状態を検出したときに RHACS がどのように応答するかを設定できます。

RHACS を使用すると、開発ライフサイクルのすべてのフェーズ (ビルド、デプロイ、ランタイム) でセキュリティーポリシーを適用できます。

RHACS は、次の 2 種類のポリシー適用を提供します。

  • Sensor 適用: ソフト 適用とも呼ばれ、ワークロードが検査され、ポリシーに違反している場合、Sensor は Kubernetes API を使用して Pod をスケールダウンします。
  • アドミッションコントローラーの適用: ハード 適用とも呼ばれるアドミッションコントローラーは、検証 Webhook および Kubernetes API サーバーと連携して、適用されたポリシーに違反するワークロードのアドミッションまたは更新の試行をブロックします。デプロイまたは更新のリクエストが行われると、検証 Webhook はアドミッションコントローラーと通信し、アドミッションコントローラーはポリシーが適用されているかどうかに基づいてアクションを許可またはブロックして応答します。API サーバーは、ポリシーに違反しているかどうか、およびポリシーが適用されているかどうかに基づいて、リクエストを受け入れるか拒否します。

アドミッションコントローラーの適用の詳細は、「アドミッションコントローラーの適用について」を参照してください。

5.1.2.1. ビルドステージの適用

RHACS はビルドステージポリシーを使用して、コードがデプロイされる前にセキュリティー違反を検出し、対応します。ビルドステージポリシーは、イメージレジストリー、イメージコンテンツ、スキャン結果とステータスを含む CVE データなどのイメージ基準のみで構成されます。

RHACS は、roxctl image check コマンドと roxctl deployment check コマンドを使用してビルドをチェックします。イメージがポリシーの基準に一致する場合に継続的インテグレーション (CI) ビルドを失敗するように RHACS を設定できます。つまり、ビルドにポリシーに違反する条件がある場合、たとえば、重大度レベルの修正可能な CVE があり、その条件に対してポリシーを設定している場合、ビルドは失敗します。

たとえば、RHACS を設定してイメージまたはデプロイメントをチェックし、そのチェックを継続的インテグレーション/継続的開発 (CI/CD) パイプラインに統合できます。次に、RHACS がポリシーが失敗することを意味する条件を検出すると、RHACS API はゼロ以外の終了コードを返します。これらの違反は RHACS によって収集または対処されるのではなく、CI/CD ツールで使用されます。たとえば、違反が報告された場合にビルドプロセスを失敗させるなど、その結果に基づいて動作するように CI/CD ツールを設定します。

5.1.2.2. デプロイステージの適用

Red Hat Advanced Cluster Security for Kubernetes は、デプロイ時のポリシーに対して、アドミッションコントローラーによるハードな適用と RHACS Sensor によるソフトな適用という 2 つの形式のセキュリティーポリシー適用をサポートしています。アドミッションコントローラーは、ポリシーに違反するデプロイメントの作成または更新をブロックします。アドミッションコントローラーが無効になっているか利用できない場合、Sensor は、ポリシーに違反するデプロイメントのレプリカを 0 にスケールダウンすることによって、適用を実行できます。

警告

ポリシーの適用は、実行中のアプリケーションまたは開発プロセスに影響を与える可能性があります。適用オプションを有効にする前に、すべての利害関係者に通知し、自動適用アクションに対応する方法を計画してください。

5.1.2.2.1. ハードエンフォースメント

ハードエンフォースメントは、RHACS アドミッションコントローラーによって実行されます。アドミッションコントローラーによる適用が有効なクラスターでは、Kubernetes または OpenShift Container Platform API サーバーが、すべての非準拠のデプロイメントをブロックします。アドミッションコントローラーは、CREATEUPDATE、および SCALE 操作をブロックします。デプロイ時の適用が有効に設定されたポリシーを満たす Pod の作成、更新、またはスケーリングのリクエストはすべて失敗します。アドミッションコントローラーは、ランタイム適用が設定されたポリシーに対して、pod execport forward などのユーザーが開始したコンテナーコマンドもブロックします。

注記

Kubernetes アドミッション Webhook は、CREATEUPDATEDELETE、および CONNECT 操作のみをサポートします。RHACS アドミッションコントローラーは、CREATEUPDATE、および SCALE 操作のみをサポートします。kubectl patchkubectl setkubectl scale などの操作は、UPDATE 操作ではなく PATCH 操作です。Kubernetes では PATCH 操作がサポートされていないため、RHACS は PATCH 操作の適用を実行できません。ただし、SCALE 操作に対する適用はサポートされています。

厳格な適用を行う場合は、RHACS でクラスターの適用設定を有効にします。適用が有効になっていることを確認するには、Dynamic configuration セクションの Admission controller enforcement behavior フィールドで、Enforce policies が選択されていることを確認します。さらに、適用するポリシーごとに、ポリシーを設定するときに Inform and enforce を選択します。

5.1.2.2.2. アドミッションコントローラーの適用からの namespace の除外

デフォルトでは、Red Hat Advanced Cluster Security for Kubernetes (RHACS) は、アドミッションコントローラーの検証 Webhook 設定から特定の管理 namespace を除外します。これらの管理 namespace から発生するレビューリクエストに対しては、ポリシーの評価と適用は実行されません。これらの namespace の一部の項目は、RHACS が正しく動作するためにデプロイする必要があるため、除外されます。

RHACS アドミッションコントローラーは、namespace を除外することに加えて、システム namespace 内の Kubernetes ServiceAccount から発生するリクエストもバイパスします。

注記

選択した継続的デプロイメントツールをデプロイするための namespace を選択するときは、この要素を考慮してください。

次の namespace はデフォルトで除外されます。

  • stackrox
  • kube-system
  • kube-public
  • istio-system

Kubernetes のセキュアクラスターへの Helm インストールにおいて、values-public.yaml ファイルを設定することで、検証 Webhook 設定から除外される namespace をカスタマイズできます。admissionControl.namespaceSelector フィールドでは、除外する namespace を指定できます。以下の例を参照してください。

...
admissionControl:
   namespaceSelector:
    matchExpressions:
    - key: namespace.metadata.stackrox.io/name
      operator: NotIn
      values:
        - stackrox
        - kube-system
        - kube-public
        - istio-system
        - example-namespace
...
Copy to Clipboard Toggle word wrap

ここでは、以下のようになります。

example-namespace
除外する namespace を示します。
5.1.2.2.3. 既存のデプロイメントへのエンフォースメント

既存のデプロイメントの場合、ポリシーの変更は、Kubernetes イベントが発生したときに、基準が次に検出されたときにのみ適用されます。ポリシーに変更を加えた場合は、Policy Management を選択し、Reassess All をクリックしてポリシーを再評価する必要があります。このアクションは、新しい受信 Kubernetes イベントがあるかどうかに関係なく、すべての既存のデプロイメントにデプロイポリシーを適用します。ポリシーに違反があった場合は、RHACS がエンフォースメントを実行します。

5.1.2.2.4. ソフトな適用

ソフトな適用は RHACS Sensor によって実行されます。このエンフォースメントにより、操作が開始しなくなります。ソフトな適用では、Sensor はレプリカを 0 にスケーリングし、Pod がスケジュールされるのを防ぎます。このエンフォースメントでは、クラスター内で準備ができていないデプロイメントが使用可能になります。

これは設計によるもので、Sensor は、デプロイメントを再びスケールダウンさせるための更新リクエストがトラップするのを防ぐため、このソフトな適用を一度だけ実行します。

ソフトな適用が設定されていて、Sensor がダウンしている場合、RHACS は適用を実行できません。

5.1.2.3. ランタイム適用

ランタイムに適用されるポリシーを設定して、ポリシーに違反する Pod を終了したり、監査ログ検査の場合は、ポリシーに違反しているがすでに発生してログに記録されているイベントを通知したりできます。

ポリシー違反が適用されると、次の 1 つ以上のアクションが実行されます。

  • 問題のある Pod をシャットダウンすると、その代わりに別の正常な Pod が作成される
  • RHACS が特定の Kubernetes API 呼び出しを傍受し、阻止する
重要

イメージまたはワークロードルールによって違反がトリガーされると、違反アラートが生成されますが、Pod は 中断されません

5.1.3. RHACS ポリシー構造

RHACS ポリシーは、セキュリティールールと、これらのルールに違反したときに RHACS が実行するアクションを定義する構造化テキストオブジェクトです。

RHACS ポリシーには次の部分が含まれます。

  • ポリシー定義: 次のコンポーネントを含むポリシーのメタデータとそのルールを指定します。

    • ポリシーの詳細: 修復プロセスでポリシーとエンドユーザーを管理するポリシー作成者を支援するテキスト。
    • ライフサイクル: ポリシーがいつ評価されるかを決定する基本的なポリシー属性。
    • ポリシールール: 暗黙的な OR と共に使用される条件のセット (例: ルール 1 または ルール 2)。各ルールは、ポリシー基準と呼ばれる事前定義された構成要素で構成されており、それらは AND 関係 (例: 基準 A and 基準 B) を使用します。RHACS では、潜在的に複雑になりがちな Kubernetes の条件をユーザーに指定させる代わりに、直感的なテキストを使用してユーザーが望む条件を記述できるようになっています。

      ほとんどの RHACS 基準は、ポリシーをトリガーする条件を設定し、多くの基準に NOT フォームが含まれています。ただし、肯定的で期待される動作を定義するためにいくつかの基準が設計されています。基準は、ポリシーユーザーにとってポリシーの作成が直感的になるように設計されているため、肯定的な条件用に設計されているか否定的な条件用に設計されているかはコンテキストによって異なります。次の例は、ポリシー基準の否定形式と肯定形式を示しています。

    • 否定形式: 特定の gcr.io レジストリーが使用されている場合、Container Registry name is <gcr.io> がトリガーされます。したがって、許可されたレジストリーである quay.io 以外のレジストリーが使用されている場合、Container Registry name is NOT <quay.io> がトリガーされます。これは一般化されたルールです。
    • 否定形式: 設定に liveness probe がない場合、Liveness probe is <Not Defined> がトリガーされます。Liveness probe is <Defined> は、準拠しているすべてのワークロードについて、通知機能を使用してポジティブな通知を受け取るために使用できます。
    • 肯定形式: Drop capabilities, Capabilities that MUST be dropped: <SYS_ADMIN> ルールは、予想される動作を定義します。ワークロードが SYS_ADMIN プロパティーを削除できない場合、ポリシーに違反し、違反アラートがトリガーされます。
  • ポリシーの動作: 特定のスコープに対して RHACS が実行するアクション (通知または適用) を指定します。

    • スコープ: デフォルトでは、RHACS ポリシーは グローバル であり、すべてのセキュアなクラスター、すべての namespace、すべてのワークロードとイメージに適用されます。ポリシースコープは、クラスター、namespace、およびデプロイメントの選択基準の組み合わせを明示的に含めるか除外することによって変更できます。ポリシースコープでは、正規表現を使用して、namespace 名、namespace ラベル、またはデプロイメント名やデプロイメントラベルを選択できます。これらは、新しいクラスターを含むすべてのクラスターに自動的に適用されます。
    • アクション: このセクションでは、ポリシーがアクティブかどうか (例: 有効か無効か)、ポリシーが適用されているかどうか、ルーティングアラートに使用する通知機能を決定します。

5.1.4. ポリシーと違反の管理

ポリシー管理 には、セキュリティーチームが適切なガードレールを確立するために実行する一連のアクティビティーが含まれます。これらのアクティビティーはすべて、ポリシーが評価される に行われます。違反管理 とは、セキュリティーチームと開発者チームが、セキュリティーインシデントへの対処を支援し、ポリシー違反を修正するために行う、一連のアクティビティーです。これらすべてのアクティビティーは、ポリシーに違反した後に発生します。

5.1.4.1. ポリシールールの設定

Policy as Code を使用することで、RHACS はポリシーの内部ソースと外部ソースの両方をサポートします。外部ポリシーを使用する場合、RHACS は Kubernetes ネイティブのカスタムリソース (CR) を定義し、OpenShift Pipelines や Argo CD などのツールを使用して Policy as Code を効率化します。

RHACS を使用して次のアクションを実行できます。

  • ポリシールールの定義: チームが Policy as Code を管理する場合でも、RHACS 内部データベースを使用して管理する場合でも、ポリシーの作成は技術的に困難になる可能性があります。RHACS は、このタスクを簡素化する直感的なユーザーインターフェイス、つまりポータルを提供します。仕様の複雑さを隠しつつ、コントロールに集中できます。ポータルを使用してポリシーを作成して、それを YAML としてエクスポートしてコードとして保存したり、ローカルに保存したりすることができます。
  • ポリシーを適用するライフサイクルの選択: 内部ポリシーの場合、RHACS は Create、Read、Update、Delete (CRUD) のアクションを提供します。外部ポリシーの場合は、これらのアクションはユーザー自身によって処理され、結果は CR を使用して RHACS に提示されます。内部ポリシーの場合は、RHACS はロールベースのアクセス制御も提供し、監査ログでポリシーの変更を追跡します。
  • ポリシー動作の設定: RHACS は、ユーザーにマルチクラスターのガバナンスを集中的に提供します。ポリシーを設定する際に、次の項目を設定できます。

    • 個々のクラスターの包含または除外の範囲を選択するか、すべてのクラスターに適用するガバナンスを確立する
    • アクション (通知/適用) を選択し、ポリシーを有効化または無効化する
    • 通知機能の設定
  • テストポリシー:

    • ポータルまたは API を使用してポリシーをテストするためのドライランを実行し、ポリシー CR 検証を実行できます。
    • ポリシーレポートの作成: ポータルまたは API を使用してレポーティングを設定し、ポリシーの範囲を詳述できます。

5.1.5. デフォルトのセキュリティーポリシー

Red Hat Advanced Cluster Security for Kubernetes のデフォルトのセキュリティーポリシーは、セキュリティーの問題を特定し、環境内のセキュリティーのベストプラクティスを確保するための幅広い範囲を提供します。これらのポリシーを設定することで、環境内でのリスクの高いサービスのデプロイを自動的に防止し、ランタイムのセキュリティーインシデントに対応できます。

重大度別に分類されたデフォルトのセキュリティーポリシーのリストについては、「ポリシーリファレンス」を参照してください。

5.1.5.1. デフォルトのセキュリティーポリシーの表示

Red Hat Advanced Cluster Security for Kubernetes (RHACS) ポータルを使用して、デフォルトポリシーの表示、それらの複製、および複製したデフォルトポリシーの編集が可能です。デフォルトのポリシーは、Policy as Code 機能ではサポートされません。

手順

  • RHACS ポータルで、Platform Configuration Policy Management に移動します。デフォルトのポリシーは、Origin 列の System ラベルで示されます。

    注記

    デフォルトのポリシーを削除したり、デフォルトポリシーのポリシー基準を編集したりすることはできません。

5.1.6. カスタムセキュリティーポリシー

RHACS を使用すると、開発のビルド、デプロイ、実行フェーズ中にセキュリティーを提供するためのカスタムセキュリティーポリシーを作成できます。次の方法でカスタムセキュリティーポリシーを作成できます。

  • デフォルトのポリシーを複製し、それを変更して環境固有の情報を設定できます。
  • RHACS ポータルを使用して、新しいポリシーを作成して保存できます。
  • Policy as Code 機能を使用すると、ポリシーを Kubernetes のカスタムリソース (CR) として作成および保存し、Argo CD のような Kubernetes ネイティブの継続的デリバリー (CD) ツールを使用して、それらをクラスターに適用できます。

詳細は、「カスタムセキュリティーポリシーの作成と変更」を参照してください。

重要

openshift-* namespace およびデフォルトの OpenShift Container Platform Pod でカスタムポリシーを適用する場合は注意してください。たとえば、適用が設定されたカスタムポリシーでは、ポリシーに違反した場合にデータが失われる可能性のある Pod を終了できます。

5.1.7. セキュリティーポリシーの共有

ポリシーをエクスポートおよびインポートすることで、RHACS ポータル内の異なる Central インスタンス間でセキュリティーポリシーを共有できます。ポリシーを共有すると、すべてのクラスターに同じ標準を適用できるようになります。ポリシーを共有するには、JSON ファイルとしてエクスポートして、別の Central インスタンスにインポートし直す必要があります。

注記

現在、RHACS ポータルを使用して複数のセキュリティーポリシーを同時にエクスポートすることはできません。ただし、API を使用して複数のセキュリティーポリシーをエクスポートできます。RHACS ポータルで Help API reference に移動し、API リファレンスを確認します。

5.1.7.1. セキュリティーポリシーのエクスポート

ポリシーをエクスポートすると、ポリシーの内容だけでなく、クラスターの範囲、クラスターの除外、および設定されたすべての通知も含まれます。

手順

  1. RHACS ポータルで、Platform Configuration Policy Management に移動します。
  2. Policies ページから、編集するポリシーを選択します。
  3. Actions Export policy to JSON を選択します。

5.1.7.2. セキュリティーポリシーのインポート

RHACS ポータルの システム ポリシービューからセキュリティーポリシーをインポートできます。

手順

  1. RHACS ポータルで、Platform Configuration Policy Management に移動します。
  2. Import policy をクリックします。
  3. Import policy JSON ダイアログで Upload をクリックし、アップロードする JSON ファイルを選択します。
  4. Begin import をクリックします。

    RHACS の各セキュリティーポリシーには、一意の ID (UID) と一意の名前があります。ポリシーをインポートすると、RHACS はアップロードされたポリシーを次のように処理します。

    • インポートされたポリシーの UID と名前が既存のポリシーと一致しないと、RHACS は新しいポリシーを作成します。
    • インポートされたポリシーで、既存のポリシーと同じ UID が設定されているが、別の名前の場合には、以下のいずれかを実行できます。

      • 両方のポリシーを保持する。RHACS はインポートされたポリシーを新しい UID で保存します。
      • 既存のポリシーをインポートされたポリシーに置き換える。
    • インポートされたポリシーの名前が既存のポリシーと同じものの、UID が異なる場合は、以下のいずれかを実行できます。

      • インポートされたポリシーの新しい名前を指定して、両方のポリシーを保持する。
      • 既存のポリシーをインポートされたポリシーに置き換える。
    • インポートされたポリシーの名前が既存のポリシーと同じ場合、Red Hat Advanced Cluster Security for Kubernetes はポリシー基準が既存のポリシーに一致するかどうかを確認します。ポリシー基準が一致する場合、RHACS は既存のポリシーを保持し、成功メッセージを表示します。ポリシー基準が一致しない場合は、以下のいずれかを実行できます。

      • インポートされたポリシーの新しい名前を指定して、両方のポリシーを保持する。
      • 既存のポリシーをインポートされたポリシーに置き換える。

        重要
        • 同じ Central インスタンスにインポートする場合、RHACS はエクスポートされたすべてのフィールドを使用します。
        • 別の Central インスタンスにインポートする場合、RHACS はクラスタースコープ、クラスター除外、通知などの特定のフィールドを省略します。RHACS は、省略されたフィールドをメッセージに表示します。これらのフィールドはインストールごとに異なりますが、フィールドを別の Central インスタンスに移行することはできません。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat