クラスタのセキュリティを強化する

このドキュメントでは、Google Kubernetes Engine（GKE）環境のセキュリティを強化するためのベスト プラクティスについて説明します。ポリシーと手順を定義、管理、実装するセキュリティ スペシャリストは、これらのベスト プラクティスを使用して組織のデータを保護できます。

次のことに精通している必要があります。

新しい GKE クラスタでは、このドキュメントのベスト プラクティスの多くがデフォルトで実装されています。Autopilot モードのクラスタは、Standard モードのクラスタよりもデフォルトのセキュリティ ポスチャーが厳しくなっています。

このドキュメントのベスト プラクティスを組織全体で実装して適用するには、次のサービスを検討してください。

  • Security Command Center: クラスタがこれらのベスト プラクティスの多くを実装しているかどうかを自動的に確認し、その他の一般的な構成ミスを確認します。
  • 組織のポリシー サービス: 組織、フォルダ、プロジェクト内の GKE リソースに特定のベスト プラクティスを適用します。このドキュメントの特定のセクションには、 Google Cloud コンソールへのリンクがあり、これらの推奨事項にマネージド制約を適用できます。

Google Cloud 環境設計

以降のセクションでは、 Google Cloudでリソースを計画して設計する際に考慮すべきセキュリティ対策について説明します。クラウド アーキテクトは、 Google Cloud アーキテクチャの計画と定義を行う際に、これらの推奨事項を使用する必要があります。

ベスト プラクティス

Google Cloud リソース構造を計画する

推奨: Google のベスト プラクティスに基づくエンタープライズ環境の完全な基盤であるエンタープライズ基盤ブループリントを実装します。

Google Cloud 組織、フォルダ、プロジェクトのアーキテクチャは、セキュリティ ポスチャーに影響します。これらの基盤となるリソースは、サービス全体でガバナンスとセキュリティ コントロールを大規模に実現できるように設計します。

マルチテナント環境を計画する

推奨: マルチテナント エンタープライズ プラットフォームに Google Cloud と GKE のベスト プラクティスを実装します。

多くの GKE ユーザーは、別々のエンジニアリング ワークフローと責任を持つ分散チームを管理しています。これらのマルチテナント環境には、すべてのデベロッパーが使用できる共有インフラストラクチャが必要です。同時に、ロールと責任に基づいてコンポーネントへのアクセスを制限する必要があります。エンタープライズ アプリケーション ブループリントは、エンタープライズ基盤ブループリントに基づいて、マルチテナント環境に内部デベロッパー プラットフォームをデプロイできるようにします。

詳細については、次のドキュメントをご覧ください。

タグを使用して Google Cloud リソースをグループ化する

推奨: タグを使用して GKE リソースを整理し、条件付きポリシーの適用とチーム間のアカウンタビリティの向上を実現します。

タグは、組織、フォルダ、プロジェクトのリソースに付加して、Google Cloud リソース階層全体でビジネス ディメンションを識別できるメタデータです。タグを GKE クラスタとノードプールに適用し、それらのタグを使用して組織のポリシー、IAM ポリシー、ファイアウォール ポリシーを条件付きで適用できます。

詳細については、次のドキュメントをご覧ください。

VPC ネットワークを計画する

推奨: VPC ネットワーク設計に Google Cloud と GKE のベスト プラクティスを実装します。

VPC ネットワークの設計と使用する機能は、ネットワーク セキュリティに影響します。 Google Cloudリソース階層とセキュリティ目標に基づいてネットワークを計画します。詳細については、次のドキュメントをご覧ください。

インシデント対応計画を設計する

推奨: セキュリティと信頼性の目標を満たすインシデント対応計画を作成して維持します。

考えられるすべてのセキュリティ コントロールを実装しても、セキュリティ インシデントが発生する可能性があります。インシデント対応計画は、セキュリティ コントロールの潜在的なギャップを特定し、さまざまなタイプのインシデントに迅速かつ効果的に対応して、停止時のダウンタイムを短縮するのに役立ちます。詳細については、次のドキュメントをご覧ください。

Google Cloud ネットワーク セキュリティ

以降のセクションでは、VPC ネットワークのセキュリティに関する推奨事項について説明します。ネットワーク アーキテクトとネットワーク管理者は、これらの推奨事項を適用して、ネットワーク レベルでの攻撃対象領域を縮小し、意図しないネットワーク アクセスの影響を制限する必要があります。

ベスト プラクティス

最小権限のファイアウォール ルールを使用する

推奨: ファイアウォール ルールを作成する場合は、最小権限の原則に従って、必要な目的に限りアクセス権を付与します。可能な場合は、ファイアウォール ルールが GKE のデフォルトのファイアウォール ルールと競合したり、オーバーライドしないようにしてください。

