So werden digitale Assets mit Multi-Party Computation und Confidential Space bearbeitet

1. Übersicht

Bevor wir beginnen, ist es hilfreich, wenn Sie mit den folgenden Funktionen und Konzepten vertraut sind.

• Cloud Storage, insbesondere Buckets
• Compute Engine, insbesondere Confidential VM
• Dienstkonten
• Container und Remote-Repositories
• Identitätsföderation von Arbeitslasten und Attributbedingungen

Lerninhalte

In diesem Lab wird eine Referenzimplementierung für die MPC-konforme Blockchain-Signierung mit Confidential Space bereitgestellt. Zur Veranschaulichung der Konzepte gehen wir ein Szenario durch, in dem das Unternehmen Primus digitale Assets an das Unternehmen Secundus übertragen möchte. In diesem Szenario verwendet Company Primus ein MPC-kompatibles Modell. Das bedeutet, dass anstelle einzelner privater Schlüssel verteilte Schlüsselanteile verwendet werden. Diese Schlüsselanteile werden von mehreren Parteien gehalten, in diesem Fall von Alice und Bob. Dieser Ansatz bietet Company Primus mehrere Vorteile, darunter eine vereinfachte Nutzerfreundlichkeit, betriebliche Effizienz und Kontrolle über die privaten Schlüssel.

Um die grundlegenden Aspekte dieses Prozesses zu erläutern, gehen wir auf die technische Einrichtung ein und führen Sie durch den Genehmigungs- und Unterzeichnungsprozess, der die Übertragung digitaler Assets von Company Primus zu Company Secundus einleitet. Bitte beachten Sie, dass Bob und Alice, die beide Mitarbeiter von Company Primus sind, die Transaktion genehmigen müssen.

Diese Referenzimplementierung demonstriert zwar Signaturvorgänge, deckt aber nicht alle Aspekte der MPC-Schlüsselverwaltung ab. Wir gehen beispielsweise nicht auf die Schlüsselgenerierung ein. Außerdem gibt es alternative und ergänzende Ansätze, z. B. die Verwendung von Nicht-Google Cloud-Diensten zum Generieren von Co-Signaturen oder die Erstellung von Blockchain-Signaturen durch Co-Signer in ihren eigenen Umgebungen, was eine dezentralere Architektur darstellt. Wir hoffen, dass dieses Lab Sie zu verschiedenen Ansätzen für MPC in Google Cloud inspiriert.

Sie arbeiten mit einer einfachen Arbeitslast, die eine Ethereum-Transaktion in Confidential Space mit Co-Signer-Schlüsselmaterial signiert. Die Signierung von Ethereum-Transaktionen ist ein Prozess, bei dem ein Nutzer eine Transaktion in der Ethereum-Blockchain autorisieren kann. Wenn Sie eine Ethereum-Transaktion senden möchten, müssen Sie sie mit Ihrem privaten Schlüssel signieren. So können wir bestätigen, dass Sie der Inhaber des Kontos sind und die Transaktion autorisieren. So läuft der Signierprozess ab:

1. Der Absender erstellt ein Transaktionsobjekt, in dem die Empfängeradresse, der zu sendende ETH-Betrag und alle anderen relevanten Daten angegeben werden.
2. Der private Schlüssel des Absenders wird verwendet, um die Transaktionsdaten zu hashen.
3. Der Hash wird dann mit dem privaten Schlüssel signiert.
4. Die Signatur ist dem Transaktionsobjekt angehängt.
5. Die Transaktion wird an das Ethereum-Netzwerk übertragen.

Wenn ein Knoten im Netzwerk eine Transaktion empfängt, wird die Signatur überprüft, um sicherzustellen, dass sie vom Inhaber des Kontos signiert wurde. Wenn die Signatur gültig ist, fügt der Knoten die Transaktion der Blockchain hinzu.

Zuerst konfigurieren Sie die erforderlichen Cloud-Ressourcen. Anschließend führen Sie die Arbeitslast in Confidential Space aus. In diesem Codelab werden Sie durch die folgenden allgemeinen Schritte geführt:

