기밀 리소스 만들기 및 액세스 권한 부여

데이터 공동작업자

---

데이터 공동작업자는 워크로드에서 액세스할 수 있도록 기밀 데이터에 대해 다음 리소스를 설정해야 합니다.

• Google Cloud에 저장된 암호화된 데이터

• 워크로드를 승인하는 워크로드 아이덴티티 풀 (WIP) WIP에서 워크로드를 승인한 후에는 데이터 공동작업자의 기밀 데이터에 액세스하여 이를 조작할 수 있습니다.

또한 데이터 공동작업자는 Confidential Space 워크로드의 결과가 저장되는 위치와 해당 결과가 각 공동작업자에게 고유한지 아니면 공유되는지 선택해야 합니다. 예를 들어 각 데이터 공동작업자가 소유한 여러 Cloud Storage 버킷에 동일한 결과를 출력할 수 있습니다.

참고: 데이터 공동작업자 리소스가 Google CloudIAM으로 관리되지 않는 경우 맞춤 잠재고객 및 선택적 nonce를 사용하여 증명 토큰을 요청하여 이러한 리소스에 대한 액세스를 관리할 수 있습니다. 워크로드 작성자와 협력하여 이를 구현하세요. 자세한 내용은 Google Cloud IAM으로 관리되지 않는 리소스에 액세스를 참고하세요.

암호화된 데이터 저장

데이터를 저장하는 모든 Google Cloud 서비스를 사용하여 기밀 데이터를 호스팅할 수 있습니다. 예를 들어 다음 서비스를 사용할 수 있습니다.

• BigQuery

• Cloud SQL

• Filestore

• Persistent Disk

• Cloud Storage

내장 기능을 사용하든 Cloud Key Management Service (Cloud KMS)와 같은 서비스를 사용하든 이 데이터가 저장 상태로 암호화되어 있는지 확인해야 합니다.

주의: 데이터에서 워크로드를 테스트할 때는 개인 정보를 사용하지 마세요. 동일한 형식으로 가짜 데이터를 설정하고 워크로드를 잠글 준비가 될 때까지 해당 데이터로 테스트합니다.

WIP로 워크로드 승인

WIP는 Confidential Space가 외부 워크로드가 제휴 ID로 기밀 데이터에 액세스하고 기밀 데이터를 사용할 수 있도록 허용하는 데 사용하는 메커니즘입니다. 제휴 ID는 자체 프로젝트 내에서 주 구성원인 것처럼 취급되는 외부 엔티티로, IAM 역할을 부여하여 특정 리소스에 액세스하거나 서비스 계정을 가장하여 동일한 작업을 실행할 수 있습니다.

데이터 공동작업자는 WIP 내에서 제공업체를 설정하여 연합 ID로 인증하는 항목의 규칙을 설정합니다. 컨피덴셜 스페이스의 경우 제공자에서 다음을 정의해야 합니다.

• 증명 서비스: 이 서비스는 워크로드가 컨피덴셜 VM 인스턴스임을 확인하고 최종적으로 OpenID Connect(OIDC) 증명 토큰을 WIP 제공업체에 반환합니다. 워크로드 운영자는 사용되는 증명 서비스를 설정하며, 액세스 권한이 부여되려면 WIP 공급자에 추가된 증명 서비스와 일치해야 합니다.

• 속성 매핑: 인증 엔티티(이 경우 워크로드를 실행하는 VM 인스턴스)에서 생성한 어설션에 매핑되는 보안 토큰 서비스 액세스 토큰의 속성입니다. 어설션은 VM 인스턴스 자체, Confidential Space 이미지, 워크로드 컨테이너에 의해 이루어지며 워크로드에 의해 WIP 제공자에게 전달됩니다. 이러한 속성은 Cloud Logging의 감사 추적과 같은 용도로 사용되며, 워크로드 이미지 컨테이너 다이제스트와 같은 인증된 엔티티 어설션을 기반으로 IAM을 통해 역할을 부여하는 데도 사용됩니다. 속성 매핑에 대해 자세히 알아보세요.

