Kubernetes の開発ペースは速く、新たなセキュリティ機能がしばしば登場します。このページでは、GKE On-Prem クラスタを強化するための最新ガイダンスを実践する方法について説明します。
このガイドでは、クラスタの作成時にお客様の操作が必要となる価値のあるセキュリティ対策を優先します。重要性の低い機能、デフォルトでセキュアな設定、クラスタ作成後に有効にできる項目についてはドキュメントの後半で説明します。セキュリティの一般的な概要については、セキュリティをご覧ください。
vSphere VM の暗号化
GKE On-Prem クラスタノードは、vSphere クラスタ内の仮想マシン（VM）で実行されます。VMware vSphere のセキュリティ ガイダンスと VM の暗号化に関するベスト プラクティス ガイドに従ってください。
インフラストラクチャを適切なタイミングでアップグレードする
Kubernetes では新しいセキュリティ機能が頻繁に導入されており、セキュリティ パッチが提供されています。セキュリティ パッチの詳細については、GKE On-Prem のセキュリティに関する情報をご覧ください。
GKE On-Prem クラスタを最新の状態に保つことは、お客様の責任範囲です。リリースごとにリリースノートを確認し、新しいパッチリリースは毎月、マイナー バージョンのリリースは 3 か月ごとに更新する計画を立ててください。クラスタをアップグレードする方法については、こちらをご覧ください。
また、次に示す vSphere インフラストラクチャのアップグレードとセキュリティ保護についてもお客様の責任の範囲です。
- 仮想マシンのパッチ適用とアップグレードを行うプロセスを確立する。
- 最新の VMware セキュリティ アドバイザリの内容を反映させる。
- ホストへのパッチの適用のガイダンスに従う。
OpenID Connect を構成する
クラスタのユーザー認証を構成する場合は、OpenID Connect（OIDC）を使用します。
また、ロールベースのアクセス制御（RBAC）でアクセス権を付与する場合は、OIDC グループを利用する必要もあります。これにより、ユーザーがロールを変更したときに RBAC 構成を手動で更新する必要がなくなります。
Google Cloud サービス アカウントの最小権限の原則を使用する
GKE On-Prem には次に示す 4 つの Google Cloud サービス アカウントが必要です。
- GKE On-Prem ソフトウェアにアクセスするため、ホワイトリストに登録されたサービス アカウント。このアカウントは、Anthos を購入したときに作成します。
- Connect が GKE On-Prem クラスタを Google Cloud に登録するために使用する、登録サービス アカウント。
- Connect が GKE On-Prem クラスタと Google Cloud 間の接続を確立するために使用する、接続サービス アカウント。
- Cloud Logging で使用するクラスタログを収集するための Cloud Logging サービス アカウント。
インストール中に、Identity and Access Management のロールを、これらのサービス アカウントにバインドします。これらのロールは、プロジェクト内の特定の権限をサービス アカウントに付与します。こうしたサービス アカウントは、最小権限の原則を使用して構成する必要があります。サービス アカウントには、それぞれのロールを実行するために必要な権限のみを付与します。
Kubernetes Namespace と RBAC を使用してアクセスを制限する
Kubernetes への最小権限をチームに付与するには、Kubernetes Namespace か、環境固有のクラスタを作成します。アカウンタビリティとチャージバックに基づいて各 Namespace にコストセンターと適切なラベルを割り当てます。デベロッパーに付与する Namespace へのアクセス権は（特に本番環境において）、アプリケーションのデプロイと管理に必要なレベルのみに制限します。
ユーザーがクラスタに対して行う必要があるタスクをマッピングし、各タスクの実行に必要な権限を定義します。クラスタレベルと名前空間レベルの権限を付与するには、Kubernetes RBAC を使用します。
GKE On-Prem のインストールに使用される Google Cloud サービス アカウントの権限の他に、IAM は GKE On-Prem クラスタには適用されません。
クラスタ ディスカバリの RBAC 権限を制限する
Kubernetes はデフォルトで、CustomResourceDefinitions（CRDs） の API など、クラスタの API に関する情報に幅広くアクセスできる、制約の緩いディスカバリ ClusterRoleBindings のセットでクラスタを起動します。これらの権限は、Kubernetes 1.14 で縮小され、GKE On-Prem バージョン 1.2 から使用できます。アクセスを制限する必要がある場合は、オンプレミス ファイアウォールを適切に構成することを検討してください。
シークレット管理
etcd に保存されている Kubernetes Secrets などのセンシティブ データを保護するレイヤを追加するには、GKE On-Prem クラスタと統合された Secret マネージャーを構成します。
複数の環境でワークロードを実行する場合は、Google Kubernetes Engine と GKE On-Prem の両方で機能するソリューションを選択できます。HashiCorp Vault などの外部 Secret マネージャーを使用する場合は、GKE On-Prem クラスタを作成する前にセットアップする必要があります。
シークレットを管理する方法はいくつかあります。
- GKE On-Prem では、Kubernetes Secret をネイティブで使用できます。前述のとおり、クラスタでは、VM 用の vSphere 暗号化が使用されます。これにより、Secret は基本的な保存時の暗号化により保護されます。Secret には、デフォルトではこれ以上の暗号化は行われません。アプリケーション レイヤで Secret を暗号化する場合は、EncryptionConfig を編集し、鍵管理サービス プラグインを使用できます。
- HashiCorp Vault などの、外部の Secret マネージャーを使用できます。HashiCorp への認証には、Kubernetes サービス アカウントまたは Google Cloud サービス アカウントを使用できます。
コントロール プレーンとノードへのネットワーク アクセスを制限する
クラスタ コントロール プレーンとノードのインターネットへの公開を制限する必要があります。この選択は、クラスタの作成後は変更できません。
デフォルトでは、GKE On-Prem クラスタノードは RFC 1918 のアドレスを使用して作成されます。これは変更しないでください。オンプレミス ネットワークにファイアウォール ルールを実装して、コントロール プレーンへのアクセスを制限する必要があります。
ネットワーク ポリシーを使用して Pod 間のトラフィックを制限する
デフォルトでは、GKE On-Prem クラスタ内のすべての Service が互いに通信できます。ワークロードに対しては必要に応じて、Service 間通信を制御します。
Service へのネットワーク アクセスを制限することで、攻撃者によるクラスタ内移動の難易度を大幅に引き上げることができ、偶発的または意図的なサービス拒否攻撃に対して Service をある程度は保護できます。トラフィックを制御する 2 つの推奨方法は次のとおりです。
- アプリケーションのエンドポイントへの L7 トラフィックを制御するには、Istio を使用します。負荷分散、サービス認可、スロットリング、割り当て、指標に関心をお持ちの場合はこれを選択します。
- Pod 間の L4 トラフィックを制御するには、Kubernetes ネットワーク ポリシーを使用します。Kubernetes で公開されている基本的なアクセス制御機能をお探しの場合は、これを選択します。
GKE On-Prem クラスタを作成した後、Istio と Kubernetes の両方のネットワーク ポリシーを有効にできます。これらは必要に応じて併用可能です。
Anthos Config Management の Policy Controller を使用する
Kubernetes アドミッション コントローラは、Kubernetes クラスタの使用方法を管理および適用するプラグインです。Kubernetes の高度なセキュリティ機能を使用するには、アドミッション コントローラを有効にする必要があります。アドミッション コントローラは、クラスタを強化する多層防御アプローチの重要な要素です。
Anthos Config Management の Policy Controller を使用することをおすすめします。Policy Controller では OPA Constraint Framework を使用して、ポリシーが CRD として記述され適用されます。クラスタに適用する制約は、クラスタにデプロイされる制約テンプレートで定義されます。
クラスタ構成をモニタリングする
クラスタ構成と定義した設定に矛盾がないか監査してください。これらの構成を自動的に確認するには、デプロイされた場所に関係なく、GKE On-Prem クラスタと連携するソリューションを使用する必要があります。Anthos パートナーをご覧ください。
以前のクライアント認証方式を無効のままにする（デフォルト）
Kubernetes API サーバーに対する認証方法は、複数存在します。OIDC がおすすめの認証メカニズムです。デフォルトでは、基本認証は無効になっています。x509 証明書は認証に使用しないでください。
Cloud Logging を有効のままにする（デフォルト）
運用上のオーバーヘッドを削減し、ログの統合ビューを維持するには、クラスタがデプロイされているすべての場所に一貫性のあるロギング方法を実装します。GKE On-Prem は、デフォルトで Google Cloud のオペレーション スイートに統合されています。GKE On-Prem 構成ファイルに stackdriver 仕様を入力して、インストール中に Google Cloud のオペレーション スイートを有効にする必要があります。
すべての GKE On-Prem クラスタで、Kubernetes 監査ロギングがデフォルトで有効になっています。監査ロギングにより、Kubernetes API サーバーに対して行われた呼び出しが時系列でログに記録されます。監査ログのエントリは、不審な API リクエストの調査、統計情報の収集、不要な API 呼び出しに対するモニタリング アラートを作成するうえで有用です。
GKE On-Prem クラスタは、Kubernetes 監査ロギングと Google Cloud Audit Logs および Cloud Logging を統合します。GKE On-Prem では、独自のロギング システムに ロギングからルーティングすることもできます。
Google Cloud のオペレーション スイートにより、クラスタのログが収集、集約されます。Google Cloud のオペレーション スイートを有効にすると、Google からより効果的なサポートを得ることができます。詳細については、ロギングとモニタリングをご覧ください。
Kubernetes ダッシュボードを無効のままにする（デフォルト）
Kubernetes ダッシュボードは高い権限が付与された Kubernetes サービス アカウントによりサポートされており、Kubernetes に対する複数のハイプロファイル攻撃で悪用されています。Google Cloud Console が、GKE On-Prem 向けの推奨ウェブ インターフェースです。このインターフェースは同じ機能の大部分を備え、権限を昇格せずに IAM と Kubernetes RBAC をサポートし、マルチクラスタ管理などの Anthos 機能を提供します。
Kubernetes Dashboard は GKE On-Prem には含まれていません。
属性ベースのアクセス制御を無効のままにする（デフォルト）
Kubernetes では、RBAC を使用してリソースに対する権限をクラスタレベルと名前空間レベルで付与します。RBAC では、一連の権限を含むルールを使用してロールを定義できます。
デフォルトでは、属性ベースのアクセス制御（ABAC）は GKE On-Prem クラスタで無効になっているため、有効にしないでください。