• Erforderliche Cloud-Ressourcen für die Ausführung von Confidential Space konfigurieren
• So autorisieren Sie den Zugriff auf geschützte Ressourcen basierend auf den Attributen von:
• Was: Der Arbeitslastcontainer
• Wo: Die Confidential Space-Umgebung (das Confidential Space-Image auf Confidential VM)
• Wer: Das Konto, mit dem die Arbeitslast ausgeführt wird
• Arbeitslast in einer Confidential VM mit dem Confidential Space-VM-Image ausführen

Erforderliche APIs

Sie müssen die folgenden APIs in den angegebenen Projekten aktivieren, um diesen Leitfaden durcharbeiten zu können.

API-Name	API-Titel
cloudkms.googleapis.com	Cloud KMS
compute.googleapis.com	Compute Engine
confidentialcomputing.googleapis.com	Confidential Computing
iamcredentials.googleapis.com	IAM
artifactregistry.googleapis.com	Artifact Registry

2. Cloud-Ressourcen einrichten

Hinweis

• Klonen Sie dieses Repository mit dem folgenden Befehl, um die erforderlichen Skripts zu erhalten, die in diesem Codelab verwendet werden.

git clone https://github.com/GoogleCloudPlatform/confidential-space.git

• Wechseln Sie in das Verzeichnis für dieses Codelab.

cd confidential-space/codelabs/digital_asset_transaction_codelab/scripts

• Achten Sie darauf, dass Sie die erforderlichen Umgebungsvariablen für das Projekt wie unten gezeigt festgelegt haben. Weitere Informationen zum Einrichten eines GCP-Projekts finden Sie in diesem Codelab. Hier finden Sie Informationen dazu, wie Sie die Projekt-ID abrufen und wie sie sich von Projektnamen und Projektnummer unterscheidet. .

export PRIMUS_PROJECT_ID=<GCP project id>

• Aktivieren Sie die Abrechnung für Ihre Projekte.
• Aktivieren Sie die Confidential Computing API und die folgenden APIs für beide Projekte.

gcloud services enable \
   cloudapis.googleapis.com \
    cloudkms.googleapis.com \
    cloudresourcemanager.googleapis.com \
    cloudshell.googleapis.com \
    container.googleapis.com \
    containerregistry.googleapis.com \
    iam.googleapis.com \
    confidentialcomputing.googleapis.com

• Mit dem folgenden Befehl können Sie die Variablen für die Ressourcennamen festlegen. Dadurch werden die Ressourcennamen, die für Ihr GCP-Projekt für Unternehmen A spezifisch sind, überschrieben, z. B. export PRIMUS_INPUT_STORAGE_BUCKET='primus-input-bucket'.
• Die folgenden Variablen können für Ihr GCP-Projekt in Unternehmen A festgelegt werden:

$PRIMUS_INPUT_STORAGE_BUCKET	Der Bucket, in dem die verschlüsselten Schlüssel gespeichert werden.
$PRIMUS_RESULT_STORAGE_BUCKET	Der Bucket, in dem das Ergebnis der MPC-Transaktion gespeichert wird.
$PRIMUS_KEY	Der KMS-Schlüssel, der zum Verschlüsseln der in $PRIMUS_INPUT_STORAGE_BUCKET für Primus Bank gespeicherten Daten verwendet wird.
$PRIMUS_KEYRING	Der KMS-Schlüsselbund, der zum Erstellen des Verschlüsselungsschlüssels $PRIMUS_KEY für Primus Bank verwendet wird.
$PRIMUS_WIP_PROVIDER	Der Anbieter des Workload Identity-Pools, der die Attributbedingung für Tokens enthält, die vom MPC-Workload-Dienst signiert wurden.
$PRIMUS_SERVICEACCOUNT	Das Dienstkonto, das $PRIMUS_WORKLOAD_IDENTITY_POOL für den Zugriff auf die geschützten Ressourcen verwendet. Dieses Dienstkonto hat die Berechtigung, die verschlüsselten Schlüssel aufzurufen, die im Bucket „$PRIMUS_INPUT_STORAGE_BUCKET“ gespeichert sind.
$PRIMUS_ARTIFACT_REPOSITORY	Das Artefakt-Repository zum Speichern des Container-Images für die Arbeitslast.
$WORKLOAD_SERVICEACCOUNT	Das Dienstkonto, das die Berechtigung hat, auf die Confidential VM zuzugreifen, auf der die Arbeitslast ausgeführt wird.
$WORKLOAD_CONTAINER	Der Docker-Container, in dem die Arbeitslast ausgeführt wird.
$WORKLOAD_IMAGE_NAME	Der Name des Container-Images der Arbeitslast.
$WORKLOAD_IMAGE_TAG	Das Tag des Arbeitslast-Container-Images.

