Backup for GKE CMEK 암호화 정보


이 페이지에서는 Backup for GKE에서 고객 관리 암호화 키(CMEK) 지원이 작동하는 방식을 설명합니다.

개요

Backup for GKE로 생성되고 저장되는 사용자 데이터 아티팩트에는 두 가지 유형이 있습니다.

  • 구성 백업: 백업을 진행 중인 클러스터의 API 서버에서 추출한 Kubernetes 리소스 설명 집합이며, 클러스터 상태를 캡처합니다.
  • 볼륨 백업: 구성 백업에 있는 PersistentVolumeClaim 리소스에 해당하는 볼륨 백업 집합입니다.

기본적으로 Backup for GKE로 생성된 모든 백업 아티팩트는 Google 제공 키를 사용하여 저장 상태에서 암호화됩니다.

하지만 Cloud Key Management Service로 관리되는 고객 관리 암호화 키(CMEK)를 사용하여 아티팩트를 암호화하도록 선택할 수 있습니다.

CMEK 암호화 사용 설정

CMEK 암호화를 사용 설정하려면 다음 두 단계를 수행해야 합니다.

  • BackupPlan에 대해 생성된 백업을 암호화하기 위한 키를 지정합니다.

  • 적절한 서비스 계정에서 적절한 키에 대한 액세스 권한을 부여합니다.

특정 백업 시나리오에서 3개의 CMEK 키가 관련될 수 있습니다.

  • bplan_key: 이는 BackupPlan을 만들거나 업데이트할 때 참조하는 키입니다. 가능한 경우 모든 백업 아티팩트를 암호화할 때 이 키가 사용됩니다. 이 키는 BackupPlan 자체와 동일한 리전에 있어야 합니다(리소스 위치 정보 참조).

  • orig_disk_key: CMEK 키를 사용하여 영구 디스크 볼륨을 암호화한 경우 BackupPlan에 서로 다른 키가 등록 되더라도 해당 볼륨에 대해 Backup for GKE가 생성하는 볼륨 백업이 이 키를 사용하여 암호화됩니다.

  • new_disk_key: 백업에서 복원한 볼륨을 암호화하는 데 사용할 CMEK 키입니다. 이는 복원의 대상 클러스터에 있는 StorageClass에서 참조됩니다.

CMEK 키에 대한 액세스 권한이 필요할 수 있는 서비스 계정은 5개입니다.

  • agent_wi: 에이전트의 프리뷰 버전(버전 1.23 이하를 실행하는 GKE 클러스터)을 실행하는 경우 이 서비스 계정에 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_NUMBERBackupPlan에 할당된 테넌트 프로젝트의 번호입니다.

  • 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_agentroles/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

프로젝트 수준에서 키에 대한 액세스 권한을 부여하거나(해당 프로젝트의 모든 키에 대한 액세스 권한 부여) 개별 키에 대한 액세스 권한을 부여하도록 선택할 수 있습니다.

프로젝트 수준 액세스 권한 부여

프로젝트 수준에서 키에 대한 액세스 권한을 부여할 수 있습니다. 그러면 해당 프로젝트의 모든 키에 대한 액세스 권한이 부여됩니다.

다음 안내에 따라 프로젝트 수준에서 액세스 권한을 부여합니다.

콘솔

  1. Google Cloud 콘솔에서 IAM 페이지로 이동합니다.

    IAM으로 이동

  2. 액세스 권한 부여를 클릭합니다.

  3. 새 주 구성원 필드에 서비스 계정의 이메일 주소를 입력합니다.

  4. 역할 선택 목록에서 Cloud KMS CryptoKey 암호화/복호화 역할을 선택합니다.

  5. 저장을 클릭합니다.

gcloud

  1. 프로젝트 수준에서 액세스 권한을 부여합니다.

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

    다음을 바꿉니다.

    • PROJECT_ID: 액세스 권한을 부여할 프로젝트의 ID입니다.
    • PROJECT_NUMBER: 액세스 권한을 부여할 프로젝트의 번호입니다.

Terraform

  1. 프로젝트 수준에서 액세스 권한을 부여합니다.

    resource "google_project_iam_member" "example_iam_member" {
    project = "PROJECT_ID"
    role    = "roles/cloudkms.cryptoKeyEncrypterDecrypter"
    member  = "serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com"
    }
    

    다음을 바꿉니다.

    • PROJECT_ID: 액세스 권한을 부여할 프로젝트의 ID입니다.
    • PROJECT_NUMBER: 액세스 권한을 부여할 프로젝트의 번호입니다.

키 수준에서 액세스 권한 부여

다음 안내에 따라 개별 키 수준에서 액세스 권한을 부여합니다.

콘솔

  1. Google Cloud 콘솔에서 키 관리 페이지로 이동합니다.

    키 관리로 이동

  2. 키링 이름을 클릭합니다.

  3. 키 이름을 클릭합니다.

  4. 권한 탭을 클릭합니다.

  5. 액세스 권한 부여를 클릭합니다.

  6. 새 주 구성원 필드에 서비스 계정의 이메일 주소를 입력합니다.

  7. 역할 선택 목록에서 Cloud KMS CryptoKey 암호화/복호화 역할을 선택합니다.

  8. 저장을 클릭합니다.

gcloud

  1. 개별 키 수준에서 액세스 권한을 부여합니다.

    gcloud kms keys add-iam-policy-binding KEY_NAME \
    --keyring KEY_RING \
    --location LOCATION \
    --member "serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com" \
    --role roles/cloudkms.cryptoKeyEncrypterDecrypter
    

    다음을 바꿉니다.

    • KEY_NAME: 키의 이름입니다.
    • KEY_RING: 키가 포함된 키링의 이름입니다.
    • LOCATION: 키링의 Cloud KMS 위치입니다.
    • PROJECT_NUMBER: 액세스 권한을 부여할 프로젝트의 번호입니다.

Terraform

  1. 개별 키 수준에서 액세스 권한을 부여합니다.

    resource "google_kms_crypto_key_iam_member" "crypto_key_iam_member" {
    crypto_key_id = "projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY_NAME"
    role          = "roles/cloudkms.cryptoKeyEncrypterDecrypter"
    member        = "serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com" 
    }
    

    다음을 바꿉니다.

    • PROJECT_ID: 액세스 권한을 부여할 프로젝트의 ID입니다.
    • LOCATION: 키링의 Cloud KMS 위치입니다.
    • KEY_RING: 키가 포함된 키링의 이름입니다.
    • KEY_NAME: 키의 이름입니다.
    • PROJECT_NUMBER: 액세스 권한을 부여할 프로젝트의 번호입니다.

사용 고려사항 및 제한사항

  • CMEK로 암호화된 볼륨을 백업하려면 BackupPlan에서 CMEK 암호화를 사용 설정하지 않더라도 디스크의 키에 대한 액세스 권한을 부여해야 합니다.

  • 백업에 계속 액세스할 수 있으므로 리전 서비스 중단으로 키에 대한 액세스 권한이 삭제되지 않도록 CMEK 키가 BackupPlan과 동일한 리전에 있어야 합니다. 그러나 암호화된 볼륨과 공유되는 키에는 이 제약조건을 적용할 수 없습니다. 암호화된 볼륨이 관련된 경우 디스크 암호화 키가 백업과 동일한 리전에 저장되지 않을 수 있으므로 백업을 사용할 수 있는 경우에도 복원이 실패할 수 있습니다.