GKE は、システム機能を有効にし、適切なセキュリティ対策を適用するために、デフォルトの VPC ファイアウォール ルールを作成します。デフォルトのファイアウォール ルールよりも優先度が高く、制限の緩いファイアウォール ルール（デバッグ用のすべての上り（内向き）トラフィックを許可するファイアウォール ルールなど）を作成すると、クラスタが意図しないアクセスを受けるリスクがあります。

プロジェクト間のトラフィックに共有 VPC を使用する

推奨: 共有 VPC を使用して、複数のプロジェクトのリソースが内部 IP アドレスを使用して相互に通信できるようにします。

組織内の異なるプロジェクトのリソースで相互通信が必要になる場合があります。たとえば、あるプロジェクトの GKE クラスタのフロントエンド サービスが、別のプロジェクトのバックエンド Compute Engine インスタンスと通信する必要がある場合があります。

詳細については、次のドキュメントをご覧ください。

個別のネットワークを使用して環境を分離する

推奨: ステージング環境、テスト環境、本番環境に個別の共有 VPC ネットワークを使用します。

開発環境を相互に分離して、不正アクセスや破壊的なバグの影響とリスクを軽減します。詳細については、複数のホスト プロジェクトをご覧ください。

変更不可のセキュリティ設定

以降のセクションでは、クラスタまたはノードプールの作成時にのみ構成できるセキュリティの推奨事項について説明します。既存のクラスタまたはノードプールを更新して、これらの設定を変更することはできません。プラットフォーム管理者は、これらの推奨事項を新しいクラスタとノードプールに適用する必要があります。

最小権限の IAM ノード サービス アカウントを使用する

推奨: デフォルトの Compute Engine サービス アカウントを使用するのではなく、GKE クラスタとノードプールにカスタム IAM サービス アカウントを使用します。

GKE は、ノードに接続されている IAM サービス アカウントを使用して、ロギングやモニタリングなどのシステムタスクを実行します。これらのノードサービス アカウントには、プロジェクトに対する Kubernetes Engine デフォルト ノードサービス アカウント（roles/container.defaultNodeServiceAccount）ロールが最低限必要です。デフォルトでは、GKE はプロジェクトに自動的に作成される Compute Engine のデフォルトのサービス アカウントをノード サービス アカウントとして使用します。

プロジェクトまたは組織内の他の機能に Compute Engine のデフォルトのサービス アカウントを使用すると、サービス アカウントに GKE が必要とする以上の権限が付与され、セキュリティ リスクにさらされる可能性があります。

ノードに接続されているサービス アカウントは、ロギングやモニタリングなどのタスクを実行するシステム ワークロードでのみ使用する必要があります。独自のワークロードの場合は、Workload Identity Federation for GKE を使用して ID をプロビジョニングします。

組織でこの推奨事項を適用するには、constraints/container.managed.disallowDefaultComputeServiceAccount 管理対象の組織のポリシーの制約を使用します。 Google Cloud コンソールでこのマネージド制約を確認するには、[ポリシーの詳細] ページに移動します。

[ポリシーの詳細] に移動

Container-Optimized OS ノードイメージを使用する

推奨: Ubuntu または Windows を使用する特定の要件がない限り、ノードに Container-Optimized OS ノードイメージを使用します。

Container-Optimized OS は、コンテナの実行専用に構築、最適化、強化されています。Container-Optimized OS は、Autopilot モードでサポートされている唯一のノードイメージであり、Standard モードのデフォルトのノードイメージです。

詳細については、次のドキュメントをご覧ください。

ノードのセキュリティ構成

以降のセクションでは、GKE ノード構成に関するセキュリティの推奨事項について説明します。プラットフォーム管理者とセキュリティ エンジニアは、これらの推奨事項を適用して GKE ノードの完全性を改善する必要があります。

ベスト プラクティス

シールドされた GKE ノードを使用する

推奨: すべてのクラスタとノードプールで、シールドされた GKE ノード、セキュアブート、完全性モニタリングを有効にします。

シールドされた GKE ノードは、ノードのセキュリティを強化する検証可能な ID と整合性チェックを提供します。Autopilot クラスタでは、Shielded GKE Nodes と、ノードの整合性モニタリングやセキュアブートなどの機能が常に有効になっています。Standard クラスタで次の操作を行います。

  • クラスタで Shielded GKE Nodes を無効にしないでください。
  • すべてのノードプールでセキュアブートを有効にします。
  • ノードプールで整合性モニタリングを無効にしないでください。

これらの機能を有効にする方法については、シールドされた GKE ノードの使用をご覧ください。

組織でこの推奨事項を適用するには、constraints/container.managed.enableShieldedNodes 管理対象の組織のポリシーの制約を使用します。 Google Cloud コンソールでこのマネージド制約を確認するには、[ポリシーの詳細] ページに移動します。

[ポリシーの詳細] に移動