• Führen Sie das folgende Skript aus, um die verbleibenden Variablennamen auf Werte basierend auf Ihrer Projekt-ID für Ressourcennamen festzulegen.

source config_env.sh

Cloud-Ressourcen einrichten

In diesem Schritt richten Sie die für die Multi-Party-Berechnung erforderlichen Cloud-Ressourcen ein. In diesem Lab verwenden Sie den folgenden privaten Schlüssel: 0000000000000000000000000000000000000000000000000000000000000001

In einer Produktionsumgebung generieren Sie Ihren eigenen privaten Schlüssel. Für dieses Lab teilen wir diesen privaten Schlüssel jedoch in zwei Teile auf und verschlüsseln jeden Teil. In einer Produktionsumgebung sollten Schlüssel niemals in Klartextdateien gespeichert werden. Stattdessen kann der private Schlüssel außerhalb von Google Cloud generiert werden (oder ganz übersprungen und durch die benutzerdefinierte Erstellung von MPC-Schlüssel-Shards ersetzt werden) und dann verschlüsselt werden, sodass niemand Zugriff auf den privaten Schlüssel oder die Schlüssel-Shards hat. In diesem Lab verwenden wir die gcloud CLI.

Führen Sie das folgende Skript aus, um die erforderlichen Cloud-Ressourcen einzurichten. Im Rahmen dieser Schritte werden die unten aufgeführten Ressourcen erstellt:

• Ein Cloud Storage-Bucket ($PRIMUS_INPUT_STORAGE_BUCKET) zum Speichern der verschlüsselten privaten Schlüsselanteile.
• Ein Cloud Storage-Bucket ($PRIMUS_RESULT_STORAGE_BUCKET) zum Speichern des Ergebnisses der Transaktion für digitale Assets.
• Ein Verschlüsselungsschlüssel ($PRIMUS_KEY) und ein Schlüsselbund ($PRIMUS_KEYRING) in KMS zum Verschlüsseln der Anteile des privaten Schlüssels.
• Ein Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL) zum Validieren von Ansprüchen basierend auf Attributbedingungen, die unter dem zugehörigen Anbieter konfiguriert sind.
• Ein Dienstkonto ($PRIMUS_SERVICEACCOUNT), das dem oben genannten Workload Identity Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL) zugeordnet ist und die folgenden IAM-Zugriffsberechtigungen hat:
• roles/cloudkms.cryptoKeyDecrypter, um die Daten mit dem KMS-Schlüssel zu entschlüsseln.
• objectViewer, um Daten aus dem Cloud Storage-Bucket zu lesen.
• roles/iam.workloadIdentityUser, um dieses Dienstkonto mit dem Workload Identity-Pool zu verbinden.

./setup_resources.sh

3. Arbeitslast erstellen

Dienstkonto für Arbeitslast erstellen

Sie erstellen jetzt ein Dienstkonto für die Arbeitslast mit den erforderlichen Rollen und Berechtigungen. Führen Sie dazu das folgende Skript aus, um ein Dienstkonto für die Arbeitslast für Unternehmen A zu erstellen. Dieses Dienstkonto wird von der VM verwendet, auf der der Arbeitslast ausgeführt wird.

