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

Padrão

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 dispositivos baseados em hardware visíveis para cargas de trabalho do GKE para realizar tarefas como atestado remoto, isolamento de segredo e geração de números aleatórios.

Você já precisa estar familiarizado com os seguintes recursos:

A tecnologia de computação confidencial específica que você usa depende do modelo de ameaça 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 em pods executados em nós confidenciais do GKE. Você pode usar esses módulos para realizar operações criptográficas, como isolamento de segredo ou atestado remoto. Os módulos específicos usados para essas tarefas dependem da tecnologia de computação confidencial usada pelos nós, conforme mostrado 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 AMD baseado em hardware.
- Intel TDX: o módulo Intel TDX baseado em hardware.
Para mais informações sobre como o atestado remoto 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:

Ativar a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, 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: Para instalações prévias da CLI gcloud, defina a compute/region propriedade. 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 nós confidenciais do GKE 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 de 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 do nó do SO otimizado por contêiner.

Instalar o plug-in do dispositivo

Para tornar as informações de integridade e segurança visíveis para os pods do GKE, instale um plug-in de dispositivo. Para usar um DaemonSet para 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 do dispositivo, é possível acessar vTPMs e dispositivos baseados em hardware de pods de maneira semelhante a como 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 do pod:
```
kubectl logs my-vtpm-pod
```
Se a saída contiver informações do arquivo, o pod poderá acessar o dispositivo.

É possível 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 isolamento. Se você usar o AMD SEV, também poderá usar o vTPM para realizar o atestado remoto da instância da VM confidencial.

Acessar módulos baseados em hardware de pods

Se você usar o AMD SEV-SNP ou o Intel TDX, também poderá acessar os módulos baseados em hardware correspondentes em pods especificando o seletor correspondente nos limites de recursos do contêiner. É necessário usar esses módulos para realizar o atestado remoto 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 processador seguro AMD 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 salvo.

Os pods recebem 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 do pod:
```
kubectl logs POD_NAME
```
Substitua POD_NAME pelo nome do pod de exemplo implantado na etapa anterior.

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

A seguir

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