• 증명 정책: 인증 엔티티가 액세스 권한을 얻기 위해 통과해야 하는 일련의 조건입니다. 이는 엔티티가 주장하는 내용을 기반으로 합니다.

워크로드가 시작되면 Confidential Space 런처는 워크로드 운영자가 정의한 증명 서비스에 증명 보고서를 전송합니다. 이 서비스는 컨피덴셜 VM 인스턴스를 확인한 후 OIDC 증명 토큰을 반환합니다. 이 토큰은 1시간 동안 지속되며 자동으로 새로고침됩니다.

그런 다음 증명 토큰이 워크로드에 의해 WIP 제공업체에 전달되고 제공업체는 이를 사용하여 어설션이 제공업체에 정의된 증명 정책을 통과하는지 확인합니다. 이 경우 워크로드가 컨피덴셜 리소스에 액세스할 수 있습니다.

참고: 토큰 검증에 Google 서버를 사용하는 대신 장기 인증서로 증명 토큰을 직접 검증할 수 있습니다.

외부 워크로드 액세스

WIP와 제공업체를 설정하기 전에 워크로드가 리소스에 액세스하는 방법을 선택해야 합니다(직접 리소스 액세스 또는 서비스 계정 가장).

직접 리소스 액세스

워크로드에는 직접 리소스 액세스 방법을 사용하는 것이 좋습니다.

이 방법은 인증 엔티티의 어설션에 연결된 WIP 제공업체에서 제휴 ID를 설정하는 것을 포함합니다. 이렇게 하면 워크로드의 컨테이너 이미지 다이제스트와 같은 속성을 기반으로 IAM 바인딩을 통해 리소스에 직접 액세스하도록 워크로드를 승인할 수 있습니다.

직접 리소스 액세스에는 다음과 같은 이점이 있습니다.

• 데이터 공동작업자가 워크로드 서비스 계정이 가장할 서비스 계정을 설정할 필요가 없으므로 컨피덴셜 스페이스 환경을 설정하는 데 필요한 단계가 적습니다.

• 워크로드는 IAM에 의해 결정된 특정 리소스에만 액세스할 수 있습니다. 이는 권한이 과도하게 부여된 서비스 계정이나 가장 권한으로 인해 악의적인 행위자에게 의도한 것보다 더 많은 액세스 권한이 부여될 수 있는 서비스 계정 가장 방법보다 더 안전합니다.

• 각 리소스 액세스는 여러 워크로드에서 공유할 수 있는 가장된 서비스 계정의 ID 대신 워크로드 VM 인스턴스의 제휴 ID로 로깅됩니다. 워크로드 VM 인스턴스의 ID에는 컨테이너의 이미지 다이제스트, 워크로드가 작동하는 프로젝트 번호, 워크로드를 실행하는 VM 인스턴스의 ID와 같은 세부정보가 포함되어 더 자세한 감사 추적을 제공할 수 있습니다.

• WIP 제공자에서 VM 인스턴스 selfLink 속성을 google.subject 속성에 매핑할 필요가 없습니다. selfLink 값이 매우 길면 이 속성의 127바이트 제한을 초과하여 WIP 제공업체 인증이 실패할 수 있습니다.

서비스 계정 가장

서비스 계정 명의 도용 방법은 각 데이터 공동작업자가 서비스 계정을 설정하여 비공개 데이터를 복호화한 다음 해당 서비스 계정을 자체 WIP에 연결하는 것입니다. 또한 WIP 제공업체에서 워크로드 서비스 계정을 지정하여 워크로드 서비스 계정이 데이터 공동작업자 서비스 계정을 가장하여 기밀 데이터를 가져오고 조작할 수 있도록 합니다.

서비스 계정 가장은 다음 시나리오에서만 사용해야 합니다.

