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

Kubernetes の開発ペースは速く、新たなセキュリティ機能がしばしば登場します。このドキュメントでは、Google Distributed Cloud クラスタを強化する方法について説明します。

このドキュメントでは、クラスタの作成時にお客様の操作が必要となる価値のあるセキュリティ対策を優先します。重要性の低い機能、デフォルトでセキュアな設定、作成後に有効にできる項目についてはドキュメントの後半でご説明します。セキュリティの一般的な概要については、セキュリティをご覧ください。

チェックリスト

次のデプロイ チェックリストは、GKE クラスタ プラットフォームのデプロイ強化のためのベスト プラクティスを示しています。各プラクティスの詳細については、このドキュメントのセクションをご覧ください。

デプロイ チェックリスト 説明
ID とアクセス制御

vSphere のアカウント権限の使用:
vSphere 管理者アカウントを最小権限で使用します。

安全な Google Cloud サービス アカウント:
Google Cloud サービス アカウントの権限を最小限に制限します。

OpenID Connect（OIDC）の構成:
ユーザー認証用に OpenID Connect を構成します。

Kubernetes Namespace と RBAC を使用してアクセスを制限する:
RBAC で Namespace を使用して、管理を分離し、最小限の権限ロールと資格を使用します。
データの保護

vSphere 仮想マシンを暗号化する:
Google Distributed Cloud で使用されるボリュームを暗号化するように vSphere を設定します。

Secret を管理する:
保存時に Secret を暗号化します。
ネットワーク保護

コントロール プレーンとノードへのネットワーク アクセスを制限する:
コントロール プレーン ネットワークとノードを分離して保護するためにコントロールを設定します。

ネットワーク ポリシーを使用してトラフィックを制限する:
ネットワーク ポリシーを実装してクラスタ内のトラフィックを制限します。
宣言型セキュリティ

Policy Controller を使用する:
クラスタ内の宣言型セキュリティ ポリシー用に Policy Controller をインストールします。
メンテナンス

GKE Enterprise をアップグレードする:
使用しているプラットフォーム用の GKE Enterprise の最新バージョンを実行します。

セキュリティ情報を監視する:
GKE Enterprise のセキュリティに関する公開情報で、バージョニングに関する最新のアドバイスとガイダンスを確認します。
モニタリングとロギング

GKE クラスタのロギング オプションを設定する:
ロギングが有効で、SIEM ソリューションに統合されていることを確認します。

ID とアクセス制御

このセクションでは、クラスタへのアクセスを制御する方法について説明します。

vSphere アカウント権限を使用する

Google Distributed Cloud のインストールに使用する vCenter ユーザー アカウントには、十分な権限が必要です。たとえば、vCenter の管理者ロールが割り当てられたユーザー アカウントには、すべての vCenter オブジェクトに対する完全アクセス権限があり、Google Distributed Cloud クラスタ管理者に完全アクセス権を付与できます。

最小権限の原則に従い、GKE Enterprise を正常にインストールするために必要な権限のみを付与することをおすすめします。インストールの実行に必要な最小権限セットと、それらの権限を付与するために必要なコマンドが用意されています。

安全な Google Cloud サービス アカウント

Google Distributed Cloud には、3 つの Google Cloud サービス アカウントが必要です。

  • Google Distributed Cloud ソフトウェアにアクセスするために事前定義されたサービス アカウント。このアカウントは、GKE Enterprise を購入したときに作成します。
  • Connect が Google Distributed Cloud クラスタを Google Cloud に登録するために使用する、登録サービス アカウント。
  • Cloud Logging で使用するクラスタログを収集するための Cloud Logging サービス アカウント。

インストール中に、Identity and Access Management のロールを、これらのサービス アカウントにバインドします。これらのロールは、プロジェクト内の特定の権限をサービス アカウントに付与します。これらのロールはインストール時に生成できます。

クラスタ ユーザーの認証を構成する

クラスタ ユーザー認証を構成するには、OpenID Connect（OIDC）または Lightweight Directory Access Protocol（LDAP）を使用できます。

