セキュリティ

このページでは、Anthos GKE On-Prem のインフラストラクチャの各レイヤに含まれるセキュリティ機能と、ニーズに合わせてセキュリティ機能を構成する方法について説明します。

概要

GKE On-Prem は、コンテナ イメージ、コンテナ ランタイム、クラスタ ネットワーク、クラスタ API サーバーへのアクセスなどのワークロードを保護するための機能を提供します。

クラスタとワークロードの保護には、階層的なアプローチをおすすめします。 最小権限の原則を、ユーザーとワークロードに与えるアクセスレベルに適用できます。柔軟性とセキュリティの適切なレベルについてトレードオフを見極める必要があります。

認証と承認

OpenID Connect(OIDC)または Cloud Console 経由で Kubernetes サービス アカウント トークンを使用して、GKE On-Prem のクラスタに対して認証を行います。

クラスタレベルや Kubernetes 名前空間内で Kubernetes リソースへのアクセス権限を詳細に構成するには、Kubernetes のロールベースのアクセス制御(RBAC)を使用します。RBAC では、ユーザーとサービス アカウントにアクセスを許可するオペレーションとリソースを定義する詳細なポリシーを作成できます。RBAC では、提供された任意の検証済み ID に対するアクセスを制御できます。

Kubernetes Engine の認証と承認の戦略をさらに簡素化、合理化するには、GKE On-Prem で、以前の属性ベースのアクセス制御(ABAC)を無効にします。

詳細については、本番環境での Kubernetes Engine の準備をご覧ください。

コントロール プレーンのセキュリティ

コントロール プレーン コンポーネントには、Kubernetes API サーバー、スケジューラ、コントローラ、Kubernetes 構成が永続化される etcd データベースが含まれます。Kubernetes Engine において、Kubernetes のコントロール プレーン コンポーネントは Google によって管理と保守が行われますが、GKE On-Prem のコントロール プレーン コンポーネントはローカルの管理者が管理します。

GKE On-Prem では、コントロール プレーン コンポーネントは企業ネットワーク内で実行されます。既存の企業ネットワーク ポリシーとファイアウォールを使用して、GKE On-Prem の API サーバーを保護できます。プライベート IP アドレスを API サーバーに割り当てて、プライベート アドレスへのアクセスを制限することもできます。

GKE On-Prem の通信はすべて、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 によって署名された鍵を使用します。

GKE On-Prem のクラスタ認証は、証明書とサービス アカウント署名なしトークンによって処理されます。管理者は、OIDC、または管理者証明書(初期ロール バインディングの作成や緊急時に使用)を使用してコントロール プレーンに対して認証します。

証明書のローテーションは次のように行われます。

  • API サーバー、コントロール プレーン、ノードの場合、アップグレードごとに証明書が作成またはローテーションされます。
  • CA はほとんどローテーションされず、オンデマンドでローテーションされる場合があります。

ノードのセキュリティ

GKE On-Prem は、クラスタにノードとして接続されている VMware インスタンスにワークロードをデプロイします。続くセクションでは、GKE On-Prem で利用可能なノードレベルのセキュリティ機能を活用する方法を説明します。

Ubuntu

GKE On-Prem は、Kubernetes コントロール プレーンとノードを実行するオペレーティング システムとして、最適化されたバージョンの Ubuntu を使用します。Ubuntu には最新のセキュリティ機能が豊富に用意されており、GKE On-Prem では次のようなセキュリティ強化機能が実装されています。

Ubuntu には、次のような別のセキュリティ ガイドも用意されています。

ノードのアップグレード

ノードは定期的にアップグレードする必要があります。コンテナのランタイム、Kubernetes 自体、ノードのオペレーティング システムのセキュリティに問題が発生すると、ノードの緊急アップグレードが必要となる場合があります。クラスタをアップグレードすると、各ノードのソフトウェアは最新バージョンにアップグレードされます。

ワークロードの保護

Kubernetes では、コンテナベースのワークロードのプロビジョニング、スケーリング、更新を迅速に行うことができます。このセクションでは、管理者とユーザーが実行中のコンテナの能力を制限して、クラスタ内の他のコンテナ、実行中のホスト、プロジェクトで有効になっている GCP サービスを制御する方法について説明します。

ポッドコンテナのプロセス権限を制限する

コンテナ化されたプロセスの権限を制限することは、クラスタの全体的なセキュリティにとって重要です。Kubernetes Engine では、Pod とコンテナの両方でセキュリティ コンテキストを使用してセキュリティ関連のオプションを設定できます。これらの設定により、次のようなプロセスのセキュリティ設定を変更できます。

  • 実行するユーザーとグループ
  • 利用可能な Linux 機能
  • 権限昇格

デフォルトの GKE On-Prem ノードのオペレーティング システムである Ubuntu は、Kubernetes が起動したすべてのコンテナにデフォルトの Docker AppArmor セキュリティ ポリシーを適用します。プロファイルのテンプレートは GitHub で確認できます。特に、次のプロファイルではコンテナに対する次の機能が拒否されます。

  • プロセス ID ディレクトリ(/proc/)内のファイルに直接書き込むこと。
  • /proc/ にないファイルへの書き込み。
  • /proc/sys 内の /proc/sys/kernel/shm* 以外のファイルへの書き込み。
  • ファイル システムをマウントする

監査ログ

Kubernetes Audit logging は、管理者が GKE On-Prem 環境で発生したイベントの保持、クエリ、処理、アラート生成を行う手段を提供します。管理者はログに記録された情報を使用して、フォレンジック分析、リアルタイム アラート、Kubernetes Engine クラスタの使用状況とユーザーのカタログを作成できます。

デフォルトでは、GKE On-Prem は管理アクティビティをログに記録します。また、検査対象のオペレーションの種類によってはデータアクセス イベントを記録することもできます。

Connect Agent は、オンプレミスで実行されるローカル API サーバーとのみ通信し、各クラスタには独自の監査ログのセットが必要です。ユーザーが UI から実行するすべてのアクションは、そのクラスタによってログに記録されます。

暗号化

Cloud Key Management Service(Cloud KMS)はクラウドでホストされる鍵管理サービスです。このサービスを利用することで、サービスの暗号鍵を管理できます。AES256、RSA 2048、RSA 3072、RSA 4096、EC P256、EC P384 の各規格に対応し、暗号鍵の生成、使用、ローテーション、破棄をサポートしています。Cloud KMS は Cloud Identity and Access Management(Cloud IAM)Cloud Audit Logging に統合されているため、個別鍵の権限を管理し、使用状況をモニタリングできます。Cloud KMS を使用して、Secret や保存する必要がある他の機密データを保護します。

GKE On-Prem クラスタとワークロードが Cloud VPN 経由で Google Cloud サービスに安全に接続されている場合は、Cloud KMS を鍵管理に使用できます。そうでない場合は、次のいずれかの方法を使用できます。

  • Kubernetes Secret
  • HashiCorp Vault
  • ハードウェア セキュリティ モジュール(HSM)

Kubernetes Secret

Kubernetes の Secret リソースは、パスワード、OAuth トークン、SSH 認証鍵などの機密性の高いデータをクラスタに格納します。Secret への機密データの保存は、平文の ConfigMaps や Pod 仕様への保存よりも安全です。Secret を使用すると、機密性の高いデータの使用方法を制御できるようになり、権限のないユーザーにデータが公開されるリスクを軽減できます。

HashiCorp Vault

ハードウェア セキュリティ モジュール