• 속성 매핑과 서명에서 사용하는 구문이 호환되지 않으므로 이미지 서명을 인증 사용자 인증 정보로 사용해야 하는 경우

• 제휴 ID를 지원하지 않는 API에 액세스하는 경우

VM 인스턴스에 매우 긴 selfLink 속성이 있으면 서비스 계정 가장 방법이 WIP 제공자에 인증하지 못할 수 있습니다. 이는 증명 토큰의 sub 클레임(selfLink 값으로 설정됨)이 WIP 공급자에서 127바이트 제한이 있는 google.subject 속성에 매핑되기 때문입니다.

VM 인스턴스 selfLink 값이 127바이트를 초과하는 경우 VM 인스턴스의 이름을 바꿔 selfLink를 단축하거나 직접 리소스 액세스 방법을 대신 사용해야 합니다.

WIP 및 제공업체 설정

제공업체 설정 단계는 직접 리소스 액세스를 사용하는지 또는 서비스 계정 가장을 사용하는지에 따라 달라집니다.

직접 리소스 액세스

직접 리소스 액세스 방법에는 WIP 및 제공업체를 설정한 다음 특정 워크로드 컨테이너 이미지 다이제스트를 기반으로 IAM 역할을 설정하는 것이 포함됩니다.

WIP 및 제공업체 설정

WIP 및 제공업체를 설정하려면 다음 안내를 따르세요.

1. WIP를 만듭니다.

   gcloud iam workload-identity-pools create DATA_COLLABORATOR_POOL_NAME \
       --location=global
   

2. WIP에서 OIDC 제공업체를 만듭니다.

   gcloud iam workload-identity-pools providers create-oidc attestation-verifier \
       --location=global \
       --workload-identity-pool=DATA_COLLABORATOR_POOL_NAME \
       --issuer-uri="https://confidentialcomputing.googleapis.com/" \
       --allowed-audiences="https://sts.googleapis.com" \
       --attribute-mapping="google.subject=\"gcpcs::\"+assertion.submods.container.image_digest+\"::\"+assertion.submods.gce.project_number+\"::\"+assertion.submods.gce.instance_id,attribute.image_digest=assertion.submods.container.image_digest" \
       --attribute-condition="assertion.swname == 'CONFIDENTIAL_SPACE' \
           && 'STABLE' in assertion.submods.confidential_space.support_attributes"
   

   이 예시에서는 다음 값을 사용합니다.

   • https://confidentialcomputing.googleapis.com/의 issuer-uri입니다. 즉, Google Cloud 증명이 증명 서비스로 사용됩니다.

   • https://sts.googleapis.com의 allowed-audiences입니다. 이는 사용자 인증 정보를 액세스 토큰으로 교환하는 Google의 보안 토큰 서비스입니다.

   • google.subject의 attribute-mapping(다음 값 포함)

     \"gcpcs::\"+assertion.submods.container.image_digest+\"::\"+assertion.submods.gce.project_number+\"::\"+assertion.submods.gce.instance_id,attribute.image_digest=assertion.submods.container.image_digest
     

     이 값은 Common Expression Language(CEL)을 사용하여 구성됩니다. 다음 값은 gcpcs 속성에 할당되며 워크로드가 리소스에 액세스할 때마다 Cloud Logging에 표시됩니다.

     • assertion.submods.container.image_digest: 워크로드 컨테이너 이미지 다이제스트입니다.

     • assertion.submods.gce.project_number: VM 인스턴스의 프로젝트 번호입니다.

     • assertion.submods.gce.instance_id: VM 인스턴스의 ID입니다.

     또한 attribute.image_digest이 워크로드 컨테이너 이미지 다이제스트인 assertion.submods.container.image_digest로 설정됩니다. 이 속성은 특정 이미지 다이제스트를 기반으로 제휴 ID IAM 역할을 부여할 수 있도록 매핑됩니다.

     google.subject 값의 총 길이가 127바이트 미만인 경우 사용 가능한 워크로드 어설션을 매핑할 수 있습니다.

   • 증명 정책을 구성하는 다음 attribute-conditions 이러한 조건이 워크로드의 어설션과 일치하면 워크로드가 제휴 ID로 컨피덴셜 리소스에 액세스할 수 있습니다.

     • assertion.swname == 'CONFIDENTIAL_SPACE': 컨피덴셜 스페이스가 VM에서 실행되는 소프트웨어이며 모든 내장 보안 보장이 있는지 확인합니다.

     • 'STABLE' in assertion.submods.confidential_space.support_attributes: 프로덕션 Confidential Space 이미지가 사용 중이며 STABLE 지원 속성이 있는지 확인합니다.

     사용할 수 있는 속성 조건에 대한 자세한 내용은 증명 정책 만들기를 참고하세요.

