アドミッションコントロール

Admission Control は、永続的になる前にKubernetes API サーバへの要求をインターセプトします。

Admission Control に基づいて、要求を即座に拒否することができ、エラーがエンドユーザに返されます。アドミッションコントロールは、要求を拒否せずに違反やレポートを検出することもできます。

アーキテクチャ

Admission Control は、次のリソースで構成されます。

  • Policy Agent - CloudGuard バックエンドから(ユーザが設定した) 設定とポリシーを取得するシングルレプリカデプロイメントです。

  • Enforcer Agent - レプリカ数が2 のデプロイメントで、アドミッションWebhook を確立し、API 呼び出しを受信し、適用されたポリシーに基づいてそれらを検証します。

  • Custom Resource Definitions (CRD) - サポートされている各オブジェクトタイプの検出および予防ルールは、カスタムリソース(CR)として保存されます。
    ポリシーエージェントのみがこれらのCRを変更する権限を持っている必要があり、ポリシーエージェントとエンフォーサエージェントのみがCRを読み取る権限を持っている必要があります。
    これらのCRD へのアクセス(read 権限(get やlist など) は、クラスタ強化に関する情報を含むため、制限する必要があります。

Kubernetes Resources

サポート対象リソース

CloudGuardアドミッション制御を使用すると、次のリソースにポリシーを適用できます。

  • ポッド

  • デプロイメント

  • ReplicationControllers

  • レプリカセット

  • DaemonSets

  • StatefulSets

  • ジョブ

  • CronJobs

  • ロール

  • ClusterRoles

  • RoleBindings

  • ClusterRoleBindings

  • サービス

  • 不正侵入

  • ServiceAccounts

  • 名前空間

  • ConfigMaps

  • NetworkPolicies

  • PodSecurityPolicies

Kubernetes 定義

一部のKubernetes リソースには所有者リソースがあります。

  • Owner resource: リソースを作成した親リソース

  • Root Owner resource: リソースの作成につながった最初のリソース

例：

  • ポッドは、ReplicaSet によって直接または間接的に作成できます。後者の場合、ReplicaSet はポッドの所有者です。

  • リソースは所有者リソースのチェーンを持つことができ、たとえば、デプロイメントはPod を作成できるReplicaSet を作成できます。

Deployment-X は2 つのレプリカを作成するReplicaSet-X を作成します。Pod-X1 およびPod-X2。

Deployment-X はPod-X1 およびPod-X2 のルート所有者で、ReplicaSet-X のルート所有者です。

Deployment-X はReplicaSet-X の所有者です。

ReplicaSet-X はPod-X1 およびPod-X2 の所有者です。

Deployment-X には所有者もroot 所有者もありません。

機能説明

アドミッション制御を有効にすると、CloudGuard はKubernetes エージェントをインストールまたはアップグレードします。Kubernetes は、エンフォーサエージェントを、サポートされているリソースのAdmission Control 検証Webhook としてデプロイおよび登録します。

施行者代理人

  • API がAPI サーバトリガーをサポートされているリソースに対して呼び出すすべてのcreate、update、delete、またはconnect オペレーションをインターセプトします。

  • これらの変更をAdmission Controlルールに対して検証します。

API 呼び出しがルールに違反した場合、CloudGuard はポリシーの通知に従ってアラートを送信します(ポスチャの検索とセキュリティイベント を参照し、Admission Control ソースでフィルタリングします)。

  • ポリシーを構成する場合は、操作をブロックします。 Prevention mode

  • ポリシーを構成する場合は、操作を許可します。 Detection mode

アドミッション制御は、API 呼び出し時にのみ違反をブロックまたは検出します。実行中のワークロードは削除またはブロックしません。

注 - アドミッションコントロールは、ユーザによって開始されたすべてのオペレーションをモニタ(ブロックまたは検出)します。Kubernetes 制御プレーンによって操作されるシステムコンポーネントは無視されます。

例

このルールを追加するとします。

kubernetesPod should not have labels with [key=’app’ and value=’my_app’]

次に、ラベルapp my_app を使用してワークロードがすでに実行されているとします。このワークロードはブロックされず、アラートもトリガーされません。ポスチャー管理(クラウドセキュリティポスチャー管理を参照)を使用して、クラスタの実行状態の違反を検出できます。

ただし、app my_app というラベルを使用してワークロードを作成するか、そのようなラベルをワークロードに追加しようとすると、Admission Control は操作を検出またはブロックします。

アラート再発

CloudGuardアドミッション制御は、一意のインシデントごとに単一の警告のみを発行します。

問題は、次のすべての条件を満たす場合に固有です。

  • すべてのオカレンスが、同じルールセットおよびポリシー内の同じルールに違反します。

  • 同じエンティティ(ユーザの名前またはサービスアカウント)は、すべてのオカレンスに関連します。

  • ターゲットは、すべてのオカレンスで同じです。つまり、エンティティの同じエンティティまたは同じルート所有者(たとえば、異なるPod に対する同じデプロイメント) を持ちます。

アラートの重大度

  • ユースケースまたはルールで定義された重大度によって決定する

  • 関連するイベントがKubernetes ドライランの場合、重大度レベルは次のようになります。

  • Kubernetes サーバ側のdry-run オプションがAPI を呼び出すと、Admission Control はイベントを他のすべてのイベントとしてインターセプトします。関連するイベントがKubernetes dry-run の場合、アラートの重大度レベルはInformational です。

アドミッション制御フェーズ

アドミッション制御では、検証中のアドミッションWebhook を使用して、CloudGuard ポータルまたはCloudGuard API を介してユーザが作成したポリシーを適用します。

アドミッションコントロールのデフォルトポリシー設定

コンテナアドミッションコントロールは、Kubernetes アドミッションコントロールのベストプラクティスルールを含むCloudGuard管理ルールセットです。このルールセットは、Workload Protection > Admission Control Rulesets に移動し、CloudGuard-Managed Type でフィルタリングすると表示されます。

デフォルトのアドミッションコントロールポリシーでは、このルールセットが使用されます。CloudGuard は、デフォルト検出モードポリシーを、Admission Control が存在するすべての新規クラスタおよび既存クラスタにアタッチします。

セキュリティソリューションを提供するために、CloudGuardエージェントは、ほとんどのワークロードに対して制限すべき高度な権限を必要とすることがあります。この要件に対処するために、デフォルトポリシーには、CloudGuardソリューションを合理化するための事前設定された除外があります。

除外

アドミッション制御の除外は、通常のCloudGuard除外と似ています。除外を参照してください。

新しいアドミッションコントロール除外を作成する場合は、次の必須フィールドとオプションフィールドを入力する必要があります。

  • ルールセット名(必須)

  • 環境またはOU(オプション)
    フィールドが空白の場合、除外はすべてのクラスタに適用されます。

  • ルール(オプション)
    フィールドが空白の場合、除外はルールセット内のすべてのルールに適用されます。

  • 日付範囲(オプション)

  • エンティティ(オプション)

  • ラベル(オプション)

    Important -ルールセットを最適化するために、ワークロードオブジェクトモデルはYAMLのcontainersセクションのみを考慮します。これにより、すべてのワークロードタイプ(ポッド、デプロイ、デーモンセットなど) で単一のルールが確実に適用されます。つまり、上位メタデータのラベルは考慮されず、コンテナメタデータのラベルのみが検査されます。
    たとえば、ラベル“app: test” が例外として追加されても、ワークロードとそのポッドは引き続き作成されます。

    これにより、ラベル“app: test-pod” が追加されると、ワークロードが作成されますが、そのポッドは作成されません。

  • 名前空間(オプション) - エージェントがインストールされている名前空間は、変数を使用して参照できます。 CHECKPOINT_NAMESPACE

  • ロール(オプション)

  • サービスアカウント(オプション)

CloudGuard でのアドミッション制御の設定

クラスタにGSLポリシーを設定するには、次の手順を実行します。

  1. アドミッション制御ルールセットの作成

  2. ルールセットへのルールの追加

  3. ルールセットをクラスタにバインドするアドミッション制御ポリシーの作成

詳細については、アドミッションコントロールポリシー を参照してください。