Crie e conceda acesso a recursos confidenciais

Os colaboradores de dados têm de configurar os seguintes recursos para que os respetivos dados confidenciais sejam acessíveis por uma carga de trabalho:

  • Dados encriptados, armazenados no Google Cloud.

  • Um Workload Identity Pool (WIP) para autorizar a carga de trabalho. Depois de uma carga de trabalho ser autorizada por um WIP, pode aceder aos dados confidenciais dos colaboradores de dados e operar sobre eles.

Além disso, os colaboradores de dados têm de escolher onde os resultados da carga de trabalho do espaço confidencial são armazenados e se esses resultados são exclusivos de cada colaborador ou partilhados. Por exemplo, pode optar por gerar o mesmo resultado em vários contentores do Cloud Storage pertencentes a cada colaborador de dados.

Armazene os seus dados encriptados

Pode usar qualquer Google Cloud serviço que armazene dados para alojar os seus dados confidenciais. Por exemplo, pode usar um dos seguintes serviços:

Deve certificar-se de que estes dados estão encriptados em repouso, quer use funcionalidades incorporadas ou algo como o Cloud Key Management Service (Cloud KMS).

Autorize a carga de trabalho com um WIP

Um WIP é o mecanismo que o espaço confidencial usa para permitir que uma carga de trabalho externa aceda e trabalhe com os seus dados confidenciais como uma identidade federada. Uma identidade federada é uma entidade externa tratada como se fosse um principal no seu próprio projeto, o que lhe permite conceder funções de IAM para dar acesso a recursos específicos ou roubar a identidade de contas de serviço para fazer o mesmo.

Como colaborador de dados, configura um fornecedor num WIP que define as regras para entidades que se autenticam como uma identidade federada. Para o Confidential Space, tem de definir o seguinte num fornecedor:

  • Um serviço de atestação: este serviço verifica se a carga de trabalho é uma instância de VM confidencial e, em última análise, devolve um token de atestação do OpenID Connect (OIDC) ao fornecedor do WIP. O operador da carga de trabalho define o serviço de atestação usado e tem de corresponder ao serviço de atestação adicionado ao fornecedor do WIP para que o acesso seja concedido.

  • Mapeamentos de atributos: atributos nos tokens de acesso do serviço de tokens de segurança que são mapeados para afirmações feitas pela entidade de autenticação, neste caso, a instância de VM que está a executar a carga de trabalho. As afirmações são feitas pela própria instância da VM, pela imagem do espaço confidencial e pelo contentor da carga de trabalho, e são transmitidas ao fornecedor da WIP pela carga de trabalho. Estes atributos são usados para itens como rastos de auditoria no Cloud Logging e para conceder funções através do IAM com base na autenticação de afirmações de entidades, como resumos de contentores de imagens de cargas de trabalho. Leia mais acerca dos mapeamentos de atributos.

  • Uma política de atestação: uma série de condições que as entidades de autenticação têm de cumprir para obter acesso, com base nas declarações que fazem.

Quando uma carga de trabalho é iniciada, o Confidential Space Launcher envia o respetivo relatório de atestação a um serviço de atestação definido pelo operador da carga de trabalho, que valida a instância de VM confidencial e, em seguida, devolve um token de atestação OIDC. Este token dura uma hora e é atualizado automaticamente.

Em seguida, o token de atestação é transmitido ao fornecedor da WIP pela carga de trabalho, e o fornecedor usa-o para verificar se as afirmações passam na política de atestação definida no fornecedor. Se o fizer, a carga de trabalho tem acesso aos recursos confidenciais.

Acesso a cargas de trabalho externas

Antes de configurar um WIP e um fornecedor, tem de escolher como a carga de trabalho vai aceder aos seus recursos: acesso direto aos recursos ou roubo de identidade da conta de serviço.

Acesso direto aos recursos

Recomendamos o método de acesso direto aos recursos para cargas de trabalho.

Este método envolve a configuração de uma identidade federada num fornecedor do WIP associado às afirmações de uma entidade de autenticação. Desta forma, uma carga de trabalho pode ser autorizada a aceder a recursos diretamente através de associações da IAM, com base em atributos como o resumo da imagem do contentor da carga de trabalho.