제휴 ID에 IAM 역할 부여

WIP 공급자를 만든 후 ID의 워크로드 이미지 컨테이너 다이제스트가 예상 값과 일치하는지 여부에 따라 제휴 ID에 IAM 역할을 부여할 수 있습니다.

다음 예에서는 특정 Cloud Key Management Service 키를 복호화할 수 있는 권한을 제휴 ID에 부여하는 방법을 보여줍니다.

gcloud kms keys add-iam-policy-binding \
    projects/DATA_COLLABORATOR_PROJECT_ID/locations/global/keyRings/DATA_COLLABORATOR_KEYRING_NAME/cryptoKeys/DATA_COLLABORATOR_KEY_NAME \
    --member="principalSet://iam.googleapis.com/projects/DATA_COLLABORATOR_PROJECT_NUMBER/locations/global/workloadIdentityPools/DATA_COLLABORATOR_POOL_NAME/attribute.image_digest/WORKLOAD_CONTAINER_IMAGE_DIGEST" \
    --role=roles/cloudkms.cryptoKeyDecrypter

서비스 계정 가장

서비스 계정 가장 방법에는 다음이 포함됩니다.

1. 각 데이터 공동작업자 프로젝트에서 서비스 계정을 만들고 기밀 데이터를 복호화할 권한을 부여합니다.

2. 각 데이터 공동작업자 프로젝트에서 WIP를 만든 다음, 방금 만든 각 프로젝트의 서비스 계정을 해당 WIP에 연결합니다.

3. 각 WIP에서 WIP 제공자를 만들어 데이터 공동작업자 서비스 계정을 가장할 수 있는 계정으로 워크로드 서비스 계정을 지정합니다.

기밀 데이터를 복호화할 서비스 계정 설정

1. 데이터 공동작업자 프로젝트에서 서비스 계정을 만듭니다.

   gcloud iam service-accounts create DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME
   

   서비스 계정에 기밀 데이터를 복호화하는 데 필요한 권한을 부여합니다. 예를 들어 Cloud KMS로 Cloud Storage의 기밀 파일을 암호화하는 경우 서비스 계정에 해당 데이터를 복호화할 수 있는 권한을 부여해야 합니다.

   gcloud kms keys add-iam-policy-binding \
       projects/DATA_COLLABORATOR_PROJECT_ID/locations/global/keyRings/DATA_COLLABORATOR_KEYRING_NAME/cryptoKeys/DATA_COLLABORATOR_KEY_NAME \
       --member=serviceAccount:DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME@DATA_COLLABORATOR_PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/cloudkms.cryptoKeyDecrypter
   

WIP 및 제공업체 설정

WIP 및 제공자를 설정하려면 각 데이터 공동작업자 프로젝트에서 다음 안내를 완료하세요.

1. WIP를 만듭니다.

   gcloud iam workload-identity-pools create DATA_COLLABORATOR_POOL_NAME \
       --location=global
   

