Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Accéder aux informations d'attestation et aux vTPM dans les nœuds Confidential GKE Node

Standard

Les charges de travail que vous exécutez sur des nœuds Confidential Google Kubernetes Engine peuvent accéder aux fonctionnalités d'intégrité et de sécurité de la plate-forme, telles que les modules vTPM (Virtual Trusted Platform Module) et les rapports d'attestation d'informatique confidentielle, et les utiliser. Ce document explique aux ingénieurs en sécurité comment rendre les modules vTPM et les appareils matériels visibles pour les charges de travail GKE afin d'effectuer des tâches telles que l'attestation à distance, le scellement des secrets et la génération de nombres aléatoires.

Vous devez déjà connaître les ressources suivantes :

La technologie d'informatique confidentielle spécifique que vous utilisez dépend du modèle de gestion des menaces et des exigences de sécurité de votre organisation. Pour en savoir plus, consultez Technologies d'informatique confidentielle.

Tâches d'informatique confidentielle

Vous pouvez accéder aux modules vTPM et matériels à partir des pods qui s'exécutent sur des nœuds Confidential GKE Node. Vous pouvez utiliser ces modules pour effectuer des opérations de chiffrement telles que le scellement des secrets ou pour l'attestation à distance. Les modules spécifiques utilisés pour ces tâches dépendent de la technologie d'informatique confidentielle utilisée par les nœuds, comme suit :

Scellement des secrets : dans toutes les technologies d'informatique confidentielle, les charges de travail peuvent utiliser le module vTPM de VM protégée comme racine de confiance pour le scellement des secrets.
Attestation à distance : les charges de travail peuvent utiliser l'un des modules suivants pour l' attestation à distance :
- AMD SEV : le module vTPM de VM protégée.
- AMD SEV-SNP : le processeur sécurisé AMD basé sur le matériel.
- Intel TDX : le module Intel TDX basé sur le matériel.
Pour en savoir plus sur le fonctionnement de l'attestation à distance dans chacune de ces technologies d'informatique confidentielle, consultez Architecture et preuves de l'attestation.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Activez l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la gcloud components update commande. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.
Remarque : Pour les installations de la gcloud CLI existantes, veillez à définir la propriété compute/region. Si vous utilisez principalement des clusters zonaux, définissez plutôt compute/zone. En définissant un emplacement par défaut, vous pouvez éviter les erreurs gcloud CLI de ce type : One of [--zone, --region] must be supplied: Please specify location. Vous devrez peut-être spécifier l'emplacement dans certaines commandes si celui de votre cluster diffère de l'emplacement par défaut que vous avez défini.

Activez les nœuds Confidential GKE Node sur un cluster ou un pool de nœuds qui répond à toutes les conditions de la section Conditions requises. Pour en savoir plus, consultez Configurer les nœuds Confidential GKE Node au niveau du cluster ou Configurer les nœuds Confidential GKE Node au niveau du pool de nœuds.

Conditions requises

Vous pouvez utiliser des nœuds Confidential GKE Node dans les conditions suivantes :

Le cluster et les pools de nœuds doivent exécuter l'une des versions suivantes, en fonction du module d'informatique confidentielle auquel vous souhaitez accéder :
- vTPMs : n'importe quelle version de GKE.
- Appareils basés sur le matériel AMD SEV-SNP : GKE version 1.33.5-gke.1350000 ou ultérieure, ou version 1.34.1-gke.2037000 ou ultérieure.
- Appareils basés sur le matériel Intel TDX : GKE version 1.33.5-gke.1697000 ou ultérieure, ou version 1.34.1-gke.2909000 ou ultérieure.
Les pools de nœuds doivent se trouver dans un emplacement Compute Engine disposant des types de machines correspondants. Pour en savoir plus sur la disponibilité régionale , consultez Types de machines, processeurs et zones.
Les nœuds doivent utiliser l'image de nœud Container-Optimized OS.

Installer le plug-in d'appareil