O acesso direto aos recursos tem as seguintes vantagens:

  • A configuração de um ambiente do espaço confidencial requer menos passos, uma vez que os colaboradores de dados não têm de configurar contas de serviço para uma conta de serviço de carga de trabalho se fazer passar por outra.

  • A carga de trabalho só tem permissão para aceder a recursos específicos, conforme determinado pela IAM. Isto é mais seguro do que o método de roubo de identidade da conta de serviço, em que as contas de serviço com autorizações excessivas ou os direitos de roubo de identidade podem dar a um agente malicioso mais acesso do que o pretendido.

  • Cada acesso a recursos é registado com a identidade federada de uma instância de VM de carga de trabalho, em vez da identidade de uma conta de serviço roubada que pode ser partilhada por várias cargas de trabalho. A identidade de uma instância de VM de carga de trabalho pode incluir detalhes como o resumo da imagem de um contentor, o número do projeto a partir do qual a carga de trabalho está a operar e o ID da instância de VM que executa a carga de trabalho, o que fornece uma trilha de auditoria mais detalhada.

  • Não precisa de mapear a propriedade da instância de VM selfLink para o atributo google.subject num fornecedor de WIP. Os valores selfLink muito longos podem exceder o limite de 127 bytes deste atributo, o que faz com que a autenticação do fornecedor do WIP falhe.

Simulação de identidade de conta de serviço

O método de roubo de identidade da conta de serviço envolve a configuração de uma conta de serviço por parte de cada colaborador de dados para desencriptar os respetivos dados privados e, em seguida, anexar essa conta de serviço ao respetivo WIP. Também especificam a conta de serviço da carga de trabalho no respetivo fornecedor do WIP, o que permite que a conta de serviço da carga de trabalho se faça passar pelas contas de serviço do colaborador de dados para poder obter e operar nos respetivos dados confidenciais.

A representação de contas de serviço só deve ser usada nos seguintes cenários:

O método de roubo de identidade da conta de serviço pode não conseguir autenticar-se num fornecedor de WIP se uma instância de VM tiver uma propriedade selfLink muito longa. Isto deve-se ao facto de a reivindicação sub no token de atestação, que está definida para o valor selfLink, ser mapeada no fornecedor de WIP para o atributo google.subject, que tem um limite de 127 bytes.

Para valores de selfLink de instâncias de VM que excedam 127 bytes, tem de mudar o nome das instâncias de VM para encurtar o selfLink ou usar o método de acesso direto aos recursos.

Configure um WIP e um fornecedor

Os passos para configurar um fornecedor variam consoante use o acesso direto aos recursos ou a representação da conta de serviço.

Acesso direto aos recursos

O método de acesso direto aos recursos envolve a configuração de um WIP e de um fornecedor e, em seguida, a configuração de funções da IAM com base num resumo da imagem do contentor de carga de trabalho específico.

Configure um WIP e um fornecedor

Para configurar um WIP e um fornecedor, siga estas instruções:

  1. Crie o WIP:

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

  2. Crie um fornecedor de OIDC no WIP:

    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"

    Este exemplo usa os seguintes valores:

    • Uma issuer-uri de https://confidentialcomputing.googleapis.com/, o que significa que a Atestação do Google Cloud é usada como o serviço de atestação.

    • Um allowed-audiences de https://sts.googleapis.com. Este é o serviço de tokens de segurança da Google, que troca credenciais por tokens de acesso.

    • Um attribute-mapping de google.subject, com o seguinte valor:

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

      Este valor é construído através do Idioma de expressão comum (IEC). Os seguintes valores são atribuídos ao atributo gcpcs e são apresentados no Cloud Logging sempre que a carga de trabalho acede a recursos:

      • assertion.submods.container.image_digest: o resumo da imagem do contentor da carga de trabalho.

      • assertion.submods.gce.project_number: o número do projeto da instância de VM.

      • assertion.submods.gce.instance_id: o ID da instância de VM.

      Além disso, attribute.image_digest está definido como assertion.submods.container.image_digest, o resumo da imagem do contentor da carga de trabalho. Este atributo é mapeado para que possa conceder funções de IAM de identidade federada com base num resumo de imagem específico.

      Pode mapear qualquer uma das afirmações da carga de trabalho disponíveis, desde que o comprimento total do valor google.subject seja inferior a 127 bytes.

    • O seguinte attribute-conditions, que forma uma política de atestação. Se estas condições corresponderem às afirmações da carga de trabalho, a carga de trabalho tem autorização para aceder aos recursos confidenciais como uma identidade federada:

      • assertion.swname == 'CONFIDENTIAL_SPACE': verifica se o Confidential Space é o software em execução na VM, com todas as respetivas garantias de segurança incorporadas.

      • 'STABLE' in assertion.submods.confidential_space.support_attributes: Verifica se a imagem do espaço confidencial de produção está a ser usada e tem o STABLE atributo support.

      Para ver mais condições de atributos que pode usar, consulte o artigo Crie uma política de atestação.