2. 가장할 서비스 계정을 WIP에 연결합니다(roles/iam.workloadIdentityUser 역할 사용).

   gcloud iam service-accounts add-iam-policy-binding \
       DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME@DATA_COLLABORATOR_PROJECT_ID.iam.gserviceaccount.com \
       --member="principalSet://iam.googleapis.com/projects/DATA_COLLABORATOR_PROJECT_NUMBER/locations/global/workloadIdentityPools/DATA_COLLABORATOR_POOL_NAME/*" \
       --role=roles/iam.workloadIdentityUser
   

3. WIP에서 OIDC 제공업체를 만들고 데이터 공동작업자 서비스 계정을 가장할 수 있도록 워크로드 서비스 계정을 정의합니다.

   gcloud iam workload-identity-pools providers create-oidc attestation-verifier \
       --location=global \
       --workload-identity-pool=DATA_COLLABORATOR_POOL_NAME \
       --issuer-uri="https://confidentialcomputing.googleapis.com/" \
       --allowed-audiences="https://sts.googleapis.com" \
       --attribute-mapping="google.subject=assertion.sub" \
       --attribute-condition="assertion.submods.container.image_digest == 'WORKLOAD_CONTAINER_IMAGE_DIGEST' \
   && 'WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_OPERATOR_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts \
   && assertion.swname == 'CONFIDENTIAL_SPACE' \
   && 'STABLE' in assertion.submods.confidential_space.support_attributes"
   

   이 예시에서는 다음 값을 사용합니다.

   • https://confidentialcomputing.googleapis.com/의 issuer-uri입니다. 즉, Google Cloud 증명이 증명 서비스로 사용됩니다.

   • https://sts.googleapis.com의 allowed-audiences입니다. 이는 사용자 인증 정보를 액세스 토큰으로 교환하는 Google의 보안 토큰 서비스입니다.

   • google.subject의 attribute-mapping(값은 assertion.sub) 이는 증명 토큰의 sub 클레임에 정의된 VM 인스턴스의 selfLink입니다.

     워크로드가 리소스에 액세스할 때마다 VM 인스턴스 selfLink가 Cloud Logging에 표시됩니다.

   • 증명 정책을 구성하는 다음 attribute-conditions 이러한 조건이 워크로드의 어설션과 일치하면 워크로드가 제휴 ID로 리소스에 액세스할 수 있습니다.

     • assertion.submods.container.image_digest == 'WORKLOAD_CONTAINER_IMAGE_DIGEST': 워크로드 컨테이너 이미지 다이제스트가 예상 값과 일치하는지 확인합니다.

     • 'WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts: 워크로드에 연결된 서비스 계정이 예상 서비스 계정과 일치하는지 확인한 다음 이를 사용하여 데이터 공동작업자 서비스 계정을 가장합니다.

     • assertion.swname == 'CONFIDENTIAL_SPACE': 컨피덴셜 스페이스가 VM에서 실행되는 소프트웨어이며 모든 내장 보안 보장이 있는지 확인합니다.

     • 'STABLE' in assertion.submods.confidential_space.support_attributes: 프로덕션 Confidential Space 이미지가 사용 중이며 STABLE 지원 속성이 있는지 확인합니다.

     사용할 수 있는 속성 조건에 대한 자세한 내용은 증명 정책 만들기를 참고하세요.

증명 정책 만들기

WIP를 만드는 과정에서 증명 정책을 만들어야 합니다. 인증 엔티티의 어설션이 데이터에 액세스할 수 있도록 정책과 일치해야 합니다.

정책은 Common Expression Language(CEL)로 작성되며 && 연산자를 사용하여 연결할 수 있는 일련의 문으로 구성됩니다.

명령문은 Confidential Space 이미지, 워크로드 컨테이너 이미지 또는 VM 인스턴스의 어설션을 변수로 사용하고 지정된 값을 표현식으로 사용합니다. 예를 들어 워크로드가 Confidential Space를 사용하고 STABLE Confidential Space 이미지를 사용해야 하며 워크로드 VM 인스턴스가 실행되는 영역이 us-central1-a여야 한다는 정책은 다음과 같습니다.

