Arbeitslasten bereitstellen

Ein Arbeitslastoperator kann Optionen an eine Confidential Space-Arbeitslast-VM übergeben, um ihr Verhalten vor der Ausführung zu bestimmen. Einige Flags haben erforderliche Werte, die sich nicht ändern. Sie müssen jedoch die folgenden Entscheidungen treffen:

Im folgenden Beispiel wird eine Confidential VM in der Zone us-west1-b basierend auf dem neuesten Produktions-Image für Confidential Space erstellt und ein Docker-Container mit dem Namen WORKLOAD_CONTAINER_NAME ausgeführt:

gcloud compute instances create workload-vm-name \
    --confidential-compute-type=CONFIDENTIAL_COMPUTING_TECHNOLOGY \
    --machine-type=MACHINE_TYPE_NAME \
    --maintenance-policy=MAINTENANCE_POLICY \
    --shielded-secure-boot \
    --image-project=confidential-space-images \
    --image-family=IMAGE_FAMILY \
    --metadata="^~^tee-image-reference=us-docker.pkg.dev/WORKLOAD_AUTHOR_PROJECT_ID/REPOSITORY_NAME/WORKLOAD_CONTAINER_NAME:latest" \
    --service-account=WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_OPERATOR_PROJECT_ID.iam.gserviceaccount.com \
    --scopes=cloud-platform \
    --zone=us-west1-b

Die in diesem Beispiel verwendeten Optionen werden in der folgenden Tabelle beschrieben.

Flag Beschreibung
--confidential-compute-type

Erforderlich. Gibt an, welche Confidential Computing-Technologie Compute Engine beim Erstellen einer Confidential VM-Instanz verwenden soll.

Ersetzen Sie CONFIDENTIAL_COMPUTING_TECHNOLOGY durch einen der folgenden Werte:

  • SEV
  • TDX

Die Confidential Computing-Technologie sollte mit der von Ihnen ausgewählten Image-Familie übereinstimmen.

--machine-type Optional. Gibt einen Namen für den Maschinentyp einer Confidential VM an. Informationen zu den Maschinentypen, die AMD SEV und Intel TDX unterstützen, finden Sie unter Unterstützte Konfigurationen.
--maintenance-policy Legen Sie für N2D-Maschinentypen, die SEV verwenden, diesen Wert auf MIGRATE fest, um die Live-Migration zu unterstützen. Legen Sie diesen Wert für alle anderen Maschinentypen auf TERMINATE fest, da sie keine Live-Migration unterstützen.
--shielded-secure-boot Erforderlich. Weist Compute Engine an, Secure Boot für die Instanz zu verwenden.
--image-project=confidential-space-images Erforderlich. Weist Compute Engine an, im Projekt confidential-space-images nach dem Confidential Space-Image zu suchen.

--image-family

Erforderlich. Weist Compute Engine an, das neueste Confidential Space-Image zu verwenden, das Teil des Projekts confidential-space-images ist.

Wenn Sie ein Produktionsimage für Ihre endgültige Arbeitslast verwenden möchten, mit der vertrauliche Daten verarbeitet werden, ersetzen Sie IMAGE_FAMILY durch confidential-space.

Wenn Sie das Debug-Image für Monitoring und Debugging verwenden möchten, ersetzen Sie IMAGE_FAMILY durch confidential-space-debug.

Die von Ihnen verwendete Image-Familie muss mit der von Ihnen ausgewählten Confidential Computing-Technologie übereinstimmen.

--metadata

Erforderlich. Ändert das Verhalten der Confidential Space-VM durch Übergeben von Variablen. Der tee-image-reference-Schlüssel und -Wert sind erforderlich und weisen die VM-Instanz an, den angegebenen Docker-Container auf dem angegebenen Confidential Space-Image auszuführen.

Die verfügbaren Schlüssel/Wert-Paare finden Sie unter Metadatavariablen.