Pour rendre les informations d'intégrité et de sécurité visibles pour les pods GKE, vous installez un plug-in d'appareil. Pour utiliser un DaemonSet afin d'installer le plug-in, procédez comme suit :

Connectez-vous à votre cluster :
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster
- CONTROL_PLANE_LOCATION : région ou zone de votre plan de contrôle de cluster, par exemple us-central1 ou us-central1-a

Créez le DaemonSet cc-device-plugin :

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

Une fois le DaemonSet créé, tous les appareils d'informatique confidentielle de vos nœuds Confidential GKE Node deviennent visibles pour les pods qui s'exécutent sur ces nœuds.

Accéder aux appareils d'informatique confidentielle à partir des pods

Une fois le DaemonSet créé pour installer le plug-in d'appareil, vous pouvez accéder aux modules vTPM et aux appareils basés sur le matériel à partir des pods de la même manière que vous demandez d'autres ressources étendues dans Kubernetes. Les sections suivantes vous expliquent comment accéder aux modules vTPM à partir de n'importe quel pod et comment accéder aux modules basés sur le matériel dans les nœuds AMD SEV-SNP et Intel TDX.

Accéder aux modules vTPM à partir des pods

Pour accéder au module vTPM de VM protégée à partir de n'importe quel pod qui s'exécute sur des nœuds Confidential GKE Node, ajoutez l'appareil google.com/cc aux limites de ressources du conteneur. Les étapes suivantes demandent l'accès à un module vTPM dans un exemple de pod :

Enregistrez le fichier manifeste de pod suivant sous le nom 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

Créez le pod :
```
kubectl apply -f example-vtpm-pod.yaml
```
Le pod obtient l'accès à l'appareil /dev/tpmrm0.
Pour vérifier que le pod peut accéder au module vTPM, consultez les journaux du pod :
```
kubectl logs my-vtpm-pod
```
Si la sortie contient des informations sur le fichier, cela signifie que le pod peut accéder à l'appareil.

Vous pouvez interagir avec l'appareil à partir du code de votre application. Par exemple, vous pouvez utiliser la bibliothèque Go-TPM pour communiquer avec le module vTPM et effectuer des tâches telles que le scellement. Si vous utilisez AMD SEV, vous pouvez également utiliser le module vTPM pour effectuer l'attestation à distance de l'instance de Confidential VM.

Accéder aux modules basés sur le matériel à partir des pods

Si vous utilisez AMD SEV-SNP ou Intel TDX, vous pouvez également accéder aux modules basés sur le matériel correspondants dans les pods en spécifiant le sélecteur correspondant dans les limites de ressources du conteneur. Vous devez utiliser ces modules pour effectuer l'attestation à distance des nœuds qui utilisent AMD SEV-SNP et Intel TDX, car le module vTPM n'est pas la racine de confiance pour les mesures dans ces technologies.

Les étapes suivantes vous montrent comment demander l'accès au processeur sécurisé AMD ou au module Intel TDX :

Enregistrez l'un des exemples de pods suivants :

Demander des appareils 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

Demander des appareils 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

Créez le pod :
```
kubectl create -f PATH_TO_POD_MANIFEST
```
Remplacez PATH_TO_POD_MANIFEST par le chemin d'accès au fichier manifeste de pod que vous avez enregistré.

Les pods obtiennent l'accès à l'un des appareils suivants :
- /dev/sev-guest pour AMD SEV-SNP
- /dev/tdx_guest pour Intel TDX
Pour vérifier que le pod peut accéder à l'appareil, consultez les journaux du pod :
```
kubectl logs POD_NAME
```
Remplacez POD_NAME par le nom de l'exemple de pod que vous avez déployé à l'étape précédente.

Si la sortie contient des informations sur le fichier, cela signifie que le pod peut accéder à l'appareil.

Étape suivante

Découvrez comment attester à distance que les charges de travail s'exécutent sur une Confidential VM.

Accéder aux informations d'attestation et aux vTPM dans les nœuds Confidential GKE Node Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.