Arbeitslasten bereitstellen

Arbeitslastoperator

---

Ein Arbeitslastbearbeiter kann einer Confidential Space-Arbeitslast-VM Optionen übergeben, um ihr Verhalten vor der Ausführung zu bestimmen. Für einige Flags gibt es erforderliche Werte, die sich nicht ändern. Sie müssen jedoch die folgenden Auswahlmöglichkeiten treffen:

• Ob die VM auf einem Produktions- oder Debugging-Image für Confidential Space basieren soll.

• Ob die AMD SEV- oder die Intel TDX-Technologie für vertrauliches Computing verwendet werden soll.

• Welche VM-Metadatenvariablen übergeben werden müssen, einschließlich Details wie das zu verwendende Arbeitslastcontainer-Image, ob Protokolle in Cloud Logging ausgegeben werden sollen und welche Umgebungsvariablen festgelegt werden sollen.

• Welches Dienstkonto der VM zugewiesen werden soll, um die Arbeitslast auszuführen, und welche Berechtigungen es benötigt, um auf vertrauliche Daten in anderen Projekten zuzugreifen und die Ergebnisse irgendwo zu speichern.

• Die Zone, in der die VM-Instanz ausgeführt werden soll.

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 namens 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 die Compute Engine beim Erstellen einer Confidential VM-Instanz verwenden soll. Ersetzen Sie CONFIDENTIAL_COMPUTING_TECHNOLOGY durch einen der folgenden Werte: SEV TDX (Vorschau) Die Confidential Computing-Technologie muss mit der von Ihnen ausgewählten Image-Familie übereinstimmen.
--machine-type	Optional. Gibt den Namen eines Confidential VM-Maschinentyps an. Eine Liste der Maschinentypen, die AMD SEV und Intel TDX (Vorabversion) unterstützen, finden Sie unter Unterstützte Konfigurationen.
--maintenance-policy	Legen Sie für N2D-Maschinentypen, die SEV verwenden, MIGRATE fest, um die Live-Migration zu unterstützen. Bei allen anderen Maschinentypen muss dieser Wert auf TERMINATE festgelegt werden, da sie die Live-Migration nicht unterstützen.
--shielded-secure-boot	Erforderlich. Hiermit wird der Compute Engine mitgeteilt, Secure Boot für die Instanz zu verwenden.
--image-project=confidential-space-images	Erforderlich. Hiermit wird die Compute Engine angewiesen, im Projekt confidential-space-images nach dem Image für Confidential Space zu suchen.
--image-family	Erforderlich. Hiermit wird die Compute Engine angewiesen, das neueste Image für Confidential Space zu verwenden, das Teil des Projekts confidential-space-images ist. Wenn Sie ein Produktions-Image mit Ihrer endgültigen Arbeitslast verwenden möchten, bei der vertrauliche Daten verarbeitet werden, ersetzen Sie IMAGE_FAMILY durch einen der folgenden Werte: confidential-space – für AMD SEV confidential-space-preview-tdx – für Intel TDX (Vorabversion) Wenn Sie das Debug-Image für das Monitoring und Debugging verwenden möchten, ersetzen Sie IMAGE_FAMILY durch einen der folgenden Werte: confidential-space-debug – für AMD SEV confidential-space-debug-preview-tdx – für Intel TDX (Vorabversion) Die verwendete Image-Familie muss mit der ausgewählten Confidential Computing-Technologie übereinstimmen.
--metadata	Erforderlich. Ändert das Verhalten der Confidential Space-VM, indem Variablen übergeben werden. 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 Metadatenvariablen.
--service-account	Optional. Das Dienstkonto, das mit der VM-Instanz verknüpft ist, auf der die Arbeitslast ausgeführt wird, und sich als Dienstkonten ausgibt, die mit Identitätspools für Arbeitslasten in anderen Projekten verknüpft 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: Confidential VM Certificate Authority Service

Angehängtes Dienstkonto

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

• mit den folgenden Rollen:

  • roles/confidentialcomputing.workloadUser, um ein Attestierungstoken zu generieren.

  • roles/artifactregistry.reader, um ein in der Artifact Registry gespeichertes Arbeitslast-Container-Image abzurufen.

  • roles/logging.logWriter, wenn Sie STDOUT und STDERR an Cloud Logging weiterleiten möchten.

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

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

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