詳細については、GKE Identity Service をご覧ください。

Kubernetes Namespace と RBAC を使用してアクセスを制限する

Kubernetes への最小権限をチームに付与するには、Kubernetes Namespace か、環境固有のクラスタを作成します。アカウンタビリティとチャージバックに基づいて各 Namespace にコストセンターと適切なラベルを割り当てます。開発者に付与する Namespace へのアクセス権は（特に本番環境において）、アプリケーションのデプロイと管理に必要なレベルのみに制限します。

ユーザーがクラスタに対して行う必要があるタスクをマッピングし、各タスクの完了に必要な権限を定義します。クラスタレベルと Namespace レベルの権限を付与するには、Kubernetes RBAC を使用します。

Google Distributed Cloud のインストールに使用される Google Cloud サービス アカウントの権限の他に、IAM は Google Distributed Cloud クラスタに適用されません。

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

データの保護

このセクションでは、データの保護について説明します。

vSphere 仮想マシンを暗号化する

Google Distributed Cloud クラスタノードは、vSphere クラスタ内の仮想マシン（VM）で実行されます。すべてのデータを保存時に暗号化することを強くおすすめします。vSphere でこれを行うには、VMware vSphere 7 セキュリティ構成と強化ガイドと、VM の暗号化のベスト プラクティス ガイドに従ってください。

これは、GKE Enterprise のインストール前に行う必要があります。

シークレットを管理する

etcd に保存されている Kubernetes Secret などのセンシティブ データを保護するレイヤを追加するには、Google Distributed Cloud クラスタと統合された Secret Manager を構成します。

複数の環境でワークロードを実行する場合は、Google Kubernetes Engine と Google Distributed Cloud の両方で機能するソリューションを選択できます。HashiCorp Vault などの外部シークレット マネージャーを使用する場合は、Google Distributed Cloud クラスタを統合する前に設定してください。

シークレットを管理する方法はいくつかあります。

  • Kubernetes Secret は Google Distributed Cloud でネイティブに使用できます。前述のとおり、クラスタでは、VM 用の vSphere 暗号化が使用されます。これにより、シークレットは基本的な保存時の暗号化により保護されます。シークレットには、デフォルトではこれ以上の暗号化は行われません。
  • HashiCorp Vault などの、外部のシークレット マネージャーを使用できます。HashiCorp への認証には、Kubernetes サービス アカウントまたは Google Cloud サービス アカウントを使用できます。

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

ネットワーク保護

このセクションでは、ネットワークの保護について説明します。

コントロール プレーンとノードへのネットワーク アクセスの制限

クラスタ コントロール プレーンとノードのインターネットへの公開を制限します。この選択は、クラスタの作成後は変更できません。デフォルトでは、Google Distributed Cloud クラスタノードは RFC 1918 アドレスを使用して作成されます。この設定を変更しないことをおすすめします。コントロール プレーンへのアクセスを制限するために、オンプレミス ネットワークにファイアウォール ルールを実装します。

ネットワーク ポリシーを使用してトラフィックを制限する

デフォルトでは、Google Distributed Cloud クラスタ内のすべての Service が互いに通信できます。ワークロードで Service 間の通信を制御する方法については、次のセクションをご覧ください。

サービスへのネットワーク アクセスを制限することで、攻撃者によるクラスタ内移動の難易度を大幅に上げることができます。また、偶発的または意図的な DoS 攻撃に対してサービスをある程度は保護できます。トラフィックを制御する場合、次の 2 つの方法をおすすめします。

  • アプリケーションのエンドポイントへの L7 トラフィックを制御するには、Istio を使用します。負荷分散、サービス認可、スロットリング、割り当て、指標に関心をお持ちの場合はこれを選択します。
  • Pod 間の L4 トラフィックを制御するには、Kubernetes ネットワーク ポリシーを使用します。Kubernetes で管理されている基本的なアクセス制御機能を探している場合は、こちらを選択します。