安全でない kubelet 読み取り専用ポートを無効にする

推奨: kubelet 読み取り専用ポートを無効にし、ポート 10255 を使用するワークロードがより安全なポート 10250 を使用するように切り替えます。

ノードで実行されている kubelet プロセスは、安全でないポート 10255 を使用して読み取り専用 API を提供します。Kubernetes では、このポートに対して認証や認可のチェックが行われません。kubelet は、より安全な認証済みのポート 10250 で同じエンドポイントにサービスを提供します。

詳細については、GKE クラスタで kubelet 読み取り専用ポートを無効にするをご覧ください。

組織でこの推奨事項を適用するには、constraints/container.managed.disableInsecureKubeletReadOnlyPort 管理対象の組織のポリシーの制約を使用します。 Google Cloud コンソールでこのマネージド制約を確認するには、[ポリシーの詳細] ページに移動します。

[ポリシーの詳細] に移動

アクセス制御

以降のセクションでは、クラスタでの不正なアクセスを制限するための推奨事項について説明します。セキュリティ エンジニアと ID 管理者、アカウント管理者は、これらの推奨事項を適用して攻撃対象領域を減らし、不正アクセスの影響を制限する必要があります。

ベスト プラクティス

クラスタ API 検出へのアクセスを制限する

推奨: クラスタ API 検出エンドポイントへの意図しないアクセスを防ぐため、インターネットからのコントロール プレーンとノードへのアクセスを制限します。

デフォルトでは、Kubernetes は制約の緩いデフォルトの API 検出ロールのセットでクラスタを作成します。これらのデフォルト ロールは、system:authenticated などのさまざまなデフォルト グループに、クラスタの API に関する情報への幅広いアクセス権を付与します。これらのデフォルト ロールは、GKE クラスタのセキュリティ レベルを意味するものではありません。たとえば、CustomResources などの API に関する情報を読み取ることができる system:authenticated グループは、認証済みユーザー（Google アカウントを持つユーザーを含む）に割り当てられます。

クラスタ検出 API へのアクセスを制限する手順は次のとおりです。

  • コントロール プレーンへのアクセスを制限する: コントロール プレーンへのアクセスに DNS ベースのエンドポイントのみを使用します。IP ベースのエンドポイントを使用する場合は、承認済みネットワークを構成して、既知のアドレス範囲のセットへのアクセスを制限します。
  • プライベート ノードを構成する: ノードの外部 IP アドレスを無効にして、ネットワーク外のクライアントがノードにアクセスできないようにします。

詳細については、ネットワーク分離についてをご覧ください。

これらのネットワーク分離機能を有効にしない場合は、すべての API 検出情報（特に CustomResources のスキーマ、APIService の定義、拡張 API サーバーでホストされている検出情報）を一般公開として扱います。

チームと環境を別々の Namespace またはクラスタに配置する

各チームと環境に個別の Namespace またはクラスタを作成して、チームに付与する Kubernetes へのアクセス権限を最低限に抑えます。Namespace またはクラスタごとに、アカウンタビリティとチャージバックのコストセンターとラベルを割り当てます。

IAM と RBAC の権限を Namespace と併用すると、 Google Cloud コンソールのクラスタ リソースに対するユーザー操作を制限できます。詳細については、アクセスを有効にしてクラスタ リソースを Namespace ごとに表示するをご覧ください。

アクセス ポリシーで最小権限の原則を使用する

推奨: デベロッパーには、特に本番環境において、Namespace でアプリケーションをデプロイして管理するために必要なアクセス権のみを付与します。アクセス制御ポリシーを設計するときは、ユーザーがクラスタで実行する必要のあるタスクをマッピングし、それらのタスクの実行に必要な権限のみを付与します。

GKE では、IAM と Kubernetes ロールベース アクセス制御（RBAC）を使用して、リソースに対する権限を付与できます。これらのアクセス制御メカニズムは連携して動作します。アクセス管理の複雑さを軽減するには、次の操作を行います。

  • プロジェクトまたは Google Cloud リソースへのアクセス権を付与するには、IAM ロールを使用します。

  • Namespace などのクラスタ内の Kubernetes リソースへのアクセス権を付与するには、RBAC を使用します。

IAM ポリシーと RBAC ポリシーの計画と設計の詳細については、次のドキュメントをご覧ください。

Workload Identity Federation for GKE を使用して Google Cloud API にアクセスする

推奨: GKE ワークロードから Google Cloud リソースにアクセスするには、Workload Identity Federation for GKE を使用します。

Google Cloud API に対する認証に推奨される方法は、Workload Identity Federation for GKE です。クラスタ内のプリンシパル（特定の Kubernetes ServiceAccount や Pod など）に、さまざまなリソースに対する IAM ロールを付与できます。Workload Identity Federation for GKE は、ノード上の機密メタデータを保護し、静的トークン ファイルなどの代替手段よりも安全な認証ワークフローを提供します。