Das Dienstkonto für die Arbeitslast ($WORKLOAD_SERVICEACCOUNT) hat die folgenden Rollen:

• confidentialcomputing.workloadUser, um ein Attestierungstoken zu erhalten
• logging.logWriter, um Logs in Cloud Logging zu schreiben.
• objectViewer, um Daten aus dem Cloud Storage-Bucket $PRIMUS_INPUT_STORAGE_BUCKET zu lesen.
• objectUser, um das Arbeitslastergebnis in den Cloud Storage-Bucket $PRIMUS_RESULT_STORAGE_BUCKET zu schreiben.

./create_workload_service_account.sh

Arbeitslast erstellen

In diesem Schritt wird ein Docker-Image für die Arbeitslast erstellt. Der Arbeitslast in diesem Codelab ist eine einfache Node.js-MPC-Anwendung, die digitale Transaktionen zum Übertragen von Assets mit verschlüsselten privaten Schlüsselanteilen signiert. Hier finden Sie den Code für das Arbeitslastprojekt. Das Arbeitslastprojekt enthält die folgenden Dateien.

package.json::Diese Datei enthält die Liste der Pakete, die für die MPC-Anwendung für den Arbeitslasttyp verwendet werden sollen. In diesem Fall verwenden wir die Bibliotheken @google-cloud/kms, @google-cloud/storage, ethers und fast-crc32c. Hier finden Sie die Datei „package.json“, die wir für dieses Codelab verwenden.

index.js::Dies ist ein Einstiegspunkt der Arbeitslastanwendung und gibt an, welche Befehle beim Start des Arbeitslastcontainers ausgeführt werden sollen. Wir haben auch eine Beispieltransaktion ohne Signatur eingefügt, die normalerweise von einer nicht vertrauenswürdigen Anwendung bereitgestellt wird, die Nutzer nach ihrer Signatur fragt. In dieser index.js-Datei werden auch Funktionen aus mpc.js importiert, die wir als Nächstes erstellen. Unten sehen Sie den Inhalt der Datei „index.js“. Sie können ihn auch hier aufrufen.

import {signTransaction, submitTransaction, uploadFromMemory} from './mpc.js';

const signAndSubmitTransaction = async () => {
  try {
    // Create the unsigned transaction object
    const unsignedTransaction = {
      nonce: 0,
      gasLimit: 21000,
      gasPrice: '0x09184e72a000',
      to: '0x0000000000000000000000000000000000000000',
      value: '0x00',
      data: '0x',
    };

    // Sign the transaction
    const signedTransaction = await signTransaction(unsignedTransaction);

    // Submit the transaction to Ganache
    const transaction = await submitTransaction(signedTransaction);

    // Write the transaction receipt
    uploadFromMemory(transaction);

    return transaction;
  } catch (e) {
    console.log(e);
    uploadFromMemory(e);
  }
};

await signAndSubmitTransaction();

mpc.js::Hier erfolgt die Transaktionssignierung. Sie importiert Funktionen aus „kms-decrypt“ und „credential-config“, die wir als Nächstes behandeln. Unten sehen Sie den Inhalt der Datei „mpc.js“. Sie finden ihn auch hier.

import {Storage} from '@google-cloud/storage';
import {ethers} from 'ethers';

import {credentialConfig} from './credential-config.js';
import {decryptSymmetric} from './kms-decrypt.js';

const providers = ethers.providers;
const Wallet = ethers.Wallet;

// The ID of the GCS bucket holding the encrypted keys
const bucketName = process.env.KEY_BUCKET;

// Name of the encrypted key files.
const encryptedKeyFile1 = 'alice_encrypted_key_share';
const encryptedKeyFile2 = 'bob_encrypted_key_share';

// Create a new storage client with the credentials
const storageWithCreds = new Storage({
  credentials: credentialConfig,
});

// Create a new storage client without the credentials
const storage = new Storage();

const downloadIntoMemory = async (keyFile) => {
  // Downloads the file into a buffer in memory.
  const contents =
      await storageWithCreds.bucket(bucketName).file(keyFile).download();

  return contents;
};