Conceda as funções IAM de identidade federada

Depois de criar um fornecedor do WIP, pode conceder à identidade federada uma função do IAM com base no facto de o resumo do contentor da imagem da carga de trabalho da identidade corresponder ou não a um valor esperado.

O exemplo seguinte demonstra a concessão a uma identidade federada da capacidade de desencriptar uma chave específica do Cloud Key Management Service:

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

Simulação de identidade de conta de serviço

O método de simulação de conta de serviço envolve o seguinte:

  1. Criar contas de serviço em cada um dos projetos de colaborador de dados e conceder-lhes autorização para desencriptar os dados confidenciais.

  2. Criar WIPs em cada um dos projetos de colaborador de dados e, em seguida, anexar a conta de serviço de cada projeto que acabou de ser criada ao respetivo WIP.

  3. Criar fornecedores de WIP em cada WIP que especifiquem a conta de serviço da carga de trabalho como a conta que pode roubar a identidade das contas de serviço de colaborador de dados.

Configure contas de serviço para desencriptar dados confidenciais

  1. Crie as contas de serviço nos projetos de colaborador de dados:

    gcloud iam service-accounts create DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME

    Conceda às contas de serviço as autorizações necessárias para desencriptar os dados confidenciais. Por exemplo, pode encriptar ficheiros confidenciais no Cloud Storage com o Cloud KMS, pelo que tem de conceder à conta de serviço autorização para desencriptar esses dados:

    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

Configure um WIP e um fornecedor

Para configurar um WIP e um fornecedor, siga as instruções abaixo em cada projeto de colaborador de dados:

  1. Crie o WIP:

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

  2. Anexe a conta de serviço que vai ser simulada ao WIP com a função 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. Crie um fornecedor OIDC no WIP e defina a conta de serviço da carga de trabalho no mesmo para que possa roubar a identidade da conta de serviço do colaborador de dados:

    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"

    Este exemplo usa os seguintes valores:

    • Uma issuer-uri de https://confidentialcomputing.googleapis.com/, o que significa que a Atestação do Google Cloud é usada como o serviço de atestação.

    • Um allowed-audiences de https://sts.googleapis.com. Este é o serviço de tokens de segurança da Google, que troca credenciais por tokens de acesso.

    • Um attribute-mapping de google.subject, com o valor assertion.sub. Este é o selfLink da instância de VM, conforme definido na reivindicação sub no token de atestação.

      A instância de VM selfLink é apresentada no Cloud Logging sempre que a carga de trabalho acede a recursos.

    • O seguinte attribute-conditions, que forma uma política de atestação. Se estas condições corresponderem às afirmações da carga de trabalho, a carga de trabalho tem autorização para aceder aos recursos como uma identidade federada:

      • assertion.submods.container.image_digest == 'WORKLOAD_CONTAINER_IMAGE_DIGEST': Verifica se o resumo da imagem do contentor da carga de trabalho corresponde ao valor esperado.

      • 'WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts: Verifica se a conta de serviço anexada à carga de trabalho corresponde à conta de serviço esperada e, em seguida, usa-a para simular a conta de serviço do colaborador de dados.

      • assertion.swname == 'CONFIDENTIAL_SPACE': verifica se o Confidential Space é o software em execução na VM, com todas as respetivas garantias de segurança incorporadas.

      • 'STABLE' in assertion.submods.confidential_space.support_attributes: Verifica se a imagem do espaço confidencial de produção está a ser usada e tem o STABLE atributo support.

      Para ver mais condições de atributos que pode usar, consulte o artigo Crie uma política de atestação.

Crie uma política de atestação

Como parte da criação de um WIP, tem de criar uma política de atestação. As afirmações de uma entidade de autenticação têm de corresponder à sua política para poder aceder aos seus dados.

As políticas são escritas no Idioma de expressão comum (IEC) e são compostas por uma série de declarações que podem ser encadeadas com o operador &&.

As declarações usam afirmações da imagem do espaço confidencial, da imagem do contentor de carga de trabalho ou da instância de VM como variáveis e o valor especificado como a expressão. Por exemplo, aqui está uma política que impõe que a carga de trabalho está a usar o espaço confidencial, tem de usar uma STABLEimagem do espaço confidencial e que a zona em que a instância de VM da carga de trabalho está a ser executada tem de ser us-central1-a:

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