Google Distributed Cloud クラスタを作成した後、Istio と Kubernetes の両方のネットワーク ポリシーを有効にできます。これらは必要に応じて併用可能です。

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

宣言型セキュリティ

このセクションでは、クラスタの保護に関する推奨事項を示します。

Policy Controller を使用する

Kubernetes アドミッション コントローラは、Kubernetes クラスタの使用方法を管理および適用するプラグインです。アドミッション コントローラは、クラスタを強化する多層防御アプローチの重要な要素です。

Policy Controller を使用することをおすすめします。Policy Controller では OPA Constraint Framework を使用して、ポリシーが CRD として記述され適用されます。クラスタに適用する制約は、クラスタにデプロイされる制約テンプレートで定義されます。

Policy Controller の制約を使用して、PodSecurityPolicies と同じ保護を行い、ポリシーの適用前にポリシーを追加できる機能については、制約を使用して Pod セキュリティを適用するをご覧ください。

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

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

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

理想的には、ワークロードには自己変更機能を付与するべきではありません。自己変更が必要な場合は、オープンソースの Gatekeeper ライブラリから NoUpdateServiceAccount などの Gatekeeper またはポリシー コントローラの制約を適用して権限を制限できます。これにより、いくつかの有用なセキュリティ ポリシーが提供されます。

ポリシーをデプロイする場合、通常はクラスタのライフサイクルを管理するコントローラがポリシー、およびパイプラインのロギングとモニタリングをバイパスできるようにする必要があります。これは、コントローラがクラスタに変更を加える（クラスタのアップグレードを適用するなど）ことができるようにするために必要です。たとえば、Google Distributed Cloud に NoUpdateServiceAccount ポリシーをデプロイする場合は、Constraint で次のパラメータを設定する必要があります。

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:serviceaccount:kube-system:monitoring-operator
  - system:serviceaccount:kube-system:stackdriver-operator
  - system:serviceaccount:kube-system:metrics-server-operator
  - system:serviceaccount:kube-system:logmon-operator

メンテナンス

このセクションでは、クラスタの維持について説明します。

GKE Enterprise をアップグレードする

Kubernetes では新しいセキュリティ機能が定期的に導入されており、セキュリティ パッチが提供されています。

Google Distributed Cloud クラスタを最新の状態に保つことは、お客様の責任で行っていただく必要があります。各リリースについて、リリースノートをご確認ください。新しいパッチリリースは毎月、マイナー バージョンのリリースは 3 か月ごとに更新する計画を立ててください。クラスタをアップグレードする方法については、こちらをご覧ください。

また、次に示す vSphere インフラストラクチャのアップグレードとセキュリティ保護についてもお客様の責任範囲です。

セキュリティに関する公開情報をモニタリングする

GKE Enterprise セキュリティ チームは、重大度が「高」や「重大」の脆弱性のセキュリティに関する情報を公開しています。

これらの情報は、共通の Google Cloud 脆弱性番号スキームに従っており、Google Cloud 情報のメインページと Google Distributed Cloud リリースノートにリンクしています。 各セキュリティに関する公開情報のページに RSS フィードがあり、ユーザーは登録すると、更新情報を受け取ることができます。

このような重大度が「高」や「重大」の脆弱性に対処するためにお客様の対応が必要な場合は、Google からメールでご連絡いたします。また、Google はサポート チャネルを通じてサポート契約を結んでいるお客様にご連絡する場合もあります。

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

モニタリングとロギング

Google Distributed Cloud には、クラウドベースのマネージド サービス、オープンソース ツール、サードパーティの商用ソリューションとの検証済みの互換性など、クラスタのロギングとモニタリングのオプションが複数あります。

  • Cloud Logging と Cloud Monitoring。Google Distributed Cloud でデプロイされたクラスタ内エージェントによって有効化されます。
  • サードパーティ ソリューションによる検証済みの構成

セキュリティ インシデント管理のため、ビジネス要件に基づいて選択したロギング ソリューションでは、関連するイベントとアラートを中央のセキュリティ情報 / イベント管理（SIEM）サービスに送信することを強くおすすめします。

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