const provider =
    new providers.JsonRpcProvider(`http://${process.env.NODE_URL}:80`);

export const signTransaction = async (unsignedTransaction) => {
  /* Check if Alice and Bob have both approved the transaction
  For this example, we're checking if their encrypted keys are available. */
  const encryptedKey1 =
      await downloadIntoMemory(encryptedKeyFile1).catch(console.error);
  const encryptedKey2 =
      await downloadIntoMemory(encryptedKeyFile2).catch(console.error);

  // For each key share, make a call to KMS to decrypt the key
  const privateKeyshare1 = await decryptSymmetric(encryptedKey1[0]);
  const privateKeyshare2 = await decryptSymmetric(encryptedKey2[0]);

  /* Perform the MPC calculations
  In this example, we're combining the private key shares
  Alternatively, you could import your mpc calculations here */
  const wallet = new Wallet(privateKeyshare1 + privateKeyshare2);

  // Sign the transaction
  const signedTransaction = await wallet.signTransaction(unsignedTransaction);

  return signedTransaction;
};

export const submitTransaction = async (signedTransaction) => {
  // This can now be sent to Ganache
  const hash = await provider.sendTransaction(signedTransaction);
  return hash;
};

export const uploadFromMemory = async (contents) => {
  // Upload the results to the bucket without service account impersonation
  await storage.bucket(process.env.RESULTS_BUCKET)
      .file('transaction_receipt_' + Date.now())
      .save(JSON.stringify(contents));
};

kms-decrypt.js:Diese Datei enthält den Code für die Entschlüsselung mit Schlüsseln, die in KMS verwaltet werden. Unten sehen Sie den Inhalt der Datei „kms-decrypt.js“. Sie können ihn auch hier aufrufen.

import {KeyManagementServiceClient} from '@google-cloud/kms';
import crc32c from 'fast-crc32c';

import {credentialConfig} from './credential-config.js';

const projectId = process.env.PRIMUS_PROJECT_ID;
const locationId = process.env.PRIMUS_LOCATION;
const keyRingId = process.env.PRIMUS_ENC_KEYRING;
const keyId = process.env.PRIMUS_ENC_KEY;

// Instantiates a client
const client = new KeyManagementServiceClient({
  credentials: credentialConfig,
});

// Build the key name
const keyName = client.cryptoKeyPath(projectId, locationId, keyRingId, keyId);

export const decryptSymmetri>c = async (ciphertext) = {
  const ciphertextCrc32c = crc32c.calculate(ciphertext);
  const [decryptResponse] = await client.decrypt({
    name: keyName,
    ciphertext,
    ciphertextCrc32c: {
      value: ciphertextCrc32c,
    },
  });

  // Optional, but recommended: perform integrity verification on
  // decryptResponse. For more details on ensuring E2E in-transit integrity to
  // and from Cloud KMS visit:
  // https://cloud.google.com/kms/docs/data-integrity-guidelines
  if (crc32c.calculate(decryptResponse.plaintext) !==
      Number(decryptResponse.plaintextCrc32c.value)) {
    throw new Error('Decrypt: response corrupted in-transit');
  }

  const plaintext = decryptResponse.plaintext.toString();

  return plaintext;
};

credential-config.js:In dieser Datei werden die Pfade des Workload Identity-Pools und Details zur Übernahme der Identität des Dienstkontos gespeichert. Hier finden Sie die Datei „credential-config.js“, die wir für dieses Codelab verwenden.

Dockerfile:Zum Schluss erstellen wir unser Dockerfile, das zum Erstellen des Docker-Images für den Arbeitslast verwendet wird. definiert das Dockerfile wie hier angegeben.

FROM node:16.18.0

ENV NODE_ENV=production

WORKDIR /app

COPY ["package.json", "package-lock.json*", "./"]

RUN npm install --production

COPY . .