assertion.swname == 'CONFIDENTIAL_SPACE' \
&& 'STABLE' in assertion.submods.confidential_space.support_attributes" \
&& assertion.submods.gce.zone == "us-central1-a"

자세한 내용은 증명 어설션을 참고하세요.

증명 어설션

다음 표에서는 증명 정책을 구성하는 데 사용할 수 있는 어설션을 자세히 보여줍니다. 정책은 Confidential Space 이미지, 워크로드 컨테이너, VM 인스턴스에서 수행한 어설션을 검증할 수 있습니다.

이미지 어설션

어설션	유형	설명
assertion.dbgstat 상호작용: 워크로드 운영자: --image-family 값입니다.	정의된 문자열	Confidential Space 이미지가 디버그 또는 프로덕션 버전인지 확인합니다. 유효한 값은 다음과 같습니다. enable: 디버그 이미지가 사용되고 있는지 확인합니다. disabled-since-boot: 프로덕션 이미지가 사용되고 있는지 확인합니다. 예시 다음 코드는 Confidential Space 이미지의 디버그 버전이 사용 중인지 확인합니다. assertion.dbgstat == "enable" 다음 코드는 Confidential Space 이미지의 프로덕션 버전이 사용 중인지 확인합니다. assertion.dbgstat == "disabled-since-boot"
assertion.submods.confidential_space.support_attributes	문자열 배열	TEE의 보안 버전이 프로덕션 Confidential Space 이미지인지 확인합니다. 디버그 Confidential Space 이미지에는 설정된 지원 속성이 없습니다. 지원 속성은 3가지입니다. LATEST: 최신 버전의 이미지이며 지원이 제공됩니다. LATEST 이미지는 STABLE 및 USABLE이기도 합니다. STABLE: 이 버전의 이미지는 지원이 제공되며 취약점이 모니터링됩니다. STABLE 이미지도 USABLE입니다. USABLE: 이 속성만 있는 이미지는 지원이 중단되어 더 이상 취약점이 모니터링되지 않습니다. 사용에 따른 책임은 사용자에게 있습니다. EXPERIMENTAL: 이 속성만 있는 이미지는 미리보기 기능을 사용합니다. 테스트용으로만 사용되며 프로덕션에 사용해서는 안 됩니다. EXPERIMENTAL 이미지는 LATEST, STABLE 또는 USABLE 속성을 갖지 않습니다. 주의: 컨피덴셜 스페이스 기본 토큰은 매시간 새로고침되므로 장기 실행 워크로드에는 LATEST를 지정하지 않는 것이 좋습니다. 워크로드가 실행되는 동안 Confidential Space 이미지가 업데이트될 수 있습니다. 즉, 워크로드가 더 이상 최신 버전이 아니며 그 결과 증명에 실패합니다. 예 다음 코드는 안정적인 버전의 Confidential Space 이미지가 사용 중인지 확인합니다. "STABLE" in assertion.submods.confidential_space.support_attributes
assertion.swname	정의된 문자열	증명 항목에서 실행되는 소프트웨어를 확인합니다. 이 값은 항상 CONFIDENTIAL_SPACE입니다. 예 assertion.swname == "CONFIDENTIAL_SPACE"
assertion.swversion	문자열 배열	Confidential Space 이미지의 소프트웨어 버전을 확인합니다. 이미지의 최신 버전을 타겟팅하려면 assertion.submods.confidential_space.support_attributes을 대신 사용하는 것이 좋습니다. 예 int(assertion.swversion[0]) == 230103

컨테이너 어설션

