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 les 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 Modules) et les rapports d'attestation de l'informatique confidentielle, et les utiliser. Ce document explique aux ingénieurs en sécurité comment rendre les 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 menace 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 les nœuds Confidential GKE Node. Vous pouvez utiliser ces modules pour effectuer des opérations de chiffrement telles que le scellage de 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 des VM protégées 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 : vTPM de la VM protégée.
- AMD SEV-SNP : processeur AMD sécurisé basé sur le matériel.
- Intel TDX : 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

Pour 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 commande gcloud components update. 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 remplit toutes les conditions de la section Conditions requises. Pour en savoir plus, consultez Configurer les nœuds Confidential GKE au niveau du cluster ou Configurer les nœuds Confidential GKE 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 : toute 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 et versions ultérieures, ou version 1.34.1-gke.2909000 et versions ultérieures.
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, CPU et zones.
Les nœuds doivent utiliser l'image de nœud Container-Optimized OS.

Installer le plug-in de l'appareil

Pour rendre les informations sur l'intégrité et la sécurité visibles par les pods GKE, vous devez installer un plug-in de périphérique. 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 du plan de contrôle de votre 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 depuis des pods

Une fois que vous avez créé le DaemonSet pour installer le plug-in de l'appareil, vous pouvez accéder aux vTPM et aux appareils matériels à 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 vTPM depuis n'importe quel pod et comment accéder aux modules matériels dans les nœuds AMD SEV-SNP et Intel TDX.

Accéder aux vTPM depuis les pods

Pour accéder au vTPM de la VM protégée depuis n'importe quel pod exécuté sur des nœuds GKE confidentiels, ajoutez l'appareil google.com/cc aux limites de ressources du conteneur. Les étapes suivantes demandent l'accès à un 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 a accès à l'appareil /dev/tpmrm0.
Pour vérifier que le pod peut accéder au vTPM, consultez les journaux du pod :
```
kubectl logs my-vtpm-pod
```
Si le résultat 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 vTPM et effectuer des tâches telles que le scellement. Si vous utilisez AMD SEV, vous pouvez également utiliser le vTPM pour effectuer une attestation à distance de l'instance Confidential VM.

Accéder aux modules matériels depuis les pods

Si vous utilisez AMD SEV-SNP ou Intel TDX, vous pouvez également accéder aux modules matériels 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 vTPM n'est pas la racine de confiance pour les mesures dans ces technologies.

Les étapes suivantes vous expliquent comment demander l'accès au module AMD Secure Processor ou 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 du pod que vous avez enregistré.

Les pods ont 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 du pod exemple que vous avez déployé à l'étape précédente.

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

Étapes suivantes

Découvrez comment attester à distance que les charges de travail s'exécutent sur 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.