Consulte as afirmações de atestação para mais informações.

Afirmações de atestação

As afirmações disponíveis para criar uma política de atestação estão detalhadas na tabela seguinte. As políticas podem validar as afirmações feitas pela imagem do espaço confidencial, pelo contentor de carga de trabalho e pela instância de VM.

Afirmações de imagens

Afirmação Tipo Descrição

assertion.dbgstat

Interage com:

 String definida

Verifica se a imagem do espaço confidencial é a versão de depuração ou de produção.

Os valores válidos são:

  • enable: verifique se está a usar a imagem de depuração.
  • disabled-since-boot: verifique se está a usar a imagem de produção.
Exemplos

O código seguinte verifica se está a ser usada a versão de depuração da imagem do Confidential Space:

assertion.dbgstat == "enable"

O código seguinte verifica se está a ser usada a versão de produção da imagem do Confidential Space:

assertion.dbgstat == "disabled-since-boot"
assertion.submods.confidential_space.support_attributes Matriz de strings

Verifica se a versão de segurança do AEF é uma imagem do Confidential Space de produção. As imagens do espaço confidencial de depuração não têm o atributo de suporte definido.

Existem três atributos de apoio técnico:

  • LATEST: esta é a versão mais recente da imagem e é suportada. A imagem LATEST também é STABLE e USABLE.
  • STABLE: esta versão da imagem é suportada e monitorizada quanto a vulnerabilidades. Uma imagem STABLE também é USABLE.
  • USABLE: uma imagem com apenas este atributo está fora do apoio técnico e já não é monitorizada quanto a vulnerabilidades. Use por sua conta e risco.
  • EXPERIMENTAL: uma imagem com apenas este atributo usa funcionalidades de pré-visualização. Destina-se apenas a fins de teste e nunca deve ser usado em produção. Uma imagem EXPERIMENTAL nunca tem os atributos LATEST, STABLE ou USABLE.
Exemplo

O código seguinte verifica se está a ser usada uma versão estável da imagem do Confidential Space:

"STABLE" in assertion.submods.confidential_space.support_attributes
assertion.swname String definida

Valida o software em execução na entidade de atestação. O valor é sempre CONFIDENTIAL_SPACE.

Exemplo
assertion.swname == "CONFIDENTIAL_SPACE"
assertion.swversion Matriz de strings

Valida a versão do software da imagem do Confidential Space. Recomendamos que use assertion.submods.confidential_space.support_attributes em alternativa para segmentar a versão mais recente de uma imagem.

Exemplo
int(assertion.swversion[0]) == 230103

Afirmações do contentor

Afirmação Tipo Descrição

assertion.submods.container.cmd_override

Interage com:

 Matriz de strings

Valida os comandos e os parâmetros CMD usados na imagem da carga de trabalho.

Exemplos

O código seguinte valida se o CMD da imagem da carga de trabalho não foi substituído:

size(assertion.submods.container.cmd_override) == 0

O código seguinte verifica se program é o único conteúdo nas substituições de CMD:

assertion.submods.container.cmd_override == ['program']

assertion.submods.container.env

Interage com:

 Objeto JSON

Verifica se as variáveis de ambiente e os respetivos valores foram transmitidos explicitamente para o contentor.

Exemplo

O código seguinte verifica se a variável de ambiente example-env-1 está definida como value-1 e se example-env-2 está definida como value-2.

assertion.submods.container.env == {"example-env-1": "value-1", "example-env-2": "value-2"}

assertion.submods.container.env_override

Interage com:

 String

Verifica se o operador da carga de trabalho substituiu as variáveis de ambiente no contentor.

Exemplos

O código seguinte verifica se o operador da carga de trabalho não substituiu a variável de ambiente example:

!has(assertion.submods.container.env_override.example)

O código seguinte verifica se o operador da carga de trabalho não substituiu nenhuma variável de ambiente:

size(assertion.submods.container.env_override) == 0
assertion.submods.container.image_digest String

Valida o resumo da imagem do contentor da carga de trabalho. A especificação desta condição permite que várias partes concordem numa carga de trabalho autorizada que tem permissão para aceder aos respetivos dados.

Exemplo
assertion.submods.container.image_digest == "sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b"
assertion.submods.container.image_id String

