CIS ベンチマーク

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

  • CIS Kubernetes Benchmark に準拠するために Google がどのようにマネージド GKE コントロール プレーンを構成しているか
  • CIS Google Kubernetes Engine（GKE）Benchmark に準拠するためにお客様がどのように GKE ノードとワークロードを構成できるか

CIS ベンチマークについて

CIS から次のベンチマークがリリースされており、この中に Kubernetes の安全な構成のガイドラインが含まれています。

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

Trusted 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 または Spanner ベース）、kube-controller-manager、kube-scheduler などのコンポーネントが含まれます。
  • ノードのオペレーティング システム。

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

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

GKE は、オープンソースの Kubernetes をマネージド型で実装するものです。Google がコントロール プレーン全体を管理するとともに、コントロール プレーン コンポーネントの構成のセキュリティ保護について責任を負います。次の表に、Google による決定事項のうち CIS ベンチマークのスコアリングに影響する可能性があるものを示します。

GKE のセキュリティ アプローチ
認証
  • 一部の GKE モニタリング コンポーネントは、匿名認証を使用して指標を取得します。
  • コントロール プレーン コンポーネントの中には静的トークンを使用してブートストラップされるものがあり、このトークンは API サーバーに対する認証に使用されます。これらのトークンは、VM の起動または再起動のたびに生成されます。
アドミッション コントローラ

GKE では次のアドミッション コントローラが無効化されます。

  • EventRateLimit: これは Kubernetes のアルファ機能の一つです。
  • AlwaysPullImages: このコントローラによって、非協調型マルチテナント クラスタの非公開レジストリ イメージがある程度保護されますが、その代償としてイメージ レジストリが単一障害点となり、クラスタ内で新しい Pod を作成できなくなることがあります。
  • SecurityContextDeny: Pod セキュリティ アドミッション コントローラのほうが優先され、すべての GKE エディションで使用可能です。
  • ImagePolicyWebhook: GKE にはイメージ管理とセキュリティの独自のメカニズムがあるため、ImagePolicyWebhook がデフォルトでは無効化されます。その結果、GKE ではより厳格なコントロールが環境に対して維持されるとともに、セキュリティの実践事項が確実に一貫して適用されます。
監査ロギング GKE では、GKE 監査ポリシーを使用して監査ログが記録されます。そのため、Kubernetes API サーバー監査ロギングのフラグの設定は一切必要ありません。
デバッグ GKE はデバッグにプロファイリングを使用します。
暗号化
etcd

オープンソースの Kubernetes では、クラスタ状態データベースに etcd が使用されます。GKE では、次のいずれかのテクノロジーを使用したバックエンド データベースにクラスタの状態が保存されます。

  • etcd: クラスタのコントロール プレーンで etcd インスタンスが実行されます。
  • Spanner: コントロール プレーン VM とは別の Spanner ベースのデータベースにクラスタの状態が保存されます。

すべての GKE クラスタのコントロール プレーン VM で etcd API のサービスが提供されます。Kubernetes API とのクライアントのやり取りは、オープンソースの Kubernetes の場合と同じです。クラスタの etcd API のバックエンドであるデータベース テクノロジーによっては、オープンソースの CIS Kubernetes Benchmark における etcd 関連のスコアリングに差異が生じることがあります。
kubelet
  • GKE では、未認証の kubelet 読み取り専用ポートが有効化されます。ポートを無効にするには、--no-autoprovisioning-enable-insecure-kubelet-readonly-port を設定します。読み取り専用ポートは、移行期間を経て、今後のリリースでデフォルトで無効になる予定です。
  • GKE では、サービス拒否攻撃のリスクを縮小するために、kubelet 内の Kubernetes イベントの数が制限されます。
  • GKE では、kubelet と API サーバーの間のトラフィックを保護するために mTLS が使用されます。
  • GKE では、サーバー証明書のローテーションがデフォルトで行われ、クライアント証明書のローテーションは Shielded GKE Nodes が有効化されているときに行われます。
  • GKE では golang のデフォルトの許可暗号セットが使用されます。これは Kubernetes のデフォルトでもあります。

CIS Benchmark で GKE を評価する

次のいずれかの方法を使用して、ベンチマークに照らしたクラスタの評価を自動化できます。

  • CIS GKE Benchmark:

    • すべての GKE エディション:
      • kube-bench を実行してワーカーノードを Benchmark に照らして評価します。詳細については、kube-bench GitHub リポジトリをご覧ください。
      • サードパーティ製ツール（たとえば Twistlock Defender）を使用してノードを Benchmark に照らして評価します。

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

    次のステップ