Workload Identity Federation for GKE は、Autopilot クラスタで常に有効になっています。Standard クラスタでは、すべてのクラスタとノードプールで Workload Identity Federation for GKE を有効にします。また、次の推奨事項も参考にしてください。

  • アプリケーション コードで Google Cloud クライアント ライブラリを使用する場合は、ワークロードに Google Cloud 認証情報を配布しないでください。クライアント ライブラリを使用するコードは、Workload Identity Federation for GKE の認証情報を自動的に取得します。
  • 個別の ID が必要なワークロードごとに、個別の Namespace と ServiceAccount を使用します。特定の ServiceAccount に IAM 権限を付与します。

詳細については、GKE ワークロードから Google Cloud API に対する認証を行うをご覧ください。

組織でこの推奨事項を適用するには、constraints/container.managed.enableWorkloadIdentityFederation 管理対象の組織のポリシーの制約を使用します。 Google Cloud コンソールでこのマネージド制約を確認するには、[ポリシーの詳細] ページに移動します。

[ポリシーの詳細] に移動

グループを使用してアクセスを管理する

推奨: アクセス ポリシーで、個人ではなくユーザーのグループに権限を付与します。

グループでユーザーを管理すると、ID 管理システムと ID 管理者は、さまざまなグループのユーザー メンバーシップを変更することで、ID を一元的に制御できます。このタイプの管理では、特定のユーザーに更新された権限が必要になるたびに RBAC ポリシーまたは IAM ポリシーを更新する必要がなくなります。

IAM ポリシーまたは RBAC ポリシーで Google グループを指定できます。詳細については、次のドキュメントをご覧ください。

組織でこの推奨事項を適用するには、constraints/container.managed.enableGoogleGroupsRBAC 管理対象の組織のポリシーの制約を使用します。 Google Cloud コンソールでこのマネージド制約を確認するには、[ポリシーの詳細] ページに移動します。

[ポリシーの詳細] に移動

クラスタ エンドポイントへの匿名アクセスを制限する

推奨: すべての Autopilot クラスタと Standard クラスタで、ヘルスチェック エンドポイントを除くすべてのクラスタ エンドポイントへの匿名リクエストを防止します。

デフォルトでは、Kubernetes はクラスタ エンドポイントへの匿名リクエストに system:anonymous ユーザーと system:unauthenticated グループを割り当てます。RBAC ポリシーでこのユーザーまたはグループに追加の権限が付与されている場合、匿名ユーザーがサービスまたはクラスタ自体のセキュリティを侵害する可能性があります。

GKE バージョン 1.32.2-gke.1234000 以降では、匿名リクエストが到達できるエンドポイントのセットを /healthz、/livez、/readyz の Kubernetes API サーバー ヘルスチェック エンドポイントのみに制限できます。これらのヘルスチェック エンドポイントへの匿名アクセスは、クラスタが正常に動作していることを確認するために必要です。

クラスタ エンドポイントへの匿名アクセスを制限するには、gcloud CLI または GKE API を使用して Standard クラスタと Autopilot クラスタを作成または更新するときに、--anonymous-authentication-config フラグに LIMITED を指定します。GKE は、認証中にヘルスチェック エンドポイントではないクラスタ エンドポイントへの匿名リクエストを拒否します。RBAC ポリシーで匿名ユーザーとグループにアクセス権が付与されていても、匿名リクエストはエンドポイントに到達しません。拒否されたリクエストは、HTTP ステータス 401 を返します。

組織のポリシーを使用して、組織、フォルダ、またはプロジェクトでこの推奨事項を適用するには、resource.anonymousAuthenticationConfig.mode 条件でカスタム制約を作成します。詳細と制約の例については、カスタムの組織のポリシーを使用して GKE リソースに対するアクションを制限するをご覧ください。

クラスタを保護するために、この機能だけに依存しないでください。次のような追加のセキュリティ対策を実装します。

GKE ネットワーク セキュリティ

以降のセクションでは、クラスタのネットワーク セキュリティを強化するための推奨事項について説明します。ネットワーク管理者とセキュリティ エンジニアは、これらの推奨事項を適用して、意図しない外部または内部アクセスからワークロードとインフラストラクチャを保護する必要があります。

ベスト プラクティス

コントロール プレーンへのアクセスを制限する

推奨: コントロール プレーン アクセス用に DNS ベースのエンドポイントを有効にし、すべての IP ベースのコントロール プレーン エンドポイントを無効にします。

デフォルトでは、インターネット上のクライアントなどの外部エンティティはコントロール プレーンにアクセスできます。ネットワーク分離を構成することで、コントロール プレーンにアクセスできるユーザーを制限できます。