Valida o ID da imagem do contentor da carga de trabalho.

Exemplo
assertion.submods.container.image_id == "sha256:652a44b0e911271ba07cf2915cd700fdfa50abd62a98f87a57fdebc59843d93f"

assertion.submods.container.image_reference

Interage com:

 String

Valida a localização do contentor de carga de trabalho em execução na parte superior da imagem do espaço confidencial.

Exemplo
assertion.submods.container.image_reference == "us-docker.pkg.dev/PROJECT_ID/WORKLOAD_CONTAINER:latest"

assertion.submods.container.image_signatures

Interage com:

 Objeto JSON

Valida se a imagem tem uma determinada assinatura ou se está assinada por uma chave pública e um algoritmo de assinatura. A especificação desta condição permite que várias partes concordem numa carga de trabalho autorizada que tem permissão para aceder aos respetivos dados.

A declaração pode incluir os seguintes elementos:

  • key_id: a impressão digital hexadecimal da chave pública. Para obter a impressão digital, pode executar o seguinte comando:

    openssl pkey -pubin -in public_key.pem -outform DER | openssl sha256

    Onde public_key.pem é a sua chave pública no formato PEM.

  • signature: A assinatura sobre uma carga útil associada ao contentor assinado e que segue o formato de assinatura simples.

  • signature_algorithm: O algoritmo usado para assinar a chave. Uma das seguintes opções:

    • RSASSA_PSS_SHA256 (RSASSA-PSS com um resumo SHA-256)
    • RSASSA_PKCS1V15_SHA256 (RSASSA-PKCS1 v1_5 com um resumo SHA-256)
    • ECDSA_P256_SHA256 (ECDSA na curva P-256 com um resumo SHA-256)
Exemplo
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

Interage com:

 String definida

Verifica a política de reinício do iniciador de contentores para quando a carga de trabalho para.

Os valores válidos são:

  • Never (predefinição)
  • Always
  • OnFailure
Exemplo
assertion.submods.container.restart_policy == "Never"

Afirmações de VMs

Afirmação Tipo Descrição

assertion.google_service_accounts

Interage com:

 Matriz de strings

Verifica se uma conta de serviço especificada está ligada à VM que executa a carga de trabalho ou se foi listada através de tee-impersonate-service-accounts nos metadados da VM.

Exemplo
workload-service-account@my-project.iam.gserviceaccount.com in assertion.google_service_accounts
assertion.hwmodel String

Valida a tecnologia de computação confidencial subjacente. As plataformas suportadas são as seguintes:

  • GCP_AMD_SEV
  • INTEL_TDX
Exemplo
assertion.hwmodel == "GCP_AMD_SEV"

assertion.submods.confidential_space.monitoring_enabled

Interage com:

 Booleano

Valida o estado de monitorização na entidade de atestação.

Exemplo
assertion.submods.confidential_space.monitoring_enabled.memory == true
assertion.submods.gce.instance_id String

Valida o ID da instância de VM.

Exemplo
assertion.submods.gce.instance_id == "0000000000000000000"
assertion.submods.gce.instance_name String

Valida o nome da instância de VM.

Exemplo
assertion.submods.gce.instance_name == "workload-vm"
assertion.submods.gce.project_id String

Verifica se a VM está a executar um Google Cloud projeto com o ID do projeto especificado.

Exemplo
assertion.submods.gce.project_id == "project-id"
assertion.submods.gce.project_number String

Verifica se a VM está a ser executada num Google Cloud projeto com o número do projeto especificado.

Exemplo
assertion.submods.gce.project_number == "00000000000"

assertion.submods.gce.zone

Interage com:

  • Operador de carga de trabalho: o valor --zone .
 String

Verifica se a VM está a ser executada na zona especificada.

Exemplo
assertion.submods.gce.zone == "us-central1-a"

assertion.submods.nvidia_gpu.cc_mode

Interage com:

 String definida

Valida o estado do controlador de computação confidencial da NVIDIA. Os valores válidos são:

  • OFF: nenhuma das funcionalidades de computação confidencial da NVIDIA está ativa.
  • ON: o hardware, o firmware e o software NVIDIA H100 ativaram totalmente as funcionalidades de computação confidencial.
  • DEVTOOLS: a GPU está num modo de computação confidencial parcial que corresponde aos fluxos de trabalho do modo ON, mas desativa as proteções de segurança.
Exemplo
assertion.submods.nvidia_gpu.cc_mode == "ON"