Backup for GKE の CMEK 暗号化について

このページでは、Backup for GKE における顧客管理の暗号鍵（CMEK）のサポートについて説明します。

概要

Backup for GKE を介して生成され、保存されるユーザーデータのアーティファクトには、次の 2 種類があります。

  • 構成のバックアップ: クラスタの状態をキャプチャして、バックアップを実行するクラスタの API サーバーから抽出された一連の Kubernetes リソースの説明。
  • ボリュームのバックアップ: 構成のバックアップにある PersistentVolumeClaim リソースに対応するボリュームのバックアップのセット。

デフォルトでは、Backup for GKE によって生成されたすべてのバックアップ アーティファクトは、Google 提供の鍵を使用して保存時に暗号化されます。

ただし、これらのアーティファクトは、Cloud Key Management Service を介して管理される顧客管理の暗号鍵（CMEK）を使用して暗号化することもできます。

CMEK 暗号化を有効にする

CMEK 暗号化を有効にするには、2 つの手順を行います。

  • BackupPlan 用に生成されたバックアップを暗号化する鍵を指定します。

  • 適切なサービス アカウントで適切な鍵へのアクセスを許可します。

特定のバックアップ シナリオでは、次の 3 つの CMEK 鍵が関係する可能性があります。

  • bplan_key: BackupPlan を作成または更新するときに参照する鍵です。可能な場合は、すべてのバックアップ アーティファクトを暗号化する際に使用されます。この鍵は、BackupPlan 自体と同じリージョンに存在する必要があります（リソースのロケーションについてをご覧ください）。

  • orig_disk_key: CMEK 鍵を使用して永続ディスク ボリュームを暗号化した場合、これらのボリュームに対して Backup for GKE が生成するボリューム バックアップは、別の鍵が BackupPlan に登録されていても、この鍵で暗号化されます。

  • new_disk_key: バックアップから復元したボリュームの暗号化に使用する CMEK 鍵です。これは、復元のターゲット クラスタの StorageClass から参照されます。

次に挙げる 5 つのサービス アカウントが、CMEK 鍵へのアクセスを必要とする可能性があります。

  • agent_wi: プレビュー版のエージェントを実行している場合（GKE クラスタがバージョン 1.23 以前を実行）は、このサービス アカウントに bplan_key へのアクセス権を付与する必要があります。このサービス アカウントの形式は、PROJECT_ID.svc.id.goog[gkebackup/agent] です。ここで、PROJECT_ID は Google Cloud プロジェクトの ID です。

  • agent_robot: GKE クラスタがバージョン 1.24 以降を実行している場合は、このサービス アカウントに bplan_key へのアクセス権を付与する必要があります。このサービス アカウントの形式は、service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com です。ここで、PROJECT_NUMBER は Google Cloud プロジェクトの番号です。

  • non_cmek_service_agent: CMEK 暗号化されていないボリュームをバックアップする場合は、このサービス アカウントに bplan_key へのアクセス権を付与する必要があります。このサービス アカウントの形式は、service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com です。ここで、PROJECT_NUMBER は Google Cloud プロジェクトの番号です。

  • cmek_service_agent: CMEK 暗号化ボリュームをバックアップする場合は、このサービス アカウントに orig_disk_key へのアクセス権を付与する必要があります。このサービス アカウントの形式は、service-TENANT_PROJECT_NUMBER@compute-system.iam.gserviceaccount.com です。ここで、TENANT_PROJECT_NUMBER は BackupPlan に割り当てられたテナント プロジェクトの番号です。

  • compute_service_agent: このサービス アカウントは、クラスタ用に、暗号化された新しいボリュームを作成するときに使用され、new_disk_key へのアクセス権を付与する必要があります。このサービス アカウントの形式は、service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com です。ここで、PROJECT_NUMBER は Google Cloud プロジェクトの番号です。

ディスクに diskEncryptionKey.kmsKeyServiceAccount が設定されている場合は、バックアップを作成する前に次の操作を行う必要があります。

  • 組織のポリシー iam.disableCrossProjectServiceAccountUsage を無効にして、プロジェクト間でのサービス アカウントの権限借用を有効にします。

      gcloud resource-manager org-policies disable-enforce \
      iam.disableCrossProjectServiceAccountUsage
      --project=PROJECT_ID

  • 有効期間の短い認証情報を作成するために、cmek_service_agent に roles/iam.serviceAccountTokenCreator ロールを付与します。

      gcloud iam service-accounts add-iam-policy-binding \
    # Replace the email with the value from
    # `diskEncryptionKey.kmsKeyServiceAccount`
    your-kms-key-service-acount@PROJECT_ID.iam.gserviceaccount.com \
    --member=service-TENANT_PROJECT_NUMBER@compute-system.iam.gserviceaccount.com \
    --role=roles/iam.serviceAccountTokenCreator

次の表では、さまざまなシナリオにおいて、どのサービス アカウントにどの鍵へのアクセス権を付与する必要があるかを示します。

アーティファクト サービス アカウント キー
構成ファイルのバックアップ、1.23 以前のクラスタ agent_wi bplan_key
構成ファイルのバックアップ、1.24 以降のクラスタ agent_robot bplan_key
CMEK 暗号化ボリュームのバックアップ cmek_service_agent orig_disk_key
Google 暗号化ボリュームのバックアップ non_cmek_service_agent bplan_key
復元中に作成された新しい CMEK 暗号化ボリューム compute_service_agent new_disk_key

鍵へのアクセス権は、プロジェクト レベルで付与する（そのプロジェクトの下にあるすべての鍵へのアクセス権を付与）か、個別に鍵へのアクセス権を付与するかを選択できます。

例: プロジェクト レベルのアクセス権を付与する

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com \
    --role roles/cloudkms.cryptoKeyEncrypterDecrypter

例: 鍵レベルのアクセス権を付与する

gcloud kms keys add-iam-policy-binding key \
    --keyring key-ring \
    --location location \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[gkebackup/agent]" \
    --role roles/cloudkms.cryptoKeyEncrypterDecrypter

使用上の検討事項と制限事項

  • CMEK 暗号化ボリュームをバックアップするには、BackupPlan で CMEK 暗号化を有効にしない場合でも、そのディスクの鍵へのアクセス権を付与する必要があります。

  • CMEK 鍵は BackupPlan と同じリージョンに存在する必要があります。これは、リージョンが停止しても鍵へのアクセス権は解除されず、バックアップには引き続きアクセスできるようにするためです。ただし、この制約は、暗号化ボリュームと共有される鍵には適用できません。暗号化ボリュームが関わる場合は、ディスク暗号鍵がバックアップと同じリージョンに保存されていない可能性があるため、バックアップが使用可能な場合でも復元に失敗する可能性があります。