LABEL "tee.launch_policy.allow_cmd_override"="true"
LABEL "tee.launch_policy.allow_env_override"="NODE_URL,RESULTS_BUCKET,KEY_BUCKET,PRIMUS_PROJECT_NUMBER,PRIMUS_PROJECT_ID,PRIMUS_WORKLOAD_IDENTITY_POOL,PRIMUS_WIP_PROVIDER,PRIMUS_SERVICEACCOUNT,PRIMUS_ENC_KEYRING,PRIMUS_ENC_KEY"

CMD [ "node", "index.js" ]

Hinweis:Das LABEL „tee.launch_policy.allow_cmd_override“=„true“ im Dockerfile ist eine vom Bildautor festgelegte Startrichtlinie. Damit kann der Operator den CMD beim Ausführen der Arbeitslast überschreiben. Standardmäßig ist „allow_cmd_override“ auf „false“ gesetzt. Das LABEL „tee.launch_policy.allow_env_override“ gibt an, welche Umgebungsvariablen Bildnutzer verwenden dürfen .

Führen Sie das folgende Skript aus, um eine Arbeitslast zu erstellen, in der die folgenden Schritte ausgeführt werden:

• Erstellen Sie Artifact Registry($PRIMUS_ARTIFACT_REPOSITORY), um das Docker-Image für die Arbeitslast zu speichern.
• Aktualisieren Sie den Arbeitslastcode mit den erforderlichen Ressourcennamen. Hier finden Sie den Arbeitslastcode, der für dieses Codelab verwendet wird.
• Erstellen Sie ein Dockerfile zum Erstellen eines Docker-Images des Arbeitslastcodes. Das Dockerfile finden Sie hier.
• Erstellen Sie das Docker-Image und veröffentlichen Sie es in der Artifact Registry ($PRIMUS_ARTIFACT_REPOSITORY), die im vorherigen Schritt erstellt wurde.
• Gewähren Sie $WORKLOAD_SERVICEACCOUNT die Leseberechtigung für $PRIMUS_ARTIFACT_REPOSITORY. Dies ist erforderlich, damit der Arbeitslastcontainer das Docker-Image der Arbeitslast aus der Artifact Registry abrufen kann.

./create_workload.sh

Blockchain-Knoten erstellen

Ganache-Ethereum-Knoten

Bevor wir die Arbeitslast autorisieren, müssen wir die Ethereum Ganache-Instanz erstellen. Die signierte Transaktion wird an diese Ganache-Instanz gesendet. Notieren Sie sich die IP-Adresse dieser Instanz. Nachdem Sie den folgenden Befehl ausgeführt haben, müssen Sie möglicherweise y eingeben, um die API zu aktivieren.

gcloud compute instances create-with-container ${ETHEREUM_NODE} \
  --zone=${PRIMUS_PROJECT_ZONE} \
  --tags=http-server \
  --project=${PRIMUS_PROJECT_ID} \
  --shielded-secure-boot \
  --shielded-vtpm \
  --shielded-integrity-monitoring \
  --container-image=docker.io/trufflesuite/ganache:v7.7.3 \
--container-arg=--wallet.accounts=\"0x0000000000000000000000000000000000000000000000000000000000000001,0x21E19E0C9BAB2400000\" \
  --container-arg=--port=80

4. Arbeitslast autorisieren und ausführen

Arbeitslast autorisieren

In diesem Schritt richten wir den Workload Identity-Poolanbieter im Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL) ein. Für die Workload Identity sind Attributbedingungen konfiguriert, wie unten dargestellt. Eine der Bedingungen besteht darin, zu prüfen, ob das Arbeitslast-Image aus dem erwarteten Artefakt-Repository abgerufen wird.

gcloud config set project $PRIMUS_PROJECT_ID

gcloud iam workload-identity-pools providers create-oidc ${PRIMUS_WIP_PROVIDER} \
 --location="${PRIMUS_PROJECT_LOCATION}" \
 --workload-identity-pool="$PRIMUS_WORKLOAD_IDENTITY_POOL" \
 --issuer-uri="https://confidentialcomputing.googleapis.com/" \
 --allowed-audiences="https://sts.googleapis.com" \
 --attribute-mapping="google.subject='assertion.sub'" \
 --attr&&ibute-condition="assertion.swname == 'CONFIDENTIAL_SPACE'&&;  'STABLE' in assertion.submods.confidential_space.support_attributes  assertion.submods.container.image_reference == '${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMU&&S_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG'  '$WORKLOAD_SERVICEACCOUNT@$PRIMUS_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts"