コントロール プレーンを分離するには、次のいずれかを行います。

  • DNS ベースのエンドポイントのみを使用する（推奨）: コントロール プレーンの DNS ベースのエンドポイントを有効にし、内部 IP ベースのエンドポイントと外部 IP ベースのエンドポイントを無効にします。すべてのコントロール プレーン アクセスで DNS ベースのエンドポイントを使用する必要があります。VPC Service Controls を使用して、DNS ベースのエンドポイントにアクセスできるユーザーを制御できます。

    組織でこの推奨事項を適用するには、constraints/container.managed.enableControlPlaneDNSOnlyAccess 管理対象の組織のポリシーの制約を使用します。 Google Cloud コンソールでこのマネージド制約を確認するには、[ポリシーの詳細] ページに移動します。

    [ポリシーの詳細] に移動

  • 外部 IP ベースのエンドポイントを無効にする: コントロール プレーンの外部 IP アドレスを削除します。VPC ネットワークの外部にあるクライアントは、外部 IP アドレスを使用してコントロール プレーンにアクセスできません。

    このオプションは、Cloud Interconnect や Cloud VPN などのテクノロジーを使用して企業ネットワークを VPC ネットワークに接続する場合に適しています。

  • 外部 IP ベースのエンドポイントで承認済みネットワークを使用する: 外部 IP ベースのエンドポイントへのアクセスを、信頼できるソース IP アドレスの範囲のみに制限します。

    このオプションは、既存の VPN インフラストラクチャがない場合や、リモート ユーザーや支社が公共のインターネットを使用してクラスタにアクセスする場合に適しています。

ほとんどの場合、コントロール プレーンへのアクセスには DNS ベースのエンドポイントのみを使用します。IP ベースのエンドポイントを有効にする必要がある場合は、承認済みネットワークを使用して、コントロール プレーンへのアクセスを次のエンティティに制限します。

  • 指定した IP アドレス範囲。
  • クラスタと同じ VPC ネットワーク内の GKE ノード。
  • クラスタ管理用に Google が予約した IP アドレス。

ノードをインターネットから分離する

デフォルトでは、すべての GKE ノードに、インターネット上のクライアントが到達できる外部 IP アドレスが割り当てられます。この外部 IP アドレスを削除するには、プライベート ノードを有効にします。

組織でこの推奨事項を適用するには、constraints/container.managed.enablePrivateNodes 管理対象の組織のポリシーの制約を使用します。 Google Cloud コンソールでこのマネージド制約を確認するには、[ポリシーの詳細] ページに移動します。

[ポリシーの詳細] に移動

Pod 間のネットワーク トラフィックを制限する

推奨: NetworkPolicy、サービス メッシュ、またはその両方を使用して、Pod 間のネットワーク トラフィックを制御します。

デフォルトでは、クラスタ内のすべての Pod が他のすべての Pod と通信できます。サービス間のネットワーク アクセスを制限することで、攻撃者によるクラスタ内での横移動の難易度を大幅に上げることができます。また、偶発的または意図的なサービス拒否インシデントからサービスをある程度保護することもできます。要件に応じて、次のいずれかまたは両方の方法を使用して、Pod 間トラフィックを制限します。

  • ロード バランシング、サービス認可、スロットリング、割り当て、指標などの機能が必要な場合は、Cloud Service Mesh を使用します。サービス メッシュは、相互に複雑なやり取りを行う多数の異なるサービスがある場合に便利です。

  • 基本的なトラフィック フロー制御メカニズムが必要な場合は、Kubernetes NetworkPolicy を使用します。NetworkPolicy が想定どおりに動作することを確認するには、ネットワーク ポリシー ロギングを構成します。

    組織でこの推奨事項を適用するには、constraints/container.managed.enableNetworkPolicy 管理対象の組織のポリシーの制約を使用します。 Google Cloud コンソールでこのマネージド制約を確認するには、[ポリシーの詳細] ページに移動します。

    [ポリシーの詳細] に移動

機密データの保護

以降のセクションでは、データの暗号化と、認証情報などの機密情報の保護に関する推奨事項について説明します。セキュリティ エンジニアとプラットフォーム管理者は、これらの推奨事項を適用して、重要なデータへの意図しないアクセスが発生するリスクを軽減する必要があります。

ベスト プラクティス

使用中のワークロード データを暗号化する

Confidential GKE Node を使用して、ハードウェア ベースのメモリ暗号化を使用し、ワークロードで使用中のデータを保護します。要件に基づいて Confidential Computing テクノロジーを選択できます。詳細については、Confidential GKE Node で使用中のワークロード データを暗号化するをご覧ください。

クラスタ外にシークレットを保存する

推奨: Secret Manager などの外部シークレット マネージャーを使用して、API キーなどの機密データをクラスタの外部に保存します。

