O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Acessar vTPMs e informações de atestado em nós confidenciais do GKE

Standard

As cargas de trabalho executadas em nós confidenciais do Google Kubernetes Engine podem acessar e usar recursos de integridade e segurança da plataforma, como módulos de plataforma confiável virtual (vTPMs) e relatórios de atestado de computação confidencial. Este documento mostra aos engenheiros de segurança como tornar os vTPMs e os dispositivos baseados em hardware visíveis para as cargas de trabalho do GKE e realizar tarefas como atestado remoto, isolamento de segredo e geração de números aleatórios.

Você já precisa conhecer os seguintes recursos:

A tecnologia específica de computação confidencial que você usa depende do modelo de ameaças e dos requisitos de segurança da sua organização. Para mais informações, consulte Tecnologias de computação confidencial.

Tarefas de Computação confidencial

É possível acessar vTPMs e módulos de hardware de pods executados em nós confidenciais do GKE. Você pode usar esses módulos para realizar operações criptográficas, como lacre secreto ou atestado remoto. Os módulos específicos usados para essas tarefas dependem da tecnologia de computação confidencial usada pelos nós, conforme abaixo:

Isolamento de segredo: em todas as tecnologias de computação confidencial, as cargas de trabalho podem usar o vTPM da VM protegida como a raiz de confiança para o isolamento de segredo.
Atestado remoto: as cargas de trabalho podem usar um dos seguintes módulos para atestado remoto:
- AMD SEV: o vTPM da VM protegida.
- AMD SEV-SNP: o processador seguro da AMD baseado em hardware.
- Intel TDX: o módulo Intel TDX baseado em hardware.
Para mais informações sobre como a comprovação remota funciona em cada uma dessas tecnologias de Computação confidencial, consulte Arquitetura e evidências do atestador.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Ative a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a Google Cloud CLI para essa tarefa, instale e inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.
Observação:em instalações prévias da CLI gcloud, defina a propriedade compute/region. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, é possível evitar erros na CLI gcloud como: One of [--zone, --region] must be supplied: Please specify location. Talvez seja necessário especificar o local em determinados comandos se o local do cluster for diferente do padrão definido.

Ative os Confidential GKE Nodes em um cluster ou pool de nós que atenda a todas as condições na seção Requisitos. Para mais informações, consulte Configurar nós confidenciais do GKE no nível do cluster ou Configurar nós confidenciais do GKE no nível do pool de nós.

Requisitos

É possível usar os Confidential GKE Nodes nas seguintes condições:

O cluster e os pools de nós precisam executar uma das seguintes versões, dependendo do módulo da Computação Confidencial que você quer acessar:
- vTPMs: qualquer versão do GKE.
- Dispositivos baseados em hardware AMD SEV-SNP: GKE versão 1.33.5-gke.1350000 e mais recente ou versão 1.34.1-gke.2037000 e mais recente.
- Dispositivos baseados em hardware Intel TDX: GKE versão 1.33.5-gke.1697000 e mais recente ou versão 1.34.1-gke.2909000 e mais recente.
Os pools de nós precisam estar em um local do Compute Engine que tenha os tipos de máquina correspondentes. Para mais informações sobre a disponibilidade regional, consulte Tipos de máquinas, CPUs e zonas.
Os nós precisam usar a imagem de nó do Container-Optimized OS.

Instalar o plug-in do dispositivo

Para tornar as informações de integridade e segurança visíveis aos pods do GKE, instale um plug-in de dispositivo. Para usar um DaemonSet e instalar o plug-in, siga estas etapas:

