脅威モデル

ネットワークレベルでWebhookエンドポイントにアクセスできる攻撃者は、大量のトラフィックを送信し、Admission Controllerに対して実質的なサービス拒否を引き起こす可能性があります。

Webhookは閉じる設定になっています。Webhookが何らかの理由で時間内に応答しない場合、APIサーバーはリクエストを拒否する必要があります。 これはAdmission Controllerのデフォルトの動作です。

閉じる設定とは、何らかの理由でAdmission Controllerが応答を停止したりクラッシュした場合、APIサーバーがデフォルトでリクエストを拒否することを意味します。 これは、リクエストが通常Admission Controllerによって受け入れられる場合でも同様です。

ネットワークレベルでAdmission Controllerにアクセスできる攻撃者は、Admission Controllerに複雑な処理を必要とするリクエストを通過させ、Admission Controllerがワークロードを処理するために計算能力を使用するため、タイムアウトを引き起こします。

Webhookは閉じる設定になっており、呼び出し元を認証します。 これはAdmission Controllerのデフォルトの動作です。

クラスター内でワークロードを作成する権限を持つ攻撃者は、誤設定を利用して意図されたセキュリティ制御をバイパスすることができます。

Webhookの設定を定期的にレビューすることで、問題を発見するのに役立ちます。

Kubernetes APIにアクセスできる攻撃者は、クラスター内のWebhookオブジェクトを削除するのに十分な権限を持っています。

RBACの権限は厳格に管理されるべきです。

RBACのほとんどは、現在の議論の範囲外です。しかし、次の内容が順次提供され、Admission Controllerユーザーを支援します：

攻撃者は、Admission Controller Webhookの有効なクライアント認証情報にアクセスします。

Webhookは閉じる設定になっています。 これはAdmission Controllerのデフォルトの動作です。

攻撃者は、Kubernetesクラスター内のクラスター管理者レベルの認証情報にアクセスします。

N/A

コンテナネットワークにアクセスできる攻撃者は、APIサーバーとAdmission Controller Webhookの間のトラフィックを嗅ぎ取ることができます。

WebhookはすべてのトラフィックにTLS暗号化を使用しているため、Admission Controllerは安全です。

コンテナネットワーク上の攻撃者は、NET_RAW機能にアクセスできる場合、APIサーバーとAdmission Controller Webhookの間のトラフィックを傍受するためにMITMツールを使用しようとすることができます。

WebhookのためにmTLS認証を使用してクラスターを構成し、Admission ControllerスタックでmTLS機能を有効にしてください。代わりに、ネットワークポリシーをサポートするCNIを使用してmTLSを設定してください。詳細については、"相互TLSによる安全なWebhook"を参照してください。

capabilities-pspポリシーを使用し、NET_RAW機能を削除するように構成してください。

攻撃者は、スプーフィングによってAdmission Controller Webhookのための意図されたAPIサーバーからトラフィックをリダイレクトすることができます。

WebhookのためにmTLS認証を使用してクラスターを構成し、Admission ControllerスタックでmTLS機能を有効にしてください。代わりに、ネットワークポリシーをサポートするCNIを使用してmTLSを設定してください。詳細については、"相互TLSによる安全なWebhook"を参照してください。

攻撃者は、変異アドミッションコントローラーがワークロードを変更するように仕向け、特権コンテナの作成を許可させることができます。

すべてのルールをレビューし、テストしてください。

攻撃者は、アドミッションコントローラーの設定から免除されたKubernetesのネームスペースにワークロードをデプロイすることができます。

RBAC権限は厳格に管理されています。

この決定に関しては、RBACのほとんどが範囲外です。しかし、Admission Controllerチームは次のことを目指しています：

攻撃者は、Admission ControllerによってカバーされていないKubernetes APIの機能を使用するワークロードマニフェストを作成しました。

すべてのルールをレビューし、テストしてください。ポリシーのデプロイメントにおけるルールを変更するPRをレビューするべきです。

ワークロードを作成する権限を持つ攻撃者は、不適切な文字列マッチングを利用してルールを回避します。

すべてのルールをレビューし、テストしてください。

このルールをカバーするテストを導入してください。 いつものように、ポリシーのデプロイメントにおけるルールを変更するPRをレビューするべきです。

ワークロードを作成する権限を持つ攻撃者は、Kubernetes APIの新機能（例えば、変更されたAPIバージョン）を使用してルールを回避します。

すべてのルールをレビューし、テストしてください。廃止されたリソースの使用をテストするポリシーがあります。それはhttps://github.com/kubewarden/deprecated-api-versions-policy[廃止されたAPIバージョンポリシー]から入手可能です。

特権コンテナをクラスターにデプロイする権限を持つ攻撃者は、Admission Controller Webhookが動作しているクラスターのノード上に特権コンテナを作成します。

アドミッションコントローラーは、特権ワークロードを防ぐために制限的なポリシーを使用します。

ワークロードと共にホストパスボリュームをデプロイする権限を持つ攻撃者は、アドミッションコントローラーポッドのファイルにアクセスできるボリュームを作成します。

kubewarden-default Helmチャートをデプロイしてください。推奨ポリシー（`hostpaths-psp`ポリシーを含む）を有効にしてください。このポリシーは、共有ホストパスボリュームを削減するように設定されています。

攻撃者は、SSHを介して特権ユーザーとしてクラスターのノードにログインすることができます。

N/A

攻撃者は、アドミッションリクエストをリスン(する)し、機密データを外部システムに送信するポリシーを設定することができます。

信頼できるが新しいKubernetesクラスターを前提とすると、攻撃者はデプロイメント前にAdmission Controllerスタックを侵害し、ポリシーの適用を妨げることができます。

例えば、次のように：