Kubernetes ランタイム保護
ランタイムプロテクションを使用すると、CloudGuard は、ワークロードコンテナが実行するカーネルシステムコールをリアルタイムで監視します。Runtime Protection メカニズムは、すべてのPod グループに対してデフォルトで有効になっている2 つのエンジン(署名とプロファイリング) を組み合わせています。
アーキテクチャ
ランタイム保護には、次のリソースが含まれます。
Runtime Protection Policy agent - CloudGuardから設定とポリシーを取得し、クラスタに保存するシングルレプリカデプロイメント
Runtime Protection Daemon - 2 つのRuntime Protection エンジン(シグネチャとプロファイリング)を備えたDaemonSet。基礎となるノードと通信してカーネルシステム呼び出しをインターセプトします。
Custom Resource Definitions (CRD) - ランタイムプロテクションポリシーを実施するためにCloudGuardがクラスタで管理するKubernetesカスタムリソース(CR)
Inventory agent
Runtime Protection Policy エージェントのみが、CR を変更する権限を持っています。Runtime Protection PolicyおよびRuntime Protection Daemonエージェントのみが、CRを読み取る権限を持っています。read 権限(get やlist など) を含むCR へのアクセスは、クラスタセキュリティ設定に関する情報が含まれているため、制限する必要があります。
Kubernetes Runtime Protection の最小要件については、対応バージョン を参照してください。
| 注 - eBPF に対応していない4.4 未満のカーネルバージョンでは、カーネルモジュールモードを使用します。有効にするには、フラグを追加します。 この構成では、デーモンコンテナはprivileged モードで実行する必要があります。 |
ランタイム保護の仕組み
Kubernetes Runtime Protection には、2 つのメインエンジンがあります。
Signatures - ワークロードの監視された動作を、悪意のある動作を示す可能性がある既知のシグネチャと比較します。例: 暗号マイニングソフトウェアに関連するプロセスの実行。
Profiling - プロファイリングフェーズ中に作成されたベースラインプロファイルに関連するビヘイビアの異常を検出します。例: 通常のワークロード操作中に発生しないサブプロセスの実行。これは、RCE 攻撃を示す可能性があります。
シグネチャとプロファイリングは、すべてのポッドグループに対してデフォルトで有効になっています。
独立Pod Group リソースのAsset ページには、以下を含むRuntime Protection タブがあります。
設定の詳細:ワークロード、プロファイリングステータス、および設定の実行時保護ステータス(有効または無効)
完全な動作プロファイルを持つワークロードの場合:ワークロードが実行できるすべてのプロセスと、アクセスできるすべてのドメインを持つ現在の動作プロファイル
シグネチャの除外
シグネチャ
シグネチャエンジンは、保護されたワークロードプロセスが実行するカーネルシステムコールを監視します。このエンジンは、潜在的に悪意のある動作に関連付けられた事前定義済みのシグネチャのセットと比較します。Check Pointリサーチチームは、CloudGuardのシグネチャをダイナミックにアップデートして、新たな脅威や脆弱性に対応します。
シグネチャの例:
/etc/passwdファイルの変更'
xmrig' バイナリの実行
プロファイリング
プロファイリングエンジンの作業は、次の2 つのフェーズで構成されます。
プロファイル学習
プロファイル強制
最初のフェーズでは、プロファイリングエンジンは、特定のクラスタで実行されるワークロードの動作パターンを学習し、そのプロファイルを構築します。プロファイル(allowlist) は、このワークロードができること(どのプロセスを実行できるか、どのドメインにアクセスできるか) を記述するポリシーです。学習が完了すると、2 番目のフェーズが開始されます。CloudGuard は、ポッドグループ内のいずれかのコンテナがプロファイリングフェーズ中に処理を実行したり、監視されていないネットワークにアクセスしたりすると、違反を検出し、警告をトリガーできます。
ポッドグループ
ランタイムプロテクションの場合、CloudGuard は個々のPod を処理しませんが、これらのPod が同じ所有者である場合、それらをまとめてPod Group のメンバとして参照します。従属リソース間の関係は、すべてのワークロードリソースのownerReferences プロパティに表示されます。所有者のいないポッドは、独立ポッドと呼ばれます。独立ポッドは、独自のポッドグループと見なされます。
一般に、環境内の各エンティティは、その上の最も高いルートエンティティによって提示されるPod Group のメンバと見なすことができます。
明示的にプロビジョニングする独立ポッドグループは、Kubernetes コントローラが別の(親) リソースのライフサイクルの一部として作成するポッドグループとは異なります。
独立ポッドグループ:
Kubernetes の展開
Kubernetesデーモンセット
Kubernetes レプリカセット(依存リソースでない場合)
Kubernetes Pods (依存リソースでない場合)
| 注 - ジョブなどの他のコントローラから派生したポッドは独立していると見なされます。 |
ポッドに関連するすべてのルール、除外、およびプロファイルは、そのポッドグループにも関連します。たとえば、デプロイ用に作成されたルールは、このデプロイのポッドグループ内のすべてのポッドに適用されます。
プロファイル学習
ノードごとに、CloudGuardエージェントは、コンテナがノードで行うシステムコールを監視します。新しいポッドグループがクラスタにデプロイされると、CloudGuard は、プロファイリング期間の終わりまで、ポッドグループ全体のすべてのプロセスとネットワークアクティビティを監視します。デフォルトでは、プロファイリング期間は24 時間です。これは、CloudGuard エージェントが新しいPod Group デプロイを検出した時点、またはRuntime Protection が有効になった時点から、既存のPod Group に対して数えられます。期間の終了時に、エージェントはPod Group のセキュリティプロファイル(ベースライン) を作成します。Runtime Protection タブには、Processes セクションとNetwork セクションにプロファイルの詳細が含まれています。この段階で学習した各プロセスとネットワークの詳細にはRuntime タグがあります。
Processes - CloudGuard は、許可されているプロセスを、プロセスパスと親プロセスのパス(それを開始したプロセス) の組合せで指定します。ポリシーの施行段階で、別の親プロセスがプロセスを開始した場合、CloudGuard はプロセスを許可しません。
Network - 許可されたネットワークドメインと親プロセスの組み合わせ。
| 注:
|
学習プロセス中、Runtime Protection タブに現在のプロファイリングステータスが表示されます。
ステータス | 説明 | プロファイリング期間 |
|---|---|---|
In Progress (%) | CloudGuard はワークロードの動作を学習しています。End Time は、学習が完了するタイミングを示します。 | 未終了 |
Finalizing | CloudGuardは、収集されたデータに基づいてプロファイルを作成しています。 | 保留中 |
Wait For Startup | CloudGuardはポッドの産卵を待つ。 | 保留中 |
Completed | CloudGuardにはポッドグループのフルプロファイルがあります。 | 完成 |
Disabled | 実行時保護は無効です。 | 開始していません |
プロファイルには、展開から安定した実行の段階までのワークロードライフサイクルに関する情報が含まれています。ワークロードがデプロイされた後にCloudGuardがプロファイル学習を開始すると、その開始情報がプロファイルに欠落し、プロファイリング期間中にCloudGuardがプロファイル学習を完了できなくなります。プロファイリングステータスはWait for Startup と表示されます。プロファイルが完了するまで、CloudGuard はランタイムプロテクションを適用できません。
プロファイリングプロセスを完了するには、以下の2 つのオプションのいずれかを選択します。
ワークロードライフサイクルが新しいポッドを自然に生成するまで待機します。
ポッドを削除する
| Important - ポッドを削除する場合は、注意してください。これは、新しいポッドの作成をトリガーしますが、特定のワークロードに望ましくない副作用を与える可能性があります。 |
プロファイル強制
プロファイルが完了すると、エージェントはイベントの収集を停止し、保護の適用を開始します。ポッドグループ内のいずれかのコンテナがプロファイリングフェーズ中に監視されない操作を実行すると、エンジンは違反を検出し、アラートをトリガーします。
CloudGuard は、ポッドグループプロファイルをバージョンに関連付け、すべてのコンテナのイメージの組合せとして識別します。新しいイメージバージョン(同じイメージ、新しいイメージタグなど)でコンテナ更新を検出すると、プロファイルがリセットされ、新しい学習期間が開始されます。シグネチャ除外などのユーザ定義の設定はそのまま残ります。
ルールと除外
プロファイリングの除外
プロファイル内の特定のプロセスおよびネットワークを手動で許可(除外を追加)できます。このようにして、プロファイルを微調整することができます。これは、実際には良性(偽陽性検出)である間に、不要、悪意、または異常として何らかの動作を誤って識別した場合です。たとえば、プロファイルのファイナライズ後に発生する月次保守プロセスには、異常とフラグが付けられます。
プロファイル除外には、関連するスコープを明示的に許可するプロセス(コマンド)とネットワークが含まれます。除外によってプロファイルに追加された各プロセスとネットワークには、その詳細にExclusion タグがあります。
プロファイルに対してルールを定義することはできません。つまり、プロセスやネットワークを禁止することもできません。
シグネチャのルールと除外
CloudGuard でセキュリティポリシーを実施する方法として、シグネチャのルールまたは除外を作成できます。これらのアクションは、セキュリティイベントが発生し、「イベント」テーブルに表示された後でのみ可能です。
イベントを許可して良性として設定するには、除外を追加します。CloudGuard がこの動作を再検出した場合、セキュリティアラートはトリガされません。
シグネチャに関連する操作をブロックするには、ルールを追加します。CloudGuard がこのアクティビティを再度検出すると、シグネチャエンジンはオペレーションを実行するコンテナを強制終了します。
アクション
クラスタでのランタイムプロテクションの有効化 ランタイムプロテクションは、すべてのポッドグループに対してデフォルトで有効になっています。
クラスタをCloudGuardにオンボードするときに機能を無効にしたか、選択しなかった場合は、以下の手順に従ってランタイムプロテクションを有効にします。
Workload Protection メニューのContainers ページに移動します。
リストから環境を選択し(フィルタリングして検索を絞り込むことができます)、Blades タブを開きます。
Runtime Protection をOn に切り替えます。
確認ウィンドウが開き、クラスタにエージェントをインストールする方法が指示されます。
クラスタにエージェントをインストールします。
確認ウィンドウで、Yes をクリックして操作を確認します。
お使いの環境でランタイムプロテクションを有効にするには、数分かかるCloudGuardがかかります。
ルールの作成 トリガーされたセキュリティイベント、つまり記録されたアラートに対してのみ、ルールを作成できます。このようなイベントは、シグネチャエンジンの監視の結果として発生します。ルールを適用した後、同じ悪意のあるアクティビティが再度発生すると、CloudGuard は実行中のコンテナを強制終了します。
プロファイルのルールを作成することはできません。
ルールを作成するには:
Events メニューのThreat & Security Events ページに移動します。
タイトル内のContainers Runtime Protection source とSignatureEvent でイベントを検索し、選択します。関連するすべてのイベントを表示するには、タイムフレームフィルタを調整する必要がある場合があります。
ツールバーで、Add Deny Rule をクリックします。
ルール確認の拒否ウィンドウが開きます。
選択したポッドグループまたはクラスタ内のすべてのポッドにルールを適用できます。該当するオプションを選択し、Create をクリックします。
CloudGuard は、該当するポッドグループのランタイムプロテクションルールタブのRules セクションにルールを追加します。
除外の作成 特定のワークロード、ワークロードのグループ、または特定のクラスタ(環境) 内のすべてのPod の範囲で除外を定義し、適用することができます。
シグネチャの場合、イベントタブおよび特定のセキュリティイベントから除外を作成できます。
プロファイリングでは、以下から除外を作成できます。
Events > Threat & Security Events テーブルの検索またはイベントのメニュー
Pod グループに関連付けられたRuntime Protection およびRuntime Protection Rules タブ
クラスタ(環境)に関連付けられたRuntime Protectionタブ
除外を作成するには:
新しい除外のコンテキストを選択し、関連エンティティを開きます。
Events テーブルで、Exclude をクリックします。エンティティタブで、Create New Exclusion をクリックします。
新規除外の作成ウィンドウで、詳細を入力します。
Name このタブの除外リストの後半に表示される除外の場合。
Target - 監視から除外するアクションのタイプ: プロセスまたは特定のホスト。シグネチャの場合、シグネチャタイプは事前に選択されています。
Pattern - プロセスのパスまたはホストのドメイン名。シグネチャの場合、パターンはシグネチャの事前選択された名前です。
Process/Parent Process - 除外されたドメインまたはプロセスを実行できるプロセスのパス。
Scope - 特定のPod グループ、Pod グループのリスト、または特定のクラスタ(環境) 内のすべてのPod へのアプリケーション。
Createをクリックします。
プロファイル学習期間の変更 デフォルトのプロファイル学習期間は24 時間です。ワークロードの動作に関する知識に基づいて、プロファイリング期間を変更できます。学習期間を完了期間よりも短い値に設定すると、プロファイル学習はただちに停止します。
プロファイリング期間を変更するには:
ワークロード(Pod Group) のRuntime Protection タブを開きます。
プロファイリングステータスバーで、メニューボタンをクリックします。
右側でSettings を選択します。「ポッドグループ設定」ウィンドウが開きます。上下矢印を使用して、Days、Hours、およびMinutes を必要に応じて調整します。
Saveをクリックします。。
| 注 - CloudGuard は、ポッドグループの将来のバージョンの新しいプロファイリング周期の設定を保存します。 |
トラブルシューティング
設置の確認
Runtime Protection エージェントのインストールを確認するには、次の手順を実行します。
CloudGuard ポータルで、Assets に移動し、目的のKubernetes クラスタを選択し、Blades タブに移動して、Runtime Protection にあるすべてのエージェントがOK 状態であることを確認します。この操作では、情報の更新に数分かかることがあります。
Kubernetes クラスタで、すべてのエージェントリソースが指定されたネームスペースにインストールされ、Ready 状態であることを確認します。インターネットに接続できない場合、イメージをすべて取り込むのに数分かかることがあります。
定義されたノードセレクタと許容値に基づいて、Runtime Protection Daemon が正しいノード数で実行されていることを確認します。
すべてのエージェントコンポーネントのログを確認し、エラーがないことを確認します。
インベントリーエージェントポッド
ランタイムポリシーポッド
ランタイムデーモンポッド(各ノード上)
probe コンテナ
daemon コンテナ
fluentbit コンテナ
イメージのダウンロードエラー
custom images を設定する場合は、ノードからアクセス可能であることを確認します。
イメージが保護されたイメージレジストリに保管されている場合(デフォルトのEAイメージの場合)、エージェントのインストール中に指定されたイメージレジストリの認証情報が正しいことを確認します。
エラーログ
ログにcpx-api.dome9.com または類似のサイトへのアクセスに関するエラーが含まれている場合:
ノードがインターネットサービスにアクセスするためにプロキシが必要かどうかを確認します。sk165514のKubernetes behind a gatewayを参照してください。
エージェントをインストールまたはアップグレードするときに、clusterID とcredentials が正しく設定されているかどうかを確認します。
ログにKubernetes APIs へのアクセスに関するエラーが含まれ、カスタムサービスアカウントが設定されている場合は、適切に設定されていることを確認します。
空または部分プロファイル
部分プロファイルには、Pod の起動時に起動されるプロセスは含まれません。プロセスを完了するには、プロファイル学習を完了する方法 を参照してください。
プロファイル再学習の動作
Runtime Protection は、ワークロードに関連付けられたコンテナイメージが変更されるたびに、ワークロードの新しい動作プロファイルを作成します。イメージ変更の決定は、Podテンプレート仕様のイメージ参照文字列によって異なります。つまり、たとえば、:latest などの汎用イメージタグを参照する場合、再学習はトリガされません。これは、Kubernetes がPod テンプレートの変更を識別する方法と一致しています(新しいバージョンのロールアウトがトリガーされます)。
Check Point では、:latest イメージタグを使用することはお勧めしません。これは、安全ではないと見なされ、プロファイルの再学習が必ずしも行われるわけではないためです。