--service-account Optional. Das Dienstkonto, das an die VM-Instanz angehängt ist, auf der die Arbeitslast ausgeführt wird, und das Dienstkonten imitiert, die an Arbeitslastidentitätspools in anderen Projekten angehängt sind. Wenn nicht angegeben, wird das Compute Engine-Standarddienstkonto verwendet.
--scopes=cloud-platform Erforderlich. Legt den Zugriffsbereich fest. Der cloud-platform-Bereich ist ein OAuth-Bereich für die meisten Google Cloud Dienste und ermöglicht der VM die Kommunikation mit dem Attestierungsprüfer.
--zone

Erforderlich. Die Zone, in der die VM-Instanz ausgeführt wird. Für Confidential Space sind die folgenden Dienste erforderlich, die an bestimmten Standorten verfügbar sind:

Angehängtes Dienstkonto

Ein Dienstkonto muss an die Confidential VM einer Arbeitslast angehängt werden, damit die Arbeitslast ausgeführt werden kann. Das Dienstkonto muss so eingerichtet sein:

  • Mit den folgenden Rollen:

  • Mit Lesezugriff auf den Speicherort, an dem die Datenmitwirkenden ihre vertraulichen Daten speichern, z. B. ein Cloud Storage-Bucket oder eine BigQuery-Tabelle.

  • Schreibzugriff auf den Ort, an dem die Arbeitslast die Daten ausgeben soll, z. B. ein Cloud Storage-Bucket. Mitbearbeiter von Daten sollten Lesezugriff auf diesen Speicherort haben.

Außerdem müssen Datenmitbearbeiter und Arbeitslastbetreiber Folgendes einrichten:

  • Datenmitarbeiter müssen das Dienstkonto ihrem Workload Identity-Pool-Anbieter als Attributbedingung hinzufügen:

    'WORKLOAD_SERVICE_ACCOUNT_NAME@DATA_COLLABORATOR_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts

  • Der Arbeitslastoperator benötigt die Rolle roles/iam.serviceAccountUser, um die Identität des Dienstkontos übernehmen zu können. So können sie sie an eine Arbeitslast-VM anhängen, damit die Arbeitslast ausgeführt werden kann.

Metadatavariablen

Sie können das Verhalten der Confidential Space-Arbeitslast-VM ändern, indem Sie beim Erstellen der VM Variablen an die Option --metadata übergeben.

Wenn Sie mehrere Variablen übergeben möchten, legen Sie zuerst das Trennzeichen fest, indem Sie dem --metadata-Wert ^~^ voranstellen. Dadurch wird das Trennzeichen auf ~ festgelegt, da , in Variablenwerten verwendet wird.

Beispiel:

metadata="^~^tee-restart-policy=Always~tee-image-reference=us-docker.pkg.dev/WORKLOAD_AUTHOR_PROJECT_ID/REPOSITORY_NAME/WORKLOAD_CONTAINER_NAME:latest"

In der folgenden Tabelle sind die Metadatavariablen aufgeführt, die Sie für Ihre Arbeitslast-VM festlegen können.

Metadatenschlüssel Typ Beschreibung und Werte

tee-image-reference

Interagiert mit:

 String

Erforderlich. Dies verweist auf den Speicherort des Arbeitslast-Containers.

Beispiel
tee-image-reference=us-docker.pkg.dev/WORKLOAD_AUTHOR_PROJECT_ID/REPOSITORY_NAME/WORKLOAD_CONTAINER_NAME:latest

tee-added-capabilities

Interagiert mit:

 JSON-String-Array

Fügt dem Arbeitslastcontainer zusätzliche Linux-Berechtigungen hinzu.

Beispiel
tee-added-capabilities="[\"CAP_SYS_ADMIN\", \"CAP_SYS_CHROOT\"]"

tee-cgroup-ns

Interagiert mit:

 Boolesch

Die Standardeinstellung ist false. Wenn dieser Parameter auf true gesetzt ist, wird eine Namespaced-Cgroup-Bereitstellung unter /sys/fs/cgroup aktiviert.

Beispiel
tee-cgroup-ns=true

tee-cmd

Interagiert mit:

 JSON-String-Array

Überschreibt die CMD-Anweisungen, die im Dockerfile des Arbeitslastcontainers angegeben sind.