어설션	유형	설명
assertion.submods.container.cmd_override 상호작용: 워크로드 작성자: allow_cmd_override 실행 정책입니다. 워크로드 연산자: tee-cmd 메타데이터 변수입니다.	문자열 배열	워크로드 이미지에 사용되는 CMD 명령어 및 매개변수를 확인합니다. 예시 다음 코드는 워크로드 이미지의 CMD를 덮어쓰지 않았는지 확인합니다. size(assertion.submods.container.cmd_override) == 0 다음 코드는 program가 CMD 재정의에서 유일한 콘텐츠인지 확인합니다. assertion.submods.container.cmd_override == ['program']
assertion.submods.container.env 상호작용: 워크로드 작성자: allow_env_override 실행 정책입니다. 워크로드 연산자: tee-env-ENVIRONMENT_VARIABLE_NAME 메타데이터 변수입니다.	JSON 개체	환경 변수 및 해당 값이 컨테이너로 명시적으로 전달되었는지 확인합니다. 예 다음 코드는 환경 변수 example-env-1이 value-1로 설정되었고 example-env-2가 value-2로 설정되었는지 확인합니다. assertion.submods.container.env == {"example-env-1": "value-1", "example-env-2": "value-2"}
assertion.submods.container.env_override 상호작용: 워크로드 작성자: allow_env_override 실행 정책입니다. 워크로드 연산자: tee-env-ENVIRONMENT_VARIABLE_NAME 메타데이터 변수입니다.	문자열	워크로드 연산자가 컨테이너에서 환경 변수를 덮어썼는지 확인합니다. 예시 다음 코드는 워크로드 운영자가 example 환경 변수를 재정의하지 않았는지 확인합니다. !has(assertion.submods.container.env_override.example) 다음 코드는 워크로드 운영자가 환경 변수를 덮어쓰지 않았는지 확인합니다. size(assertion.submods.container.env_override) == 0
assertion.submods.container.image_digest	문자열	워크로드 컨테이너의 이미지 다이제스트를 확인합니다. 이 조건을 지정하면 여러 당사자가 자신의 데이터에 액세스하도록 승인된 워크로드에 동의할 수 있습니다. 예 assertion.submods.container.image_digest == "sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b"
assertion.submods.container.image_id	문자열	워크로드 컨테이너의 이미지 ID를 확인합니다. 예 assertion.submods.container.image_id == "sha256:652a44b0e911271ba07cf2915cd700fdfa50abd62a98f87a57fdebc59843d93f"
assertion.submods.container.image_reference 상호작용: 워크로드 연산자: tee-image-reference 메타데이터 변수입니다.	문자열	Confidential Space 이미지에서 실행되는 워크로드 컨테이너의 위치를 확인합니다. 예 assertion.submods.container.image_reference == "us-docker.pkg.dev/PROJECT_ID/WORKLOAD_CONTAINER:latest"
assertion.submods.container.image_signatures 상호작용: 워크로드 연산자: tee-signed-image-repos 메타데이터 변수입니다.	JSON 개체	이미지에 특정 서명이 있거나 공개 키와 서명 알고리즘으로 서명되었는지 확인합니다. 이 조건을 지정하면 여러 당사자가 자신의 데이터에 액세스하도록 승인된 워크로드에 동의할 수 있습니다. 어설션에는 다음 요소가 포함될 수 있습니다. key_id: 공개 키의 16진수 디지털 지문입니다. 지문을 가져오려면 다음 명령어를 실행하면 됩니다. openssl pkey -pubin -in public_key.pem -outform DER | openssl sha256 여기서 public_key.pem는 PEM 형식의 공개 키입니다. signature: 서명된 컨테이너와 연결되고 간단한 서명 형식을 따르는 페이로드의 서명입니다. signature_algorithm: 키에 서명하는 데 사용되는 알고리즘입니다. 다음 중 하나입니다. RSASSA_PSS_SHA256 (SHA-256 다이제스트가 있는 RSASSA-PSS) RSASSA_PKCS1V15_SHA256 (SHA-256 다이제스트를 사용하는 RSASSA-PKCS1 v1_5) ECDSA_P256_SHA256 (P-256 곡선의 ECDSA, SHA-256 다이제스트) 예 assertion.swname == 'CONFIDENTIAL_SPACE' && ['ECDSA_P256_SHA256:PUBLIC_KEY_FINGERPRINT'].exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig, sig.signature_algorithm+':'+sig.key_id)) && 'serviceaccount.iam.gserviceaccount.com' in assertion.google_service_accounts"
assertion.submods.container.restart_policy 상호작용: 워크로드 연산자: tee-restart-policy 메타데이터 변수입니다.	정의된 문자열	워크로드가 중지될 때 컨테이너 런처의 다시 시작 정책을 확인합니다. 유효한 값은 다음과 같습니다. Never(기본) Always OnFailure 예 assertion.submods.container.restart_policy == "Never"