Kubernetes では、クラスタ内の Secret に機密データを保存できます。Secret を使用すると、アプリケーション コードに機密データを含めることなく、アプリケーションに機密データを提供できます。ただし、このデータをクラスタに保存すると、次のようなリスクがあります。

  • Namespace で Pod を作成できるユーザーは、その Namespace 内の任意の Secret のデータを読み取ることができます。
  • すべての Kubernetes API オブジェクトを読み取る RBAC または IAM アクセス権を持つユーザーは、Secret を読み取ることができます。

このようなリスクがあるため、クラスタにシークレットを作成するのは、他の方法でワークロードにデータを提供できない場合に限ります。機密データを保存してアクセスするには、次の方法を優先順位の高い順におすすめします。

  • Secret Manager クライアント ライブラリ: Workload Identity Federation for GKE で Secret Manager API を使用して、アプリケーション コードからシークレットにプログラムでアクセスします。詳細については、クライアント ライブラリを使用して GKE クラスタの外部に保存されているシークレットにアクセスするをご覧ください。
  • マウントされたボリュームとしての Secret Manager データ: GKE 用の Secret Manager アドオンを使用して、マウントされたボリュームとして Pod に機密データを提供します。この方法は、Secret Manager クライアント ライブラリを使用するようにアプリケーション コードを変更できない場合に便利です。詳細については、Google Kubernetes Engine で Secret Manager アドオンを使用するをご覧ください。

  • サードパーティのシークレット管理ツール: HashiCorp Vault などのサードパーティ ツールは、Kubernetes ワークロードのシークレット管理機能を提供します。これらのツールは Secret Manager よりも多くの初期構成が必要になりますが、クラスタでシークレットを作成するよりも安全なオプションです。シークレット管理用にサードパーティ ツールを構成する方法については、プロバイダのドキュメントをご覧ください。また、次の推奨事項も検討してください。

    • サードパーティ ツールがクラスタで実行されている場合は、ワークロードを実行するクラスタとは異なるクラスタを使用します。
    • Cloud Storage または Spanner を使用して、ツールのデータを保存します。
    • 内部パススルー ネットワーク ロードバランサを使用して、VPC ネットワークで実行される Pod にサードパーティのシークレット管理ツールを公開します。

  • Kubernetes Secret を使用する（おすすめしません）: 上記のいずれのオプションもユースケースに適していない場合は、データを Kubernetes Secret として保存できます。Google Cloudは、デフォルトでストレージ レイヤでデータを暗号化します。このデフォルトのストレージ レイヤの暗号化には、クラスタの状態を保存するデータベースが含まれます。このデータベースは、etcd または Spanner に基づいています。また、自分が管理している鍵を使用して、アプリケーション レイヤでこれらのシークレットを暗号化することもできます。詳細については、アプリケーション レイヤでシークレットを暗号化するをご覧ください。

ワークロード セキュリティ

以降のセクションでは、ワークロードの問題に対するクラスタのセキュリティを強化するための推奨事項について説明します。セキュリティ エンジニアとプラットフォーム管理者は、これらの推奨事項を適用して、ワークロードからの GKE インフラストラクチャの保護を強化する必要があります。

ベスト プラクティス

GKE Sandbox を使用してワークロードを分離する

推奨: GKE Sandbox を使用して、悪意のあるコードがクラスタノードのホストカーネルに影響を与えないようにします。

サンドボックス環境でコンテナを実行すると、ほとんどのコンテナ エスケープ攻撃（ローカル権限昇格攻撃とも呼ばれる）を軽減できます。GKE セキュリティに関する公開情報で説明されているように、このタイプの攻撃では、攻撃者はコンテナのホスト VM にアクセスします。攻撃者はこのホストアクセスを使用して、同じ VM 上の他のコンテナにアクセスできます。GKE Sandbox は、このような攻撃の影響を抑えるのに役立ちます。

GKE Sandbox は、次のようなシナリオで使用します。

  • 信頼できないコードを実行するワークロードがある。
  • ワークロード内のコンテナが攻撃者によって不正使用された場合の影響を制限する必要がある。

詳細については、GKE Sandbox によるワークロード分離の強化をご覧ください。

ワークロードの自己変更機能を制限する

推奨: アドミッション コントローラを使用して、ワークロードの自己変更を防ぐか、ServiceAccount などのリスクの高いワークロード属性の変更を防ぎます。

特定の Kubernetes ワークロード（特にシステム ワークロード）には、自己変更の権限があります。たとえば、一部のワークロードは垂直方向に自動スケーリングされます。これは便利ですが、すでにノードを不正使用した攻撃者がクラスタ内でさらに攻撃を行う可能性があります。たとえば、攻撃者が Namespace 内のワークロード自体を変更して、同じ Namespace 内のより権限の高い ServiceAccount として実行するおそれがあります。