Beispiel
tee-cmd="[\"params1\", \"params2\"]"

tee-container-log-redirect

Interagiert mit:

 Definierter String

Gibt STDOUT und STDERR aus dem Arbeitslastcontainer in Cloud Logging oder der seriellen Konsole aus, unter dem Feld confidential-space-launcher.

Die gültigen Werte sind:

  • false: (Standard) Es erfolgt kein Logging.
  • true: Ausgaben an die serielle Konsole und Cloud Logging.
  • cloud_logging: Ausgabe nur in Cloud Logging.
  • serial: Nur Ausgaben an die serielle Konsole.

Ein hohes Logvolumen in der seriellen Konsole kann sich auf die Leistung der Arbeitslast auswirken.

Beispiel
tee-container-log-redirect=true

tee-dev-shm-size-kb

 Ganzzahl

Legt die Größe der Bereitstellung des gemeinsamen Arbeitsspeichers /dev/shm in kB fest.

Beispiel
tee-dev-shm-size-kb=65536

tee-env-ENVIRONMENT_VARIABLE_NAME

Interagiert mit:

 String

Legt Umgebungsvariablen im Arbeitslastcontainer fest. Der Autor der Arbeitslast muss die Namen der Umgebungsvariablen auch der allow_env_override -Startrichtlinie hinzufügen, da sie sonst nicht festgelegt werden.

Beispiel
tee-env-example-env-1='value-1'~tee-env-example-env-2='value-2'

tee-impersonate-service-accounts

Interagiert mit:

 String

Eine Liste der Dienstkonten, deren Identität vom Arbeitslastoperator übernommen werden kann. Der Arbeitslastoperator muss die Identität der Dienstkonten übernehmen dürfen.

Es können mehrere Dienstkonten durch Kommas getrennt aufgeführt werden.

Beispiel
tee-impersonate-service-accounts=SERVICE_ACCOUNT_NAME_1@WORKLOAD_OPERATOR_PROJECT_ID.iam.gserviceaccount.com,SERVICE_ACCOUNT_NAME_2@WORKLOAD_OPERATOR_PROJECT_ID.iam.gserviceaccount.com

tee-monitoring-memory-enable

Interagiert mit:

 Boolesch

Die Standardeinstellung ist false. Wenn true festgelegt ist, wird die Überwachung der Speichernutzung aktiviert. Die von der Confidential VM erfassten Messwerte haben den Typ guest/memory/bytes_used und können in Cloud Logging oder im Metrics Explorer aufgerufen werden.

Beispiel
tee-monitoring-memory-enable=true

tee-mount

Interagiert mit:

 String

Eine Liste von durch Semikolons getrennten Mount-Definitionen. Eine Mount-Definition besteht aus einer durch Kommas getrennten Liste von Schlüssel/Wert-Paaren, für die type, source und destination erforderlich sind. destination muss ein absoluter Pfad sein und type/source muss tmpfs sein.

Beispiel
type=tmpfs,source=tmpfs,destination=/tmp/tmpfs,size=12345;type=tmpfs,source=tmpfs,destination=/run/workload

tee-restart-policy

Interagiert mit:

 Definierter String

Die Neustart-Richtlinie des Container-Launchers, wenn die Arbeitslast beendet wird.

Die gültigen Werte sind:

  • Never (Standard)
  • Always
  • OnFailure

Diese Variable wird nur vom Confidential Space-Produktions-Image unterstützt.

Beispiel
tee-restart-policy=OnFailure

tee-signed-image-repos

Interagiert mit:

 String

Eine Liste durch Kommas getrennter Container-Repositories, in denen die von Sigstore Cosign generierten Signaturen gespeichert werden.

Beispiel
tee-signed-image-repos=us-docker.pkg.dev/projectA/repo/example,us-docker.pkg.dev/projectB/repo/example,us-docker.pkg.dev/projectC/repo/example

Skalierung

Informationen zur Skalierung und Hochverfügbarkeit von Confidential Space-Arbeitslasten in der Produktion finden Sie unter Verwaltete Instanzgruppen.