Arbeitslast ausführen

In diesem Abschnitt wird erläutert, wie Sie die Arbeitslast auf einer Confidential VM ausführen. Dazu übergeben wir die erforderlichen TEE-Argumente über das Metadaten-Flag. Außerdem legen wir Umgebungsvariablen für den Arbeitslastcontainer mit dem Flag „tee-env-*“ fest. Das Bild hat die folgenden Variablen:

• NODE_URL: Die URL des Ethereum-Knotens, der die signierte Transaktion verarbeitet.
• RESULTS_BUCKET: Der Bucket, in dem das Ergebnis der MPC-Transaktion gespeichert wird.
• KEY_BUCKET: Der Bucket, in dem die MPC-verschlüsselten Schlüssel gespeichert sind.
• PRIMUS_PROJECT_NUMBER: Die Projektnummer, die für die Konfigurationsdatei für Anmeldedaten verwendet wird.
• PRIMUS_PROJECT_ID: Die Projekt-ID, die für die Konfigurationsdatei für Anmeldedaten verwendet wird. Das Ergebnis der Workload-Ausführung wird in $PRIMUS_RESULT_STORAGE_BUCKET veröffentlicht.
• PRIMUS_WORKLOAD_IDENTITY_POOL: Der Workload Identity-Pool, der zum Validieren von Ansprüchen verwendet wird.
• PRIMUS_WIP_POROVIDER: Der Anbieter des Workload Identity-Pools, der die Attributbedingungen enthält, die zum Validieren von Tokens verwendet werden, die von Workloads präsentiert werden.
• WORKLOAD_SERVICEACCOUNT: Das Dienstkonto der Arbeitslast.

gcloud compute instances create $WORKLOAD_VM \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=TERMINATE \
 --scopes=cloud-platform \
 --zone=${PRIMUS_PROJECT_ZONE} \
 --project=${PRIMUS_PROJECT_ID} \
 --image-project=confidential-space-images \
 --image-family=confidential-space \
 --service-account=$WORKLOAD_SERVICEACCOUNT@$PRIMUS_PROJECT_ID.iam.gserviceaccount.com \
 --metadata "^~^tee-image-reference=${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG~tee-restart-policy=Never~tee-env-NODE_URL=$(gcloud compute instances describe ${ETHEREUM_NODE} --format='get(networkInterfaces[0].networkIP)' --zone=${PRIMUS_PROJECT_ZONE})~tee-env-RESULTS_BUCKET=$PRIMUS_RESULT_STORAGE_BUCKET~tee-env-KEY_BUCKET=$PRIMUS_INPUT_STORAGE_BUCKET~tee-env-PRIMUS_PROJECT_ID=$PRIMUS_PROJECT_ID~tee-env-PRIMUS_PROJECT_NUMBER=$(gcloud projects describe $PRIMUS_PROJECT_ID --format="value(projectNumber)")~tee-env-PRIMUS_WORKLOAD_IDENTITY_POOL=$PRIMUS_WORKLOAD_IDENTITY_POOL~tee-env-PRIMUS_PROJECT_LOCATION=${PRIMUS_PROJECT_LOCATION}~tee-env-PRIMUS_WIP_PROVIDER=$PRIMUS_WIP_PROVIDER~tee-env-PRIMUS_SERVICEACCOUNT=$PRIMUS_SERVICEACCOUNT~tee-env-PRIMUS_KEY=${PRIMUS_KEY}~tee-env-PRIMUS_KEYRING=${PRIMUS_KEYRING}"

Cloud Storage-Ergebnisse prüfen