Conecte-se ao cluster:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION
```
Substitua:
- CLUSTER_NAME: o nome do cluster.
- CONTROL_PLANE_LOCATION: a região ou zona do plano de controle do cluster, como us-central1 ou us-central1-a.

Crie o DaemonSet cc-device-plugin:

kubectl create -f https://raw.githubusercontent.com/google/cc-device-plugin/main/manifests/cc-device-plugin.yaml

Depois de criar o DaemonSet, todos os dispositivos de computação confidencial nos nós confidenciais do GKE ficam visíveis para os pods executados nesses nós.

Acessar dispositivos de Computação confidencial de pods

Depois de criar o DaemonSet para instalar o plug-in de dispositivo, é possível acessar vTPMs e dispositivos baseados em hardware de pods da mesma forma que você solicita outros recursos estendidos no Kubernetes. As seções a seguir mostram como acessar vTPMs de qualquer pod e como acessar módulos baseados em hardware em nós AMD SEV-SNP e Intel TDX.

Acessar vTPMs de pods

Para acessar o vTPM da VM protegida de qualquer pod executado em nós confidenciais do GKE, adicione o dispositivo google.com/cc aos limites de recursos do contêiner. As etapas a seguir solicitam acesso a um vTPM em um pod de exemplo:

Salve o seguinte manifesto de pod como example-vtpm-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
name: my-vtpm-pod
spec:
containers:
- name: test-vtpm
  image: ubuntu
  command: ["/bin/sh", "-c", "ls -l /dev/tpmrm0; sleep 3600"]
  ports:
  - containerPort: 8080
    name: http
  resources:
    limits:
      google.com/cc: 1

Crie o pod:
```
kubectl apply -f example-vtpm-pod.yaml
```
O pod recebe acesso ao dispositivo /dev/tpmrm0.
Para verificar se o pod pode acessar o vTPM, confira os registros dele:
```
kubectl logs my-vtpm-pod
```
Se a saída contiver informações de arquivo, o pod poderá acessar o dispositivo.

Você pode interagir com o dispositivo no código do aplicativo. Por exemplo, você pode usar a biblioteca Go-TPM para se comunicar com o vTPM e realizar tarefas como lacrar. Se você usa o SEV AMD, também é possível usar o vTPM para realizar o atestado remoto da instância de VM confidencial.

Acessar módulos baseados em hardware de pods

Se você usa AMD SEV-SNP ou Intel TDX, também é possível acessar os módulos correspondentes baseados em hardware em pods especificando o seletor correspondente nos limites de recursos do contêiner. É necessário usar esses módulos para realizar a atestação remota de nós que usam AMD SEV-SNP e Intel TDX, porque o vTPM não é a raiz de confiança para medições nessas tecnologias.

As etapas a seguir mostram como solicitar acesso ao AMD Secure Processor ou ao módulo Intel TDX:

Salve um dos seguintes pods de exemplo:

Solicitar dispositivos AMD SEV-SNP:

apiVersion: v1
kind: Pod
metadata:
  name: snp-test-pod
spec:
  containers:
  - name: test-container
    image: alpine
    command: ["/bin/sh", "-c"]
    args:
      - |
        echo "Checking for SEV-SNP device..."
        ls -l /dev/sev-guest
        echo "SNP container started successfully"
        sleep 3600
    resources:
      limits:
        amd.com/sev-snp: "1"
      requests:
        amd.com/sev-snp: "1"
  nodeSelector:
    cloud.google.com/gke-confidential-nodes-instance-type: SEV_SNP

Solicitar dispositivos Intel TDX:

apiVersion: v1
kind: Pod
metadata:
  name: tdx-test-pod
spec:
  containers:
  - name: test-container
    image: alpine
    command: ["/bin/sh", "-c"]
    args:
      - |
        echo "Checking for TDX device..."
        ls -l /dev/tdx*
        echo "TDX container started successfully"
        sleep 3600
    resources:
      limits:
        intel.com/tdx: "1"
      requests:
        intel.com/tdx: "1"
  nodeSelector:
    cloud.google.com/gke-confidential-nodes-instance-type: TDX

Crie o pod:
```
kubectl create -f PATH_TO_POD_MANIFEST
```
Substitua PATH_TO_POD_MANIFEST pelo caminho para o arquivo de manifesto do pod que você salvou.

Os pods têm acesso a um dos seguintes dispositivos:
- /dev/sev-guest para AMD SEV-SNP.
- /dev/tdx_guest para Intel TDX.
Para verificar se o pod pode acessar o dispositivo, confira os registros dele:
```
kubectl logs POD_NAME
```
Substitua POD_NAME pelo nome do pod de exemplo que você implantou na etapa anterior.

Se a saída contiver informações de arquivo, o pod poderá acessar o dispositivo.

A seguir

Saiba como atestar remotamente que as cargas de trabalho estão sendo executadas em VM confidencial.