必要がない限り、Pod に自己変更の権限を付与しないでください。一部の Pod で自己変更が必要な場合は、Policy Controller を使用して、ワークロードで変更できる内容を制限します。たとえば、NoUpdateServiceAccount 制約テンプレートを使用すると、Pod が ServiceAccount を変更できないようにできます。ポリシーを作成するときは、次の例のように、クラスタ管理コンポーネントを制約から除外します。

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

ポリシーベースの適用

以降のセクションでは、ポリシーを使用して複数のリソースにセキュリティ制約を適用するための推奨事項について説明します。ID 管理者、アカウント管理者、セキュリティ エンジニアは、組織のセキュリティ要件に対するクラスタとワークロードのコンプライアンスを維持するために、これらの推奨事項を適用する必要があります。

ベスト プラクティス

Google Cloud リソース階層全体にポリシーを適用する

推奨: 組織、フォルダ、プロジェクトでセキュリティ対策を適用するには、組織のポリシー サービスを使用します。

組織のポリシーを使用すると、制約を一元的に定義し、リソース階層のさまざまなレベルで適用できます。さまざまな Google Cloud プロダクトは、そのプロダクトのベスト プラクティスの推奨事項を適用できるマネージド制約を公開しています。たとえば、GKE はこのドキュメントの多くのベスト プラクティスに対してマネージド制約を公開しています。

組織のポリシーを有効にする方法については、組織のポリシーの作成と管理をご覧ください。

ワークロードの承認時にポリシーを適用する

推奨: Policy Controller や PodSecurity アドミッション コントローラなどのアドミッション コントローラを使用して、受信 API リクエストを確認し、それらのリクエストにポリシーを適用します。

アドミッション コントローラは、認証および認可された Kubernetes API へのリクエストをインターセプトし、リソースが API に永続化される前に検証またはミューテーション タスクを実行します。

GKE クラスタでは、次の方法で承認制御を行うことができます。

クラスタ管理

以降のセクションでは、アップグレード、モニタリング、ログの構成など、クラスタを長期にわたって管理するための推奨事項について説明します。セキュリティ エンジニア、プラットフォーム管理者、SRE は、これらの推奨事項を使用して GKE プラットフォームのセキュリティ ポスチャーを維持する必要があります。

ベスト プラクティス

GKE インフラストラクチャを定期的にアップグレードする

推奨: GKE バージョンを最新の状態に保ち、新しいセキュリティ機能にアクセスしてセキュリティ パッチを適用します。リリース チャンネル、高速パッチ自動アップグレード、ノードの自動アップグレードを使用します。

Kubernetes と GKE は、セキュリティの改善と脆弱性の修正を含む新しいパッチ バージョンを頻繁にリリースします。すべてのクラスタで、GKE はより安定したマイナー バージョンとパッチ バージョンにコントロール プレーンを自動的にアップグレードします。

GKE クラスタで最新バージョンが実行されるようにするには、次の操作を行います。

  • クラスタをリリース チャンネルに登録します。Autopilot クラスタは常にリリース チャンネルに登録されます。
  • リリース チャンネルにあるクラスタの場合は、高速パッチ自動アップグレードを有効にします。これにより、リリース チャンネルでセキュリティ パッチ バージョンが利用可能になるとすぐにパッチを取得します。
  • リリース チャンネルに登録されていない Standard クラスタの場合は、ノードの自動アップグレードを有効にします。ノードの自動アップグレードは、Google Cloud コンソールを使用して作成されたクラスタに対しては 2019 年 6 月から、GKE API を使用して作成されたクラスタに対しては 2019 年 11 月 11 日からデフォルトで有効になっています。
  • メンテナンス ポリシーを使用する場合は、メンテナンスの時間枠を使用して、GKE がノードを少なくとも月に 1 回自動アップグレードできるようにします。
  • ノードの自動アップグレードを使用しないノードプールでは、独自のスケジュールで少なくとも月に 1 回はノードプールをアップグレードします。
  • セキュリティ パッチの詳細については、GKE セキュリティに関する公開情報と GKE リリースノートをご覧ください。

セキュリティに関する公開情報の通知を有効にする

推奨: クラスタに影響する新しいセキュリティに関する公開情報の通知を構成します。

クラスタに関連するセキュリティ情報が利用可能になると、GKE はそれらのイベントに関する通知を構成済みの Pub/Sub トピックにメッセージとして公開します。これらの通知は、Pub/Sub サブスクリプションで受信し、サードパーティ サービスと統合して、Cloud Logging で通知を受信できます。

組織でこの推奨事項を適用するには、constraints/container.managed.enableSecurityBulletinNotifications 管理対象の組織のポリシーの制約を使用します。 Google Cloud コンソールでこのマネージド制約を確認するには、[ポリシーの詳細] ページに移動します。

