このページは Cloud Translation API によって翻訳されました。

CIS ベンチマーク

Autopilot Standard

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

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

CIS ベンチマークについて

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

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

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

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

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

Container-Optimized OS ベンチマーク: すべての GKE Linux ノードにインストールされているデフォルトのオペレーティングシステム
Ubuntu Linux ベンチマーク: GKE Standard で利用可能
Windows Server ベンチマーク: GKE Standard で利用可能

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

共有責任モデル

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

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

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

CIS Benchmark 向けの GKE の保護に対する Google のアプローチ

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

GKE のセキュリティアプローチ
認証	一部の GKE モニタリングコンポーネントは、匿名認証を使用して指標を取得します。一部のコントロールプレーンコンポーネントは静的トークンを使用してブートストラップされ、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 はデバッグにプロファイリングを使用します。
暗号化	GKE は、保存したお客様のコンテンツをデフォルトで暗号化します。必要に応じて、管理する鍵を使用してデータを暗号化できます。詳細については、アプリケーションレイヤで Secret を暗号化するをご覧ください。 GKE は、etcd インスタンス間、API サーバー間、etcd 間、コントロールプレーンとノード間のトラフィックに mTLS を使用します。詳細については、クラスタの信頼性をご覧ください。
kubelet	GKE では、未認証の kubelet 読み取り専用ポートが有効になります。ポートを無効にするには、`--no-autoprovisioning-enable-insecure-kubelet-readonly-port` を設定します。読み取り専用ポートは、移行期間を経て、今後のリリースでデフォルトで無効になります。 GKE Standard モードでは、必要に応じてワークロードがカーネルのデフォルトを変更できます。 GKE は、サービス拒否攻撃のリスクを軽減するために、kubelet 内の Kubernetes イベントの数を制限します。 GKE は mTLS を使用して、kubelet と API サーバー間のトラフィックを保護します。 GKE はデフォルトでサーバー証明書をローテーションし、シールドされた GKE ノードが有効になっている場合はクライアント証明書をローテーションします。 GKE は golang のデフォルトの許可暗号セットを使用します。これは Kubernetes のデフォルトでもあります。

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

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

CIS GKE Benchmark:
- すべての GKE エディション:
  - kube-bench を実行して、ワーカーノードをベンチマークと比較します。詳細については、kube-bench GitHub リポジトリをご覧ください。
  - Twistlock Defender などのサードパーティツールを使用して、ベンチマークと比較してノードを評価します。
- GKE Enterprise エディション: Compliance ダッシュボードを使用して、すべてのクラスタが CIS GKE ベンチマークに準拠しているかどうかを評価します。詳細については、GKE Compliance ダッシュボードについてをご覧ください。
CIS Kubernetes Benchmark: kube-bench を実行して、Benchmark に対してワーカーノードを評価します。ベンチマークの推奨事項と比較して、マネージドコントロールプレーンを評価することはできません。

次のステップ

GKE セキュリティの概要を確認する。
GKE 強化ガイドのセキュリティのベストプラクティスの手順に従う。
GKE セキュリティポスチャーを使用して、クラスタのセキュリティ問題をモニタリングする方法について学習します。
GKE Enterprise の GKE Compliance ダッシュボードで、クラスタのコンプライアンス問題を評価する方法について学習します。