CIS ベンチマーク

このページでは、Kubernetes と GKE の Center for Internet Security（CIS）ベンチマークへの準拠を強化するために Google Kubernetes Engine（GKE）が採用しているアプローチについて説明します。このページには、次の情報が含まれています。

  • CIS Kubernetes Benchmark に準拠するようにマネージド GKE コントロール プレーンを構成する方法
  • CIS Google Kubernetes Engine（GKE）Benchmark に準拠するように GKE ノードとワークロードを構成する方法

CIS ベンチマークについて

CIS は、Kubernetes の安全な構成ガイドラインを含む次のベンチマークを公開しています。

  • CIS Kubernetes Benchmark: オープンソースの Kubernetes プロジェクトに適用されます。さまざまなセルフマネージド Kubernetes 実装とホスト型 Kubernetes 実装に関するガイダンスを提供することを目的としています。
  • CIS GKE Benchmark: GKE クラスタで制御できるコンポーネントの安全な構成に関するガイドラインを確立します。Google Cloud 上の GKE に固有の推奨事項が含まれています。

CIS GKE Benchmark は Google Cloud 上の GKE に固有であるため、CIS GKE Benchmark を優先することをおすすめします。CIS Kubernetes Benchmark には、GKE で表示または変更できないコントロールに関する推奨事項が多数含まれています。Google のクラスタ セキュリティのアプローチには、オープンソースの Kubernetes ベンチマークの範囲を超える緩和策が含まれており、それらの推奨事項と競合する可能性があります。

GKE に適用されるその他のベンチマーク

CIS GKE Benchmark と CIS Kubernetes Benchmark に加えて、GKE で使用可能なオペレーティング システムには次のベンチマークが適用されます。特定の OS ベンチマークで Kubernetes の使用が明示的に扱われていない場合でも、追加のセキュリティ ガイダンスについてそのベンチマークを参照する必要があります。

デフォルトのコンテナ ランタイムである containerd にはベンチマークはありません。

共有責任モデル

Google は、GKE の共有責任モデルに基づいて次のコンポーネントを管理します。

  • コントロール プレーン（コントロール プレーン VM、API サーバー、etcd、kube-controller-manager、kube-scheduler などのコンポーネントを含む）。
  • ノードのオペレーティング システム。

これらのコンポーネントは GKE が所有するプロジェクト内に存在するため、対応する CIS Benchmark コントロールに基づいてこれらのコンポーネントを変更または評価することはできません。ただし、ワーカーノードとワークロードに適用される CIS Benchmark コントロールを評価して修正することはできます。GKE の共有責任モデルに基づき、これらのコンポーネントはお客様の責任で管理する必要があります。

CIS Benchmark に対応した Google の GKE 保護のためのアプローチ

GKE は、オープンソースの Kubernetes のマネージド実装です。Google はコントロール プレーンを完全に管理し、コントロール プレーン コンポーネントの構成を保護する責任を担います。次の表に、CIS ベンチマークのスコアリングに影響する可能性がある Google の決定事項の一部を示します。

GKE のセキュリティ アプローチ
認証
  • 一部の GKE モニタリング コンポーネントは、匿名認証を使用して指標を取得します。GKE では kubelet の匿名認証が許可されていますが、追加のデバッグ ハンドラを無効にしているため、公開は読み取り専用ポートと同じです。
  • 一部のコントロール プレーン コンポーネントは静的トークンを使用してブート ストラップされ、API サーバーの認証に使用されます。これらのトークンは、VM の起動または再起動のたびに生成されます。
アドミッション コントローラ

GKE では、次のアドミッション コントローラが無効になっています。

  • EventRateLimit: Kubernetes のアルファ機能
  • AlwaysPullImages: このコントローラは、非協調型のマルチテナント クラスタの非公開レジストリ イメージを保護しますが、クラスタ内で新しい Pod を作成する際にイメージ レジストリが単一障害点となります。
  • SecurityContextDeny: Pod セキュリティ アドミッション コントローラが推奨されます。このコントローラはすべての GKE エディションで使用できます。 GKE Enterprise を使用している場合は、Policy Controller を使用して Pod セキュリティ標準の適用を有効にすることもできます。
  • ImagePolicyWebhook: GKE にはイメージ管理とセキュリティのための独自のメカニズムがあるため、デフォルトでは ImagePolicyWebhook は無効になっています。これにより、GKE は環境をより厳密に制御し、またセキュリティ プラクティスが一貫して適用されるようになります。 ただし、ポリシー管理には Binary Authorization または Policy Controller を使用できます。
監査ロギング GKE は、GKE 監査ポリシーを使用して監査ログをキャプチャします。そのため、Kubernetes API サーバー監査ロギングフラグを設定する必要はありません。
デバッグ GKE はデバッグにプロファイリングを使用します。
暗号化
kubelet
  • GKE では、未認証の kubelet 読み取り専用ポートが有効になります。
  • GKE Standard モードでは、必要に応じてワークロードがカーネルのデフォルトを変更できます。
  • GKE では、サービス拒否攻撃のリスクを軽減するために、kubelet 内の Kubernetes イベントの数が制限されます。
  • GKE は mTLS を使用して、kubelet と API サーバー間のトラフィックを保護します。
  • GKE はデフォルトでサーバー証明書をローテーションし、Shielded GKE Nodes が有効になっている場合はクライアント証明書をローテーションします。
  • GKE は golang のデフォルトの許可暗号セットを使用します。これは Kubernetes のデフォルトでもあります。

CIS ベンチマークに基づいて GKE を評価する

ベンチマークに基づくクラスタの評価は、次のいずれかの方法で自動化できます。

  • CIS GKE Benchmark:

    • すべての GKE エディション:
      • kube-bench を実行して、ベンチマークに基づいてワーカーノードを評価します。詳細については、kube-bench GitHub リポジトリをご覧ください。
      • Twistlock Defender などのサードパーティ ツールを使用して、ベンチマークに基づいてノードを評価します。
    • GKE Enterprise エディション: Compliance ダッシュボードを使用して、すべてのクラスタが CIS GKE Benchmark に準拠しているかどうかを評価します。詳細については、GKE Compliance ダッシュボードについてをご覧ください。

  • CIS Kubernetes Benchmark: kube-bench を実行して、Benchmark に基づいてワーカーノードを評価します。ベンチマークの推奨事項に基づいてマネージド コントロール プレーンを評価することはできません。

次のステップ