[ポリシーの詳細] に移動

ログ収集を構成する

推奨: 運用上のオーバーヘッドを削減し、ログの統合ビューを維持するには、クラスタ全体で一貫したロギング方法を実装します。Standard クラスタでログ収集を無効にしないでください。

GKE クラスタは、特定のログを Google Cloud Observability に送信します。必要に応じて、追加の種類のログの収集を構成できます。システムログとワークロード ログに加えて、すべての GKE クラスタは次の監査ログを Logging に送信します。

  • Kubernetes 監査ログ: Kubernetes API サーバーに対して行われた呼び出しの時系列記録。Kubernetes 監査ログのエントリは、不審な API リクエストの調査、統計情報の収集、不要な API 呼び出しに対するモニタリング アラートの作成に役立ちます。
  • GKE 監査ログ: GKE API の管理アクティビティとアクセス アクティビティの記録。

詳細については、次のドキュメントをご覧ください。

組織でこの推奨事項を適用するには、constraints/container.managed.enableCloudLogging 管理対象の組織のポリシーの制約を使用します。 Google Cloud コンソールでこのマネージド制約を確認するには、[ポリシーの詳細] ページに移動します。

[ポリシーの詳細] に移動

リソースのセキュリティ上の問題をモニタリングする

GKE セキュリティ ポスチャー ダッシュボードと Security Command Center を使用して、クラスタとワークロードで発生する可能性のある問題をモニタリングします。これらのサービスを使用して、GKE インフラストラクチャに影響するアクティブな脆弱性、脅威、セキュリティ速報を確認できます。

デフォルトのセキュリティ構成

以降のセクションでは、新しいクラスタでデフォルトで構成され、脆弱性やリスクなどの特定のセキュリティ上の懸念を軽減するオプションについて説明します。セキュリティ エンジニアとプラットフォーム管理者は、既存のクラスタでこれらの設定が使用されていることを確認する必要があります。

ベスト プラクティス

以前のクライアント認証方式を無効のままにする

推奨: 静的証明書やパスワードなどの以前の API サーバー認証方法を無効にします。

Kubernetes API サーバーに対する認証方法は、複数存在します。GKE でサポートされる方法は、サービス アカウントの署名なしトークン、OAuth トークン、X.509 クライアント証明書です。gcloud CLI は、OAuth トークンを使用して GKE のユーザーを認証します。

静的パスワードなどの以前の認証方法は、クラスタの不正使用を招く攻撃対象範囲が広がるため、無効になっています。Autopilot クラスタでは、これらの認証方法を有効にしたり使用することはできません。

Kubernetes API サーバーに対する認証には、次のいずれかの方法で行います。

  • ユーザー: gcloud CLI を使用して、GKE がユーザーを認証し、クラスタの OAuth アクセス トークンを生成して、トークンを最新の状態に保つようにします。
  • アプリケーション: Workload Identity 連携を使用して、Google Cloud または他の環境のアプリケーションがクラスタに対して認証できるようにします。

認証方法と以前の認証方法を無効にする方法については、Kubernetes API サーバーに対して認証を行うをご覧ください。

組織でこの推奨事項を適用するには、constraints/container.managed.disableLegacyClientCertificateIssuance 管理対象の組織のポリシーの制約を使用します。 Google Cloud コンソールでこのマネージド制約を確認するには、[ポリシーの詳細] ページに移動します。

[ポリシーの詳細] に移動

ABAC を無効のままにする

推奨: IAM と RBAC を使用して GKE でアクセスを制御します。属性ベースのアクセス制御（ABAC）を有効にしないでください。

ABAC は、すべての GKE クラスタでデフォルトで無効になっている以前の認可方法です。Autopilot クラスタでは有効にできません。

組織でこの推奨事項を適用するには、constraints/container.managed.disableABAC 管理対象の組織のポリシーの制約を使用します。 Google Cloud コンソールでこのマネージド制約を確認するには、[ポリシーの詳細] ページに移動します。

[ポリシーの詳細] に移動

DenyServiceExternalIPs アドミッション コントローラを有効のままにする

推奨: DenyServiceExternalIPs アドミッション コントローラを無効にしないでください。

このアドミッション コントローラは、Service が ExternalIPs を使用できないようにするとともに、GCP-2020-015 を緩和します。このアドミッション コントローラは、GKE バージョン 1.21 以降で作成されたクラスタではデフォルトで有効になっています。以前の GKE バージョンで最初に作成されたクラスタの場合は、アドミッション コントローラを有効にします。

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips
組織でこの推奨事項を適用するには、constraints/container.managed.denyServiceExternalIPs 管理対象の組織のポリシーの制約を使用します。 Google Cloud コンソールでこのマネージド制約を確認するには、[ポリシーの詳細] ページに移動します。

[ポリシーの詳細] に移動

次のステップ