• Mitbearbeiter für Daten müssen dem Anbieter ihres Workload Identity-Pools das Dienstkonto 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 zu übernehmen. So kann er sie an eine Arbeitslast-VM anhängen, damit sie die Arbeitslast ausführen kann.

Metadatenvariablen

Sie können das Verhalten der Confidential Space-VM für Arbeitslasten ä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 Wert --metadata das Präfix ^~^ 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 Metadatenvariablen aufgeführt, die Sie für Ihre Arbeitslast-VM festlegen können.

Hinweis :Einige Metadatenvariablen können von Startrichtlinien beeinflusst werden, die von den Autoren der Arbeitslast festgelegt wurden.

Metadatenschlüssel	Typ	Beschreibung und Werte
tee-image-reference Interagiert mit: Datenbearbeiter: Die container.image_id Aussage.	String	Erforderlich. Dieser verweist auf den Speicherort des Arbeitslastcontainers. Beispiel tee-image-reference=us-docker.pkg.dev/WORKLOAD_AUTHOR_PROJECT_ID/REPOSITORY_NAME/WORKLOAD_CONTAINER_NAME:latest
tee-cmd Interagiert mit: Autor der Arbeitslast: Die allow_cmd_override Einführungsrichtlinie. Datenbearbeiter: Die Aussage container.cmd_override	JSON-Strings-Array	Überschreibt die CMD-Anweisungen, die in der Dockerfile des Arbeitslastcontainers angegeben sind. Beispiel tee-cmd="[\"params1\", \"params2\"]"
tee-container-log-redirect Interagiert mit: Autor der Arbeitslast: Die log_redirect Einführungsrichtlinie.	Definierter String	Gibt STDOUT und STDERR aus dem Arbeitslastcontainer in Cloud Logging oder in der seriellen Konsole aus, unter dem Feld confidential-space-launcher. Gültige Werte: false: (Standard) Es erfolgt keine Protokollierung. true: werden an die serielle Konsole und Cloud Logging ausgegeben. cloud_logging: Ausgabe nur in Cloud Logging. serial: Ausgabe nur an die serielle Konsole. Ein hohes Protokollvolumen in der seriellen Konsole kann sich auf die Arbeitslastleistung auswirken. Beispiel tee-container-log-redirect=true
tee-dev-shm-size-kb	Ganzzahl	Hiermit wird die Größe des gemeinsamen Arbeitsspeichers von /dev/shm in KB festgelegt. Beispiel tee-dev-shm-size-kb=65536
tee-env-ENVIRONMENT_VARIABLE_NAME Interagiert mit: Datenmitbearbeiter: Die container.env und container.env_override Behauptungen.	String	Hiermit werden Umgebungsvariablen im Arbeitslastcontainer festgelegt. Der Autor der Arbeitslast muss die Namen der Umgebungsvariablen auch der allow_env_override -Richtlinie für den Start 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: Datenbearbeiter: Die Aussage google_service_accounts	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: Datenbearbeiter: Die instance_memory_monitoring_enabled Behauptung. Autor der Arbeitslast: Die monitoring_memory_allow Einführungsrichtlinie.	Boolesch	Die Standardeinstellung ist false. Wenn true festgelegt ist, wird die Überwachung der Arbeitsspeichernutzung aktiviert. Die von der Confidential VM erfassten Messwerte sind vom 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: Autor der Arbeitslast: Die allow_mount_destinations Einführungsrichtlinie.	String	Eine Liste von durch Semikolons getrennten Bereitstellungsdefinitionen. Eine Bereitstellungsdefinition 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: Datenbearbeiter: Die container.restart_policy Aussage.	Definierter String	Die Neustart-Richtlinie des Container-Launchers, wenn die Arbeitslast beendet wird Gültige Werte: Never (Standard) Always OnFailure Diese Variable wird nur vom Produktions-Image für Confidential Space unterstützt. Beispiel tee-restart-policy=OnFailure
tee-signed-image-repos Interagiert mit: Datenbearbeiter: Die Aussage container.image_signatures	String	Eine Liste von durch Kommas getrennten Container-Repositories, in denen die Signaturen gespeichert werden, die von Sigstore Cosign generiert 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 Produktionsarbeitslasten in Confidential Space finden Sie unter Verwaltete Instanzgruppen.