このページでは、Google Kubernetes Engine(GKE)で顧客管理の暗号鍵(CMEK)を使用する方法について説明します。鍵の管理を制御する必要がある場合は、Cloud Key Management Service と CMEK を使用することで、GKE クラスタ内の接続された永続ディスクとカスタム ブートディスクを保護することができます。
概要
Google Cloud では、デフォルトで保存されている顧客コンテンツを暗号化し、GKE が自動的に暗号化の管理を行います。
暗号鍵のローテーションを自身で管理する場合は、CMEK を使用します。これらの鍵は、データの暗号化に使用するデータ暗号鍵を暗号化します。詳細については、鍵管理をご覧ください。また、自身で管理する鍵を使用してクラスタの Secret を暗号化することもできます。詳しくは、アプリケーション レイヤでの Secret の暗号化をご覧ください。
GKE では、CMEK を使用することによって、ノード ブートディスクとアタッチされたディスクの 2 種類のストレージ ディスクのデータを保護できます。
- ノード ブートディスク
- ノード ブートディスクは、クラスタのノードプールの一部です。クラスタとノードプールを作成するときに、CMEK で暗号化されたノード ブートディスクを作成できます。
- 接続されたディスク
- 接続されたディスクは、耐久性の高いストレージ用にポッドで使用される PersistentVolume です。CMEK で暗号化され、アタッチされた永続ディスクは、動的にプロビジョニングされる PersistentVolume として GKE で使用できます。
ストレージ ディスクの詳細については、ストレージ オプションをご覧ください。GKE コントロール プレーンに使用するコントロール プレーン ディスクは、CMEK では保護できません。
始める前に
このトピックの演習を行うには、2 つの Google Cloud プロジェクトが必要です。
鍵プロジェクト: 暗号鍵の作成先。
クラスタ プロジェクト: CMEK を有効にするクラスタの作成先。
鍵プロジェクトで、Cloud KMS API が有効になっていることを確認します。
鍵プロジェクトで、キーリングと鍵を作成するユーザーには次の IAM 権限が必要になります。
cloudkms.keyRings.getIamPolicy
cloudkms.keyRings.setIamPolicy
これらの権限は、事前定義された
roles/cloudkms.admin
Identity and Access Management ロールに付与されています。鍵を管理するための権限の付与に関する詳細については、Cloud KMS のドキュメントをご覧ください。クラスタ プロジェクトで Cloud KMS API が有効になっていることを確認します。
Cloud SDK がインストール済みであることを確認します。
gcloud
を最新バージョンに更新します。gcloud components update
Cloud KMS 鍵を作成する
CMEK でノード ブートディスクまたはアタッチされたディスクを保護する前に、Cloud KMS のキーリングと鍵が必要です。
キーリングと鍵の要件は次のとおりです。
鍵には対称暗号化を使用する必要があります。
鍵を使用するには、GKE サービス アカウントに権限を付与する必要があります。
キーリングには、GKE クラスタのロケーションと一致するロケーションが必要です。
ゾーンクラスタは、スーパーセット ロケーションからのキーリングを使用する必要があります。たとえば、ゾーン
us-central1-a
のクラスタは、リージョンus-central1
の鍵のみを使用できます。リージョン クラスタは、同じロケーションからのキーリングを使用する必要があります。たとえば、
asia-northeast1
リージョンのクラスタは、asia-northeast1
リージョンのキーリングで保護する必要があります。GKE では、Cloud KMS の
global
リージョンの使用はサポートされていません。
キーリングと鍵を作成する方法については、対称鍵の作成をご覧ください。
鍵を使用する権限を付与する
クラスタのノードで使用する Compute Engine サービス アカウントには、Cloud KMS 暗号鍵の暗号化 / 復号の役割を割り当てる必要があります。これは、GKE 永続ディスクが暗号鍵にアクセスして使用する際に必要になります。
Compute Engine サービス アカウントの名前は次の形式です。
service-project-number@compute-system.iam.gserviceaccount.com
project-number は、クラスタのプロジェクト番号に置き換えます。
サービス アカウントにアクセス権を付与するには、gcloud
コマンドまたは Google Cloud Console を使用します。
gcloud
Compute Engine サービス アカウントに、Cloud KMS 暗号鍵の暗号化 / 復号の役割を付与します。
gcloud kms keys add-iam-policy-binding key \
--location location \
--keyring key-ring \
--member serviceAccount:service-account \
--role roles/cloudkms.cryptoKeyEncrypterDecrypter \
--project key-project-id
以下を置き換えます。
- key は、鍵の名前です。
- location は、キーリングを作成したリージョンです。
- key-ring は、キーリングの名前です。
- service-account は、Compute Engine サービス アカウントの名前です。
- key-project-id は、鍵プロジェクト ID です。
Console
Compute Engine サービス アカウントに、Cloud KMS 暗号鍵の暗号化 / 復号の役割を付与します。
- Google Cloud Console で Cloud Key Management Service 鍵ブラウザを開きます。
Cloud KMS 鍵のブラウザを開く 目的の鍵を含むキーリングの名前をクリックします。
使用する鍵のチェックボックスをオンにします。
右側のウィンドウの [権限] タブが有効になります。
[メンバーの追加] ダイアログで、アクセス権を付与する Compute Engine サービス アカウントのメールアドレスを指定します。
[役割を選択] プルダウンで、[クラウド KMS 暗号鍵の暗号化 / 復号化] を選択します。
[保存] をクリックします。
CMEK で保護されたブートディスクを作成する
このセクションでは、CMEK で保護されたブートディスクが含まれる新しいクラスタまたはノードプールを作成します。
既存のクラスタまたはノードプールのブートディスクの種類は変更できないため、既存のクラスタではノード ブートディスクの顧客管理の暗号化を有効にすることはできません。ただし、クラスタ用の新しいノードプールを作成し、そこで顧客管理の暗号化を有効にし、以前のノードプールを削除することは可能です。
また、既存のクラスタまたは既存のノードプールで、ノード ブートディスク用の顧客管理の暗号化を無効にすることもできません。ただし、クラスタ用の新しいノードプールを作成し、そこで顧客管理の暗号化を無効にし、以前のノードプールを削除することは可能です。
CMEK で保護されたノード ブートディスクが含まれるクラスタを作成する
CMEK で保護されたノード ブートディスクが含まれるクラスタを作成するには、gcloud
コマンドまたは Google Cloud Console を使用します。
CMEK 鍵で暗号化できるのは、標準永続ディスク(pd-standard
)または SSD 永続ディスク(pd-ssd
)のみです。
gcloud
ブートディスクが CMEK 鍵で暗号化されたクラスタを作成するには、作成コマンドで --boot-disk-kms-key parameter
の値を指定します。
gcloud container clusters create cluster \
--cluster-version=latest \
--zone zone \
--boot-disk-kms-key projects/key-project-id/locations/location/keyRings/key-ring/cryptoKeys/key \
--project cluster-project-id\
--disk-type disk-type
以下を置き換えます。
- cluster は、クラスタに付ける名前です。
- zone は、クラスタを作成するゾーンです。
- key-project-id は、鍵プロジェクト ID です。
- location は、キーリングのロケーションです。
- key-ring は、キーリングの名前です。
- key は、鍵の名前です。
- cluster-project-id は、クラスタ プロジェクト ID です。
- disk-type は
pd-standard
(デフォルト)またはpd-ssd
です。
Console
Cloud Console の [Cloud Key Management Service] メニューに移動します。
[クラスタを作成] ボタンをクリックします。
必要に応じてクラスタを構成します。
ナビゲーション パネルで、[ノードプール] の下の [ノード] をクリックします。
[ブートディスクの種類] プルダウン リストで、[標準永続ディスク] または [SSD 永続ディスク] を選択します。
[ブートディスクの顧客管理の暗号化を有効にする] チェックボックスをオンにし、上記で作成した Cloud KMS 暗号鍵を選択します。
[作成] をクリックします。
CMEK で保護されたノード ブートディスクが含まれるクラスタを更新する
既存のクラスタで CMEK を有効にして新しいノードプールを作成するには、gcloud
コマンドまたは Google Cloud Console を使用します。
gcloud
ノード ブートディスクに対して顧客管理の暗号化が適用されるノードプールを作成するには、作成コマンドで -boot-disk-kms-key parameter
の値を指定します。
gcloud container node-pools create node-pool-name \
--zone zone \
--disk-type disk-type \
--boot-disk-kms-key projects/key-project-id/locations/location/keyRings/ring-name/cryptoKeys/<var>key-name \
--project cluster-project-id \
--cluster cluster-name
以下を置き換えます。
- node-pool-name は、ノードプールに付ける名前です。
- zone は、クラスタを作成するゾーンです。
- disk-type は
pd-standard
(デフォルト)またはpd-ssd
です。 - key-project-id は、鍵プロジェクト ID です。
- location は、キーリングのロケーションです。
- ring-name は、キーリングの名前です。
- key-name は、鍵の名前です。
- cluster-project-id は、クラスタ プロジェクト ID です。
- cluster-name は、前の手順で作成したクラスタの名前です。
Console
Cloud Console の GKE メニューに移動します。
ノードプールを追加するクラスタを選択します。
[ノードプールを追加] をクリックします。
[ブートディスクの種類] が [標準永続ディスク] または [SSD 永続ディスク] であることを確認します。
[ブートディスクの顧客管理の暗号化を有効にする] を選択し、作成した Cloud KMS 暗号鍵を選択します。
[保存] をクリックします。
CMEK で保護された、接続されたディスクを作成する
以下の手順に従い、新しく作成した永続ディスクを暗号化します。新規または既存のクラスタで、Cloud KMS の新規または既存の鍵を使用して CMEK を有効にできます。
これらの手順は、GKE クラスタごとに 1 度実行する必要があります。
- GKE クラスタを作成します(まだ存在しない場合)。
- Compute Engine 永続ディスクの CSI ドライバをクラスタにデプロイします。
- Cloud KMS のキーリングと鍵バージョンを作成します(まだない場合)。
- Kubernetes によってプロビジョニングされるディスクが Cloud KMS 鍵によって自動的に暗号化されるようにするための StorageClass を作成します。詳しい手順については、次のセクションをご覧ください。
Cloud KMS 鍵を参照する StorageClass を作成する
以下の内容を
gcepd-sc.yaml
という名前の YAML ファイルにコピーします。この構成では、暗号化されたボリュームの動的なプロビジョニングが可能です。apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: csi-gce-pd-cmek provisioner: pd.csi.storage.gke.io volumeBindingMode: "WaitForFirstConsumer" allowVolumeExpansion: true parameters: type: pd-standard disk-encryption-kms-key: projects/key-project-id/locations/location/keyRings/key-ring/cryptoKeys/key
disk-encryption-kms-key
フィールドは、新しいディスクの暗号化に使用する鍵の完全修飾リソース識別子である必要があります。disk-encryption-kms-key
の値では大文字と小文字が区別されます(例:keyRings
とcryptoKeys
)。新しいボリュームを不正な値でプロビジョニングすると、invalidResourceUsage
エラーが発生します。- デフォルトの StorageClass を設定できます。
disk-encryption-kms-key
パラメータを既存の StorageClass に追加することはできません。ただし、既存の StorageClass を削除し、同じ名前で別のパラメータ セットを含む StorageClass を作成することは可能です。その場合は、既存のクラスのプロビジョナーがpd.csi.storage.gke.io
であることを確認してください。kubectl
を使用して、GKE クラスタにStorageClass
をデプロイします。kubectl apply -f gcepd-sc.yaml
StorageClass
が Compute Engine Persistent Disk CSI ドライバを使用し、キーの ID が含まれていることを確認します。kubectl describe storageclass csi-gce-pd-cmek
コマンドの出力で、次のことを確認します。
- プロビジョナーが
pd.csi.storage.gke.io
に設定されている。 - 鍵の ID が
disk-encryption-kms-key
の形式になっている。
Name: csi-gce-pd-cmek IsDefaultClass: No Annotations: None Provisioner: pd.csi.storage.gke.io Parameters: disk-encryption-kms-key=projects/key-project-id/locations/location/keyRings/ring-name/cryptoKeys/key-name,type=pd-standard AllowVolumeExpansion: unset MountOptions: none ReclaimPolicy: Delete VolumeBindingMode: WaitForFirstConsumer Events: none
- プロビジョナーが
GKE で暗号化された永続ディスクを作成する
このセクションでは、新しい StorageClass
と Cloud KMS 鍵によって暗号化された Kubernetes ストレージ ボリュームを動的にプロビジョニングします。
次の内容を
pvc.yaml
という名前の新しいファイルにコピーし、storageClassName
の値がStorageClass
オブジェクトの名前と一致していることを確認します。kind: PersistentVolumeClaim apiVersion: v1 metadata: name: podpvc spec: accessModes: - ReadWriteOnce storageClassName: csi-gce-pd-cmek resources: requests: storage: 6Gi
GKE クラスタに
PersistentVolumeClaim
(PVC)を適用します。kubectl apply -f pvc.yaml
クラスタの
PersistentVolumeClaim
のステータスを取得して、PVC が作成されていて、新しくプロビジョニングされたPersistentVolume
にバインドされていることを確認します。kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE podpvc Bound pvc-e36abf50-84f3-11e8-8538-42010a800002 10Gi RWO csi-gce-pd-cmek 9s
これで、CMEK で保護された永続ディスクが GKE クラスタで使用できるようになります。
永続ディスクでの CMEK による保護を終了する
永続ディスクで CMEK による保護を終了するには、Compute Engine のドキュメントの指示に従います。
次のステップ
- Cloud Key Management Service に関するよくある質問をご覧ください。
- Cloud KMS 鍵によるリソースの保護の詳細をご覧ください。