VM 어설션

어설션	유형	설명
assertion.google_service_accounts 상호작용: 워크로드 연산자: tee-impersonate-service-accounts 메타데이터 변수 및 --service-account 값입니다.	문자열 배열	지정된 서비스 계정이 워크로드를 실행하는 VM에 연결되었는지 또는 VM 메타데이터에서 tee-impersonate-service-accounts 를 사용하여 나열되었는지 확인합니다. 예 [e-mail] in assertion.google_service_accounts
assertion.hwmodel	문자열	기본 컨피덴셜 컴퓨팅 기술을 확인합니다. 지원되는 플랫폼은 다음과 같습니다. GCP_AMD_SEV INTEL_TDX 예 assertion.hwmodel == "GCP_AMD_SEV"
assertion.submods.confidential_space.monitoring_enabled 상호작용: 워크로드 작성자: monitoring_memory_allow 실행 정책입니다. 워크로드 연산자: tee-memory-monitoring-enable 메타데이터 변수입니다.	불리언	증명 항목의 모니터링 상태를 확인합니다. 예 assertion.submods.confidential_space.monitoring_enabled.memory == true
assertion.submods.gce.instance_id	문자열	VM 인스턴스 ID를 확인합니다. 예 assertion.submods.gce.instance_id == "0000000000000000000"
assertion.submods.gce.instance_name	문자열	VM 인스턴스의 이름을 확인합니다. 예 assertion.submods.gce.instance_name == "workload-vm"
assertion.submods.gce.project_id	문자열	VM이 지정된 프로젝트 ID로 Google Cloud 프로젝트를 실행하는지 확인합니다. 예 assertion.submods.gce.project_id == "project-id"
assertion.submods.gce.project_number	문자열	VM이 지정된 프로젝트 번호로 Google Cloud 프로젝트에서 실행되는지 확인합니다. 예 assertion.submods.gce.project_number == "00000000000"
assertion.submods.gce.zone 상호작용: 워크로드 운영자: --zone 값입니다.	문자열	VM이 지정된 영역에서 실행되는지 확인합니다. 예 assertion.submods.gce.zone == "us-central1-a"
assertion.submods.nvidia_gpu.cc_mode 상호작용: 워크로드 연산자: tee-install-gpu-driver 메타데이터 변수	정의된 문자열	NVIDIA의 컨피덴셜 컴퓨팅 드라이버 상태를 확인합니다. 유효한 값은 다음과 같습니다. OFF: NVIDIA 컨피덴셜 컴퓨팅 기능이 활성화되어 있지 않습니다. ON: NVIDIA H100 하드웨어, 펌웨어, 소프트웨어에서 컨피덴셜 컴퓨팅 기능을 완전히 활성화했습니다. DEVTOOLS: GPU가 ON 모드의 워크플로와 일치하지만 보안 보호를 사용 중지하는 부분 컨피덴셜 컴퓨팅 모드에 있습니다. 예 assertion.submods.nvidia_gpu.cc_mode == "ON"