Sie können den Transaktionsbeleg in Cloud Storage aufrufen. Es kann einige Minuten dauern, bis Confidential Space gestartet und Ergebnisse angezeigt werden. Der Container ist fertig, wenn sich die VM im Status „Beendet“ befindet.

1. Rufen Sie die Seite Cloud Storage-Browser auf.
2. Klicken Sie auf $PRIMUS_RESULT_STORAGE_BUCKET.
3. Klicken Sie auf die Datei transaction_receipt.
4. Klicken Sie auf „Herunterladen“, um die Transaktionsantwort herunterzuladen und anzusehen.

Alternativ können Sie die folgenden Befehle ausführen, um das Ergebnis aufzurufen.

gcloud config set project $PRIMUS_PROJECT_ID

gsutil cat gs://$PRIMUS_RESULT_STORAGE_BUCKET/transaction_receipt

Hinweis:Wenn keine Ergebnisse angezeigt werden, können Sie in der Compute Engine Cloud Console-Seite zur $WORKLOAD_VM wechseln und auf „Serieller Port 1 (Konsole)“ klicken, um die Logs aufzurufen.

Ganache-Blockchain-Transaktion prüfen

Sie können sich die Transaktion auch im Blockchain-Log ansehen.

1. Rufen Sie die Seite Cloud Compute Engine auf.
2. Klicken Sie auf das Dreipunkt-Menü ${ETHEREUM_NODE} VM.
3. Klicken Sie auf SSH, um das Fenster „SSH im Browser“ zu öffnen.
4. Geben Sie im SSH-Fenster sudo docker ps ein, um den ausgeführten Ganache-Container aufzurufen.
5. Container-ID für trufflesuite/ganache:v7.7.3 ermitteln
6. Geben Sie sudo docker logs CONTAINER_ID ein und ersetzen Sie CONTAINER_ID durch die ID für trufflesuite/ganache:v7.7.3.
7. Sehen Sie sich die Logs für Ganache an und prüfen Sie, ob dort eine Transaktion aufgeführt ist.

5. Bereinigen

Hier finden Sie das Skript, mit dem die Ressourcen bereinigt werden können, die wir im Rahmen dieses Codelabs erstellt haben. Im Rahmen dieser Bereinigung werden die folgenden Ressourcen gelöscht:

• Eingabe-Speicher-Bucket zum Speichern verschlüsselter Schlüsselanteile ($PRIMUS_INPUT_STORAGE_BUCKET).
• Verschlüsselungsschlüssel ($PRIMUS_KEY).
• Dienstkonto für den Zugriff auf geschützte Ressourcen ($PRIMUS_SERVICEACCOUNT).
• Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL).
• Dienstkonto für Arbeitslasten ($WORKLOAD_SERVICEACCOUNT).
• Workload Compute-Instanzen ($WORKLOAD_VM und $ETHEREUM_NODE).
• Der Bucket zum Speichern der Ergebnisse, in dem das Transaktionsergebnis gespeichert wird.($PRIMUS_RESULT_STORAGE_BUCKET).
• Artifact Registry zum Speichern des Arbeitslast-Images ($PRIMUS_ARTIFACT_REPOSITORY).

./cleanup.sh

Wenn Sie fertig sind, sollten Sie Ihr Projekt löschen.

• Rufen Sie die Cloud Platform Console auf.
• Wählen Sie das Projekt aus, das Sie beenden möchten, und klicken Sie oben auf „Löschen“. Das Projekt wird zum Löschen geplant.

Nächste Schritte

Sehen Sie sich einige dieser ähnlichen Codelabs an:

• Gemeinsam genutzte Daten mit Confidential Space schützen
• Codelab für signierte Container-Images
• Vertrauliche Daten mit Confidential Spaces analysieren

Weitere Informationen

• Fühlst du dich isoliert? Confidential Computing als Lösung
• Confidential Computing in der GCP
• Confidential Space: Die Zukunft der datenschutzfreundlichen Zusammenarbeit
• Wie Google und Intel Confidential Computing sicherer machen
• Datenschutz und Fortschritt – Sicherheit mit Confidential Computing in Google Cloud verbessern