Uma carga de trabalho é criada por um autor e processa os dados confidenciais com que os colaboradores de dados querem trabalhar.
Um autor de carga de trabalho precisa reunir os seguintes recursos para criar uma carga de trabalho:
Um aplicativo para processar os dados confidenciais. Você pode escrever seu aplicativo em qualquer linguagem, desde que crie uma imagem conteinerizada que ofereça suporte a ela.
Uma imagem conteinerizada para empacotar o aplicativo usando o Docker.
Um repositório no Artifact Registry para armazenar a imagem do Docker.
Políticas de lançamento definidas na imagem do contêiner que controlam como uma carga de trabalho pode ser executada e restringem a capacidade de um operador mal-intencionado.
Para implantar a carga de trabalho, uma VM confidencial é executada por um operador de carga de trabalho com base na imagem do Confidential Space. Isso recupera a imagem conteinerizada do Artifact Registry e a executa.
Os colaboradores de dados precisam validar os atestados de uma carga de trabalho antes que ela possa acessar os dados.
Antes de começar
Escrever uma carga de trabalho para o Confidential Space é mais do que apenas código e depuração. Você também precisa conversar com os colaboradores de dados para avaliar as necessidades deles, configurar seu ambiente, empacotar o código em uma imagem conteinerizada e trabalhar com um operador de carga de trabalho para garantir que tudo seja implantado corretamente.
Converse com os colaboradores de dados
Antes de começar a escrever seu aplicativo, você precisa conversar com os colaboradores de dados sobre os dados particulares em que eles querem que você trabalhe. As perguntas que você pode fazer incluem o seguinte:
Quais são os IDs da organização envolvidos?
Quais são os números de projetos envolvidos?
Quais são os Google Cloud recursos que preciso acessar e quais são os IDs e nomes deles?
Há recursos que preciso acessar que não são gerenciados pelo Google Cloud IAM?
Qual serviço de atestado você quer usar, o Google Cloud Attestation ou o Intel Trust Authority?
Como o aplicativo deve comparar e processar os dados particulares?
Qual formato a saída deve ter?
Onde a saída deve ser armazenada e ela precisa ser criptografada?
Todos os colaboradores de dados estão vendo o mesmo resultado ou as saídas são exclusivas para cada um?
Além disso, cada colaborador de dados também pode ter normas de privacidade exclusivas que você precisa atender. É fundamental que nenhum dado particular seja exposto como resultado de uma carga de trabalho.
Crie sua solução do Confidential Space
É útil configurar dois ou mais projetos com as permissões adequadas como um ambiente de teste, como em Criar seu primeiro ambiente do Confidential Space. Tente espelhar as configurações de projeto dos colaboradores de dados da melhor maneira possível. Isso permite que você ganhe experiência com permissões entre projetos e recupere os dados necessários de recursos específicos. Google Cloud Ele também pode dar uma ideia das funções e responsabilidades do operador de carga de trabalho e do colaborador de dados
Durante a fase inicial de criação, é útil observar as seguintes práticas:
Ao trabalhar como colaborador de dados, mantenha a validação de atestado no mínimo para acelerar o desenvolvimento.
Ao trabalhar como operador de carga de trabalho, use a imagem de depuração do Confidential Space em vez da produção ao implantar a carga de trabalho. Isso oferece mais maneiras de solucionar problemas da carga de trabalho.
À medida que o aplicativo amadurece e o estado dele se torna mais previsível, você pode bloquear cada vez mais sua solução com validação de atestado e políticas de lançamento, e mudar para a imagem de produção do Confidential Space.
Depois de fazer com que a carga de trabalho funcione corretamente no ambiente de teste, você pode mudar para os projetos dos colaboradores de dados com recursos reais, mas dados falsos para demonstrar aos colaboradores de dados como tudo funciona. Nesse momento, você pode começar a trabalhar com um operador de carga de trabalho independente.
Quando tudo estiver funcionando e a saída for a esperada, você poderá começar a testar os dados de produção. Depois que o teste for concluído e todas as partes assinarem os resultados, a carga de trabalho estará pronta para ser colocada em produção.
Tenha cuidado com a saída
Ao testar o código, pode ser tentador depurar imprimindo em STDOUT ou STDERR. Se você fizer isso, tenha cuidado para não expor dados particulares que outras partes possam ler acessando registros. Antes que o código comece a funcionar na produção, verifique se ele não está gerando nada além do que é estritamente necessário.
O mesmo vale para a saída final. Forneça apenas um resultado final que não comprometa a privacidade e a sensibilidade dos dados originais.
Criar uma imagem conteinerizada com o Docker
Os aplicativos precisam ser empacotados em uma imagem conteinerizada criada pelo Docker, que é armazenada no Artifact Registry. Quando uma carga de trabalho é implantada, a imagem Docker é extraída do repositório do Artifact Registry pela imagem do Confidential Space, executada, e o aplicativo pode começar a trabalhar nos recursos do projeto apropriado.
Ao criar a imagem Docker, considere o seguinte:
Outros recursos do Linux
A carga de trabalho do Confidential Space é executada em um contêiner do Linux usando o containerd. Este contêiner é executado usando os recursos padrão do Linux.
Para adicionar recursos, use
tee-added-capabilities.
Limites de disco e memória
O Confidential Space redimensiona automaticamente a partição com estado do disco de inicialização quando usando tamanhos maiores de disco de inicialização. O tamanho da partição é aproximadamente o tamanho do disco de inicialização menos 5 GB.
Como parte das proteções do sistema de arquivos de integridade do Confidential Space, o Confidential Space armazena tags de integridade do disco na memória. Isso usa aproximadamente 1% de sobrecarga de memória para cada byte de disco. Por exemplo, um disco de 100 GB requer 1 GB de memória e um disco de 10 TB requer 100 GB de memória.
Mantenha os limites de memória da VM. A troca de memória está desativada nas VMs do Confidential Space, o que significa que o uso excessivo de memória pode causar uma falha na carga de trabalho. Verifique se a seleção da máquina oferece suporte ao uso da memória da carga de trabalho, além da sobrecarga de integridade do disco.
Encerramentos sem dificuldades
Quando um operador solicita o desligamento de uma VM do Confidential Space, o inicializador do Confidential Space tenta desligar a carga de trabalho sem dificuldades enviando um sinal SIGTERM. Após o recebimento, a carga de trabalho tem até 120 segundos para realizar a limpeza antes que o inicializador do Confidential Space inicie o processo de encerramento. As cargas de trabalho que não implementam o tratamento de sinal SIGTERM são encerradas imediatamente após receber o sinal.
Montagens de espaço temporário na memória
O Confidential Space oferece suporte à adição de espaços temporários na memória. Isso usa a memória disponível na VM do Confidential Space. Como o espaço temporário usa a memória da VM confidencial, ele tem as mesmas propriedades de integridade e confidencialidade da VM confidencial.
Você pode usar
tee-dev-shm-size
para aumentar o tamanho da montagem de memória compartilhada /dev/shm para a carga de trabalho.
O tamanho /dev/shm é especificado em KB.
Você pode usar
tee-mount para especificar
montagens tmpfs no contêiner em execução usando configurações separadas por ponto e vírgula.
O type e a source são sempre tmpfs. O destination é o ponto de montagem,
que interage com a
tee.launch_policy.allow_mount_destinations política de lançamento. Opcionalmente, você pode especificar o tamanho tmpfs em bytes. O tamanho padrão é 50% da memória da VM.
Portas de entrada
Por padrão, as VMs do Confidential Space operam com uma regra de firewall para bloquear todas as portas de entrada. Ao usar a versão de imagem do Confidential Space 230600 ou superior, é possível especificar as portas de entrada que devem permanecer abertas no Dockerfile ao criar a imagem da carga de trabalho.
Para abrir portas, adicione a palavra-chave EXPOSE ao seu Dockerfile, com o número da porta a ser mantida aberta e um protocolo opcional de tcp ou udp. Se você não especificar o protocolo para uma porta, ambos serão permitidos: TCP e UDP. Confira um exemplo de Dockerfile que expõe portas de entrada:
FROM alpine:latest
EXPOSE 80
EXPOSE 443/tcp
EXPOSE 81/udp
WORKDIR /test
COPY salary /test
ENTRYPOINT ["/test/salary"]
CMD []
Dependendo da imagem de base usada, algumas portas já podem estar expostas. O Dockerfile só expõe outras portas. Ele não pode bloquear portas que já foram abertas pela imagem de base.
Os operadores de carga de trabalho precisam garantir que as portas expostas estejam abertas no firewall da VPC antes de executar a carga de trabalho. Os números de porta podem ser fornecidos pelo autor da carga de trabalho ou extraídos das informações da imagem Docker.
As portas expostas são registradas no console e redirecionadas para o Cloud Logging
ao usar a
tee-container-log-redirect
variável de metadados.
Políticas de lançamento
As políticas de lançamento substituem as variáveis de metadados da VM definidas pelos operadores de carga de trabalho para restringir ações maliciosas. Um autor de carga de trabalho pode definir políticas com um rótulo como parte da criação da imagem do contêiner.
Por exemplo, em um Dockerfile:
LABEL "tee.launch_policy.allow_cmd_override"="true"
Em um arquivo BUILD do Bazel:
container_image(
...
labels={"tee.launch_policy.allow_cmd_override":"true"}
...
)
As políticas de lançamento disponíveis estão na seguinte tabela:
| Política | Tipo | Descrição |
|---|---|---|
|
Interage com :
|
Booleano (o padrão é false) |
Determina se o operador de carga de trabalho pode adicionar outros recursos do Linux ao contêiner de carga de trabalho. |
|
Interage com :
|
Booleano (o padrão é false) |
Determina se o contêiner de carga de trabalho pode incluir uma montagem de cgroup com namespace
em /sys/fs/cgroup.
|
|
Interage com :
|
Booleano (o padrão é false) |
Determina se o
CMD
especificado no contêiner de carga de trabalho Dockerfile pode ser
substituído por um operador de carga de trabalho com o
tee-cmd
valor de metadados.
|
|
Interage com :
|
String separada por vírgulas |
Uma string separada por vírgulas de nomes de variável de ambiente permitidos que
são permitidos serem definidos por um operador de carga de trabalho com
tee-env-ENVIRONMENT_VARIABLE_NAME
valores de metadados.
|
|
Interage com : |
String separada por dois pontos |
Uma string separada por dois pontos de diretórios de montagem permitidos que o operador de carga de trabalho
pode montar usando Por exemplo: |
|
Interage com :
|
String definida |
Determina como a geração de registros funciona se
Os valores válidos são os seguintes:
|
|
Interage com :
|
String definida |
Determina como o monitoramento do uso de memória da carga de trabalho funciona se
Os valores válidos são os seguintes:
|
Várias execuções de carga de trabalho
Para executar uma carga de trabalho novamente, o operador de carga de trabalho precisa reiniciar a instância da VM. Isso inicia a carga de trabalho no ambiente mais limpo possível e criptografa o disco da instância da VM com uma nova chave temporária.
A reinicialização aborda o vetor de ataque da modificação de uma imagem de carga de trabalho no disco após o download e a medição. No entanto, isso também adiciona sobrecargas, como tempo de inicialização e extração da imagem da carga de trabalho a cada execução da carga de trabalho. Se essas sobrecargas afetarem muito o desempenho da carga de trabalho, é possível codificar uma reinicialização para a própria carga de trabalho ao custo de aumentar seu perfil de risco.
Cgroups com namespace
A carga de trabalho do Confidential Space é executada sem uma montagem de cgroup por padrão.
Para gerenciar cgroups no contêiner de carga de trabalho, use
tee-cgroup-ns. Essa chave de metadados instrui a instância da VM a criar uma montagem em /sys/fs/cgroup no sistema de arquivos do contêiner.
Imagens de contêiner reproduzíveis
Criar uma imagem do contêiner de maneira reproduzível pode ajudar a aumentar a confiança entre as partes. É possível criar imagens reproduzíveis com o Bazel.
Recursos não gerenciados pelo Google Cloud IAM
Para acessar recursos não gerenciados pelo Google Cloud IAM, a carga de trabalho precisa especificar um público-alvo personalizado.
Para mais informações, consulte Acessar recursos não gerenciados pelo Google Cloud IAM.
Imagens de contêiner assinadas
É possível assinar uma imagem de contêiner com uma chave pública, que um colaborador de dados pode usar para atestado em vez de especificar um resumo de imagem na política de WIP.
Isso significa que os colaboradores de dados não precisam atualizar as políticas de WIP sempre que uma carga de trabalho é atualizada, e a carga de trabalho pode continuar acessando recursos protegidos sem interrupção.
Você pode usar Sigstore Cosign para
assinar a imagem do contêiner. Para que o Confidential Space busque as assinaturas, os operadores de carga de trabalho precisam adicionar as informações de assinatura à variável de metadados tee-signed-image-repos antes de implantar a carga de trabalho.
Durante a execução, as assinaturas são enviadas a um serviço de atestado para verificação. O serviço de atestado retorna um token de declarações de atestado que contém as declarações de assinatura verificadas. Confira um exemplo de declaração de assinatura:
"image_signatures": [
{
"key_id": "hexadecimal-sha256-fingerprint-public-key1",
"signature": "base64-encoded-signature",
"signature_algorithm": "RSASSA_PSS_SHA256"
},
{
"key_id": "hexadecimal-sha256-fingerprint-public-key2",
"signature": "base64-encoded-signature",
"signature_algorithm": "RSASSA_PSS_SHA256",
},
{
"key_id": "hexadecimal-sha256-fingerprint-public-key3",
"signature": "base64-encoded-signature",
"signature_algorithm": "RSASSA_PSS_SHA256",
}
]
Para configurar a assinatura da imagem do contêiner, consulte o codelab de imagem do contêiner assinada.