このページでは、VMware 用 Google Distributed Cloud（ソフトウェアのみ）のインフラストラクチャの各レイヤに含まれるセキュリティ機能と、ニーズに合わせてセキュリティ機能を構成する方法について説明します。
概要
VMware 用 Google Distributed Cloud（ソフトウェアのみ）には、コンテナ イメージのコンテンツ、コンテナ ランタイム、クラスタ ネットワーク、クラスタ API サーバーへのアクセスなどのワークロードを保護する機能がいくつかあります。
クラスタとワークロードの保護には、階層的なアプローチをおすすめします。ユーザーとワークロードに付与するアクセスレベルに対して最小権限の原則を適用できます。柔軟性とセキュリティの適切なレベルについてトレードオフを見極める必要があります。
認証と認可
OpenID Connect（OIDC）または Cloud コンソール 経由で Kubernetes サービス アカウント トークンを使用して、クラスタに対して認証を行います。
クラスタレベルまたは Kubernetes Namespace 内の Kubernetes リソースへのアクセス権限を詳細に構成するには、Kubernetes のロールベース アクセス制御（RBAC）を使用します。RBAC では、ユーザーとサービス アカウントにアクセスを許可するオペレーションとリソースを定義する詳細なポリシーを作成できます。RBAC では、指定された任意の検証済み ID に対するアクセスを制御できます。
Kubernetes Engine の認証と認可の戦略をさらに簡素化、合理化するには、Google Distributed Cloud で、以前の属性ベースのアクセス制御（ABAC）を無効にします。
コントロール プレーンのセキュリティ
コントロール プレーン コンポーネントには、Kubernetes API サーバー、スケジューラ、コントローラ、Kubernetes 構成が永続化される etcd データベースが含まれます。GKE では、Kubernetes コントロール プレーン コンポーネントの管理と保守は Google によって行われますが、Google Distributed Cloud のコントロール プレーン コンポーネントはローカル管理者が管理します。
Google Distributed Cloud では、コントロール プレーン コンポーネントは企業ネットワーク内で実行されます。既存の企業ネットワーク ポリシーとファイアウォールを使用して、Kubernetes API サーバーを保護できます。内部 IP アドレスを API サーバーに割り当てて、このアドレスへのアクセスを制限することもできます。
Google Distributed Cloud での通信はすべて TLS チャネルを介して行われます。TLS チャネルは、etcd、cluster、org の 3 つの認証局（CA）によって管理されます。
- etcd CA は、API サーバーから etcd レプリカへの通信と、etcd レプリカ間のトラフィックを保護します。この CA は自己署名です。
- クラスタ CA は、API サーバーとすべての内部 Kubernetes API クライアント（kubelet、コントローラ、スケジューラ）間の通信を保護します。この CA は自己署名です。
- org CA は、Kubernetes API を外部ユーザーに提供するために使用される外部 CA です。この CA はユーザーが管理します。
管理コントロール プレーンの場合、鍵はコントロール プレーンのノードに保存されます。ユーザー クラスタの場合、鍵は管理コントロール プレーンに Kubernetes Secret として保存されます。API サーバーは、org CA によって署名されたユーザー指定の証明書で構成されます。API サーバーは、Server Name Indication（SNI）を使用して、クラスタ CA によって署名された鍵、または org CA によって署名された鍵のいずれを使用するかを決定します。
クラスタ認証は、証明書とサービス アカウント署名なしトークンによって処理されます。管理者は、OIDC、または管理者証明書（初期ロール バインディングの作成や緊急時に使用）を使用してコントロール プレーンに対して認証します。
証明書のローテーションは次のように行われます。
- API サーバー、コントロール プレーン、ノードの場合、アップグレードごとに証明書が作成またはローテーションされます。
- CA はほとんどローテーションされない、またはオンデマンドでローテーションされる場合があります。
ノードのセキュリティ
Google Distributed Cloud は、クラスタにノードとして接続されている VMware インスタンスにワークロードをデプロイします。以降のセクションでは、使用可能なノードレベルのセキュリティ機能の使用方法について説明します。
Ubuntu
Google Distributed Cloud は、Kubernetes コントロール プレーンとノードを実行するオペレーティング システムとして、最適化されたバージョンの Ubuntu を使用します。Ubuntu には最新のセキュリティ機能が豊富に用意されており、Google Distributed Cloud では次のようなセキュリティ強化機能が実装されています。
- イメージは、PCI DSS、NIST ベースライン ハイ、DoD クラウド コンピューティングの SRG Impact Level 2 の基準を満たすように事前構成されています。
- 最適化されたパッケージのセット。
- Google Cloud 向けにカスタマイズされた Linux カーネル。
- OS の自動セキュリティ更新（省略可）。
- 制限付きユーザー アカウントと root ログインの無効化。
Ubuntu には、次のような別のセキュリティ ガイドも用意されています。
ノードのアップグレード
ノードは定期的にアップグレードする必要があります。コンテナのランタイム、Kubernetes 自体、ノードのオペレーティング システムのセキュリティに問題が発生すると、ノードの緊急アップグレードが必要となる場合があります。クラスタをアップグレードすると、各ノードのソフトウェアが最新バージョンにアップグレードされます。
ワークロードの保護
Kubernetes では、コンテナベースのワークロードのプロビジョニング、スケーリング、更新を迅速に行うことができます。このセクションでは、実行中のコンテナがクラスタ内の他のコンテナ、実行中のホスト、プロジェクトで有効な Google Cloud サービスに影響を与えてしまう能力について、管理者とユーザーがそれを制限する際に利用できる方法について説明します。
Pod コンテナのプロセス権限を制限する
コンテナ化されたプロセスの権限を制限することは、クラスタの全体的なセキュリティにとって重要です。Kubernetes Engine では、Pod とコンテナの両方でセキュリティ コンテキストを使用してセキュリティ関連のオプションを設定できます。これらの設定により、次のようなプロセスのセキュリティ設定を変更できます。
- 実行するユーザーとグループ
- 利用可能な Linux 機能
- 権限昇格
デフォルトのノードのオペレーティング システムである Ubuntu は、Kubernetes が起動したすべてのコンテナにデフォルトの Docker AppArmor セキュリティ ポリシーを適用します。プロファイルのテンプレートは GitHub で確認できます。特に、このプロファイルではコンテナに対する以下の機能が拒否されます。
- プロセス ID ディレクトリ（/proc/）内のファイルに直接書き込むこと。
- /proc/ に存在しないファイルへの書き込み。
- /proc/sys 内の /proc/sys/kernel/shm* 以外のファイルへの書き込み。
- ファイル システムをマウントする
監査ロギング
Kubernetes 監査ロギングを使用すると、管理者が Google Distributed Cloud 環境で発生したイベントの保持、クエリ、処理、アラート生成を行うことができます。管理者はログに記録された情報を使用して、フォレンジック分析、リアルタイム アラート、Kubernetes Engine クラスタの使用状況とユーザーのカタログを作成できます。
デフォルトでは、Google Distributed Cloud は管理アクティビティをログに記録します。また、検査対象のオペレーションの種類によってはデータアクセス イベントを記録することもできます。
Connect Agent は、オンプレミスで実行されるローカル API サーバーとのみ通信し、各クラスタには独自の監査ログのセットが必要です。ユーザーが UI から実行するすべてのアクションは、そのクラスタによってログに記録されます。
暗号化
クラスタとワークロードが Cloud VPN 経由で Google Cloud サービスに安全に接続されている場合は、Cloud Key Management Service（Cloud KMS）を使用して鍵を管理できます。Cloud KMS は、サービスの暗号鍵を管理するクラウドホスト型鍵管理サービスです。AES256、RSA 2048、RSA 3072、RSA 4096、EC P256、EC P384 の各規格に対応し、暗号鍵の生成、使用、ローテーション、破棄をサポートしています。Cloud KMS は Identity and Access Management（IAM）および Cloud Audit Logging と統合されているため、個別鍵の権限を管理し、使用状況をモニタリングできます。Cloud KMS を使用して、Secret や保存する必要がある他の機密データを保護します。それ以外の場合は、次の代替方法のいずれかを選択します。
- Kubernetes Secret
- HashiCorp Vault
- Thales Luna ネットワーク HSM
- Google Cloud ハードウェア セキュリティ モジュール（HSM）
Kubernetes Secret
Kubernetes の Secret リソースは、パスワード、OAuth トークン、SSH 認証鍵などの機密性の高いデータをクラスタに格納します。Secret への機密データの保存は、平文の ConfigMaps や Pod 仕様への保存よりも安全です。Secret を使用すると、機密データの使用方法を制御し、権限のないユーザーにデータが公開されるリスクを軽減できます。