Diese Seite wurde von der Cloud Translation API übersetzt.

ML-Modelle und geistiges Eigentum mit Confidential Space schützen

1. Übersicht

Confidential Space bietet eine sichere Umgebung für die Zusammenarbeit mehrerer Parteien. In diesem Codelab wird gezeigt, wie Confidential Space zum Schutz vertraulicher geistiger Eigentumsrechte wie Modellen für maschinelles Lernen verwendet werden kann.

In diesem Codelab verwenden Sie einen vertraulichen Bereich, damit ein Unternehmen sein eigenes maschinelles Lernmodell sicher mit einem anderen Unternehmen teilen kann, das das Modell verwenden möchte. Insbesondere hat das Unternehmen Primus ein Modell für maschinelles Lernen, das nur für eine Arbeitslast freigegeben werden soll, die in Confidential Space ausgeführt wird. So behält Primus die vollständige Kontrolle über sein geistiges Eigentum. Unternehmen 2 ist der Arbeitslastoperator und führt die Arbeitslast für maschinelles Lernen in einem Confidential Space aus. Secundus lädt dieses Modell und führt eine Inferenz mit Beispieldaten aus, die Secundus gehören.

Hier ist Primus der Autor des Arbeitslastcodes und ein Mitbearbeiter, der sein geistiges Eigentum vor dem nicht vertrauenswürdigen Arbeitslastoperator Secundus schützen möchte. Secundus ist der Arbeitslastoperator der Machine-Learning-Arbeitslast.

Aufgaben in diesem Lab

Wie eine Umgebung konfiguriert wird, in der eine Partei ihr proprietäres ML-Modell mit einer anderen Partei teilen kann, ohne die Kontrolle über ihr geistiges Eigentum zu verlieren.

Voraussetzungen

Google Cloud Platform-Projekt
Grundlegende Kenntnisse der Google Compute Engine ( Codelab), Confidential VMs, Container und Remote-Repositories
Grundlegende Kenntnisse zu Dienstkonten, Workload Identity-Föderation und Attributbedingungen

Rollen bei der Einrichtung eines Confidential Space

In diesem Codelab ist das Unternehmen Primus der Ressourceninhaber und Autor der Arbeitslast. Es ist für Folgendes verantwortlich:

Erforderliche Cloud-Ressourcen mit einem Modell für maschinelles Lernen einrichten
Code für die Arbeitslast schreiben
Arbeitslast-Image veröffentlichen
Workload Identity Pool-Richtlinie konfigurieren, um ML-Modell vor nicht vertrauenswürdigen Betreibern zu schützen

Secundus Company ist der Betreiber und für Folgendes verantwortlich:

Erforderliche Cloud-Ressourcen zum Speichern der Beispielbilder einrichten, die von der Arbeitslast verwendet werden, und der Ergebnisse
ML-Arbeitslast mit dem von Primus bereitgestellten Modell in Confidential Space ausführen

So funktioniert Confidential Space

Wenn Sie die Arbeitslast in Confidential Space ausführen, wird der folgende Prozess mit den konfigurierten Ressourcen ausgeführt:

Die Arbeitslast fordert vom Workload Identity-Pool ein allgemeines Google-Zugriffstoken für die $PRIMUS_SERVICEACCOUNT an. Es bietet ein Attestation Verifier-Diensttoken mit Workload- und Umgebungsansprüchen.
Wenn die Ansprüche für die Arbeitslastmessung im Token des Attestation Verifier Service mit der Attributbedingung in der WIP übereinstimmen, wird das Zugriffstoken für $PRIMUS_SERVICEACCOUNT. zurückgegeben.
Die Arbeitslast verwendet das Dienstkonto-Zugriffstoken, das mit $PRIMUS_SERVICEACCOUNT verknüpft ist, um auf das im Bucket $PRIMUS_INPUT_STORAGE_BUCKET gespeicherte Modell für maschinelles Lernen zuzugreifen.
Die Arbeitslast führt einen Vorgang an den Daten aus, die Secundus gehören, und wird von Secundus in seinem Projekt ausgeführt.
Die Arbeitslast verwendet das Dienstkonto $WORKLOAD_SERVICEACCOUNT, um die Ergebnisse dieses Vorgangs in den Bucket $SECUNDUS_RESULT_STORAGE_BUCKET zu schreiben.

2. Cloud-Ressourcen einrichten

Hinweis

Klonen Sie dieses Repository mit dem folgenden Befehl, um die erforderlichen Scripts 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/ml_model_protection/scripts

Achten Sie darauf, dass Sie die erforderlichen Projektumgebungsvariablen wie unten gezeigt festgelegt haben. Weitere Informationen zum Einrichten eines GCP-Projekts finden Sie in diesem Codelab. In diesem Artikel finden Sie Details dazu, wie Sie die Projekt-ID abrufen und wie sie sich von Projektnamen und Projektnummer unterscheidet.

export PRIMUS_PROJECT_ID=<GCP project id of Primus>
export SECUNDUS_PROJECT_ID=<GCP project id of Secundus>

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 \
    cloudresourcemanager.googleapis.com \
    cloudshell.googleapis.com \
    container.googleapis.com \
    containerregistry.googleapis.com \
    iam.googleapis.com \
    confidentialcomputing.googleapis.com

Weisen Sie den Variablen für die oben angegebenen Ressourcennamen mit dem folgenden Befehl Werte zu. Mit diesen Variablen können Sie die Ressourcennamen nach Bedarf anpassen und vorhandene Ressourcen verwenden, falls diese bereits erstellt wurden. (z. B. export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket')

Sie können die folgenden Variablen mit vorhandenen Namen von Cloud-Ressourcen im Primus-Projekt festlegen. Wenn die Variable festgelegt ist, wird die entsprechende vorhandene Cloud-Ressource aus dem Primus-Projekt verwendet. Wenn die Variable nicht festgelegt ist, wird der Name der Cloud-Ressource aus dem Projektnamen generiert und eine neue Cloud-Ressource mit diesem Namen erstellt. Im Folgenden finden Sie die unterstützten Variablen für Ressourcennamen:

`$PRIMUS_INPUT_STORAGE_BUCKET`	Der Bucket, in dem das Machine-Learning-Modell von Primus gespeichert ist.
`$PRIMUS_WORKLOAD_IDENTITY_POOL`	Der Workload Identity-Pool (WIP) von Primus, der Ansprüche validiert.
`$PRIMUS_WIP_PROVIDER`	Der Workload Identity-Poolanbieter von Primus, der die Autorisierungsbedingung für vom Attestation Verifier-Dienst signierte Tokens enthält.
`$PRIMUS_SERVICE_ACCOUNT`	Primus-Dienstkonto, mit dem `$PRIMUS_WORKLOAD_IDENTITY_POOL` auf die geschützten Ressourcen zugreift (ML-Modell in diesem Codelab) In diesem Schritt hat es die Berechtigung, das im Bucket `$PRIMUS_INPUT_STORAGE_BUCKET` gespeicherte ML-Modell zu lesen.
`$PRIMUS_ARTIFACT_REPOSITORY`	Das Artefakt-Repository, in das das Docker-Image der Arbeitslast per Push übertragen wird.

Sie können die folgenden Variablen mit vorhandenen Namen von Cloud-Ressourcen im Secundus-Projekt festlegen. Wenn die Variable festgelegt ist, wird die entsprechende vorhandene Cloud-Ressource aus dem Secundus-Projekt verwendet. Wenn die Variable nicht festgelegt ist, wird der Name der Cloud-Ressource aus dem Projektnamen generiert und eine neue Cloud-Ressource mit diesem Namen erstellt. Im Folgenden finden Sie die unterstützten Variablen für Ressourcennamen:

`$SECUNDUS_INPUT_STORAGE_BUCKET`	Der Bucket, in dem die Beispielbilder gespeichert sind, die Secundus mit dem von Primus bereitgestellten Modell klassifizieren möchte.
`$SECUNDUS_RESULT_STORAGE_BUCKET`	Der Bucket, in dem die Ergebnisse der Arbeitslast gespeichert werden.
`$WORKLOAD_IMAGE_NAME`	Der Name des Arbeitslast-Container-Images.
`$WORKLOAD_IMAGE_TAG`	Das Tag des Arbeitslastcontainer-Images.
`$WORKLOAD_SERVICE_ACCOUNT`	Das Dienstkonto, das auf die vertrauliche VM zugreifen darf, auf der die Arbeitslast ausgeführt wird.

Für diese beiden Projekte benötigen Sie bestimmte Berechtigungen. In diesem Leitfaden erfahren Sie, wie Sie IAM-Rollen mit der GCP Console gewähren:
Für die $PRIMUS_PROJECT_ID benötigen Sie die Rollen „Speicheradministrator“, „Artifact Registry-Administrator“, „Dienstkontoadministrator“ und „IAM Workload Identity-Pooladministrator“.
Für die $SECUNDUS_PROJECT_ID benötigen Sie die Rollen „Compute Admin“, „Storage Admin“, „Service Account Admin“, „IAM Workload Identity Pool Admin“ und „Security Admin“ (optional).
Führen Sie das folgende Script aus, um die verbleibenden Variablennamen auf Werte basierend auf Ihrer Projekt-ID für Ressourcennamen festzulegen.

source config_env.sh

Primus-Unternehmensressourcen einrichten

In diesem Schritt richten Sie die erforderlichen Cloud-Ressourcen für Primus ein. Führen Sie das folgende Script aus, um die Ressourcen für Primus einzurichten. Im Rahmen der Scriptausführung werden die folgenden Ressourcen erstellt:

Cloud Storage-Bucket ($PRIMUS_INPUT_STORAGE_BUCKET) zum Speichern des Modells für maschinelles Lernen von Primus.
Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL) zur Validierung von Ansprüchen basierend auf Attributbedingungen, die für den Anbieter konfiguriert wurden.
Dienstkonto ($PRIMUS_SERVICEACCOUNT), das mit dem oben genannten Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL) verknüpft ist, mit IAM-Zugriff zum Lesen von Daten aus dem Cloud-Speicher-Bucket (mit der Rolle objectViewer) und zum Verbinden dieses Dienstkontos mit dem Workload Identity-Pool (mit der Rolle roles/iam.workloadIdentityUser).

Für die Einrichtung dieser Cloud-Ressourcen verwenden wir ein TensorFlow-Modell. Wir können das gesamte Modell mit der Architektur, den Gewichten und der Trainingskonfiguration in einem ZIP-Archiv speichern. In diesem Codelab verwenden wir das MobileNet V1-Modell, das auf dem ImageNet-Dataset trainiert wurde.

./setup_primus_company_resources.sh

Mit dem oben genannten Script wird die Cloud-Ressource eingerichtet. Wir laden das Modell jetzt herunter und veröffentlichen es im Cloud Storage-Bucket, der vom Script erstellt wurde.

Laden Sie das vortrainierte Modell herunter.
Benennen Sie die heruntergeladene TAR-Datei in model.tar.gz um.
Veröffentlichen Sie die Datei model.tar.gz im Cloud Storage-Bucket. Verwenden Sie dazu den folgenden Befehl im Verzeichnis, in dem sich die Datei model.tar.gz befindet.

gsutil cp model.tar.gz gs://${PRIMUS_INPUT_STORAGE_BUCKET}/

Ressourcen für Secundus-Unternehmen einrichten

In diesem Schritt richten Sie die erforderlichen Cloud-Ressourcen für Secundus ein. Führen Sie das folgende Script aus, um die Ressourcen für Secundus einzurichten. Dabei werden die folgenden Ressourcen erstellt:

Cloud Storage-Bucket ($SECUNDUS_INPUT_STORAGE_BUCKET) zum Speichern der Beispielbilder für die Ausführung von Inferenzen durch Secundus.
Cloud Storage-Bucket ($SECUNDUS_RESULT_STORAGE_BUCKET) zum Speichern des Ergebnisses der Ausführung der ML-Arbeitslast durch Secundus.

Einige Beispielbilder für dieses Codelab finden Sie hier.

./setup_secundus_company_resources.sh

3. Arbeitslast erstellen

Dienstkonto für Arbeitslast erstellen

Jetzt erstellen Sie ein Dienstkonto für die Arbeitslast mit den erforderlichen Rollen und Berechtigungen. Führen Sie das folgende Script aus, um ein Arbeitslastdienstkonto im Secundus-Projekt zu erstellen. Dieses Dienstkonto wird von der VM verwendet, auf der die ML-Arbeitslast ausgeführt wird.

Dieses Workload-Dienstkonto ($WORKLOAD_SERVICEACCOUNT) hat die folgenden Rollen:

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

./create_workload_service_account.sh

Arbeitslast erstellen

In diesem Schritt erstellen Sie ein Docker-Image für die Arbeitslast. Die Arbeitslast wird von Primus erstellt. Die in diesem Codelab verwendete Arbeitslast besteht aus Python-Code für maschinelles Lernen, der auf das ML-Modell zugreift, das im Storage-Bucket von Primus gespeichert ist, und Inferenzen mit den Beispielbildern ausführt, die in einem Storage-Bucket gespeichert sind.

Auf das im Speicher-Bucket von Primus gespeicherte Machine-Learning-Modell kann nur über Arbeitslasten zugegriffen werden, die die erforderlichen Attributbedingungen erfüllen. Diese Attributbedingungen werden im nächsten Abschnitt zur Autorisierung der Arbeitslast ausführlicher beschrieben.

Hier ist die run_inference()-Methode der Arbeitslast, die in diesem Codelab erstellt und verwendet wird. Den vollständigen Code für die Arbeitslast finden Sie hier.

def run_inference(image_path, model):
  try:
    # Read and preprocess the image
    image = tf.image.decode_image(tf.io.read_file(image_path), channels=3)
    image = tf.image.resize(image, (128, 128))
    image = tf.image.convert_image_dtype(image, tf.float32)
    image = tf.expand_dims(image, axis=0)

    # Get predictions from the model
    predictions = model(image)
    predicted_class = np.argmax(predictions)

    top_k = 5
    top_indices = np.argsort(predictions[0])[-top_k:][::-1]

    # Convert top_indices to a TensorFlow tensor
    top_indices_tensor = tf.convert_to_tensor(top_indices, dtype=tf.int32)

    # Use TensorFlow tensor for indexing
    top_scores = tf.gather(predictions[0], top_indices_tensor)

    return {
        "predicted_class": int(predicted_class),
        "top_k_predictions": [
            {"class_index": int(idx), "score": float(score)}
            for idx, score in zip(top_indices, top_scores)
        ],
    }
  except Exception as e:
    return {"error": str(e)}

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

Erstellen Sie eine Artifact Registry($PRIMUS_ARTIFACT_REGISTRY), deren Inhaber Primus ist.
Aktualisieren Sie den Arbeitslastcode mit den Namen der erforderlichen Ressourcen.
Erstellen Sie die ML-Arbeitslast und ein Dockerfile zum Erstellen eines Docker-Images des Arbeitslastcodes. Hier finden Sie das Dockerfile, das für dieses Codelab verwendet wird.
Erstellen und veröffentlichen Sie das Docker-Image in der Artifact Registry ($PRIMUS_ARTIFACT_REGISTRY) von Primus.
Gewähren Sie $WORKLOAD_SERVICEACCOUNT die Leseberechtigung für $PRIMUS_ARTIFACT_REGISTRY. Dies ist erforderlich, damit der Arbeitslastcontainer das Docker-Image der Arbeitslast aus der Artifact Registry abrufen kann.

./create_workload.sh

Außerdem können Arbeitslasten so codiert werden, dass die erwartete Version des KI-Modells geladen wird, indem der Hash oder die Signatur des Modells vor der Verwendung geprüft wird. Der Vorteil solcher zusätzlichen Prüfungen besteht darin, dass die Integrität des Modells für maschinelles Lernen sichergestellt wird. In diesem Fall müsste der Arbeitslastbearbeiter auch das Arbeitslast-Image oder seine Parameter aktualisieren, wenn für die Arbeitslast voraussichtlich unterschiedliche Versionen des ML-Modells verwendet werden.

4. Arbeitslast autorisieren und ausführen

Arbeitslast autorisieren

Primus möchte Arbeitslasten basierend auf Attributen der folgenden Ressourcen autorisieren, auf sein Machine-Learning-Modell zuzugreifen:

Was: Code, der bestätigt wurde
Wo: Eine sichere Umgebung
Wer: Ein vertrauenswürdiger Betreiber

Primus verwendet die Workload Identity-Föderation, um eine Zugriffsrichtlinie auf der Grundlage dieser Anforderungen durchzusetzen. Mit der Workload Identity-Föderation können Sie Attributbedingungen angeben. Mit diesen Bedingungen wird eingeschränkt, welche Identitäten sich beim Workload Identity-Pool (WIP) authentifizieren können. Sie können den Attestation Verifier Service dem WIP als Workload Identity-Pool-Anbieter hinzufügen, um Messungen vorzulegen und die Richtlinie durchzusetzen.

Der Workload Identity-Pool wurde bereits im Rahmen der Einrichtung der Cloud-Ressourcen erstellt. Primus erstellt jetzt einen neuen OIDC-Workload Identity-Pool-Anbieter. Die angegebene --attribute-condition autorisiert den Zugriff auf den Arbeitslastcontainer. Dafür sind erforderlich:

Was: Letzte $WORKLOAD_IMAGE_NAME, die in das $PRIMUS_ARTIFACT_REPOSITORY-Repository hochgeladen wurde.
Wo: Die vertrauenswürdige Ausführungsumgebung von Confidential Space wird auf dem vollständig unterstützten VM-Image von Confidential Space ausgeführt.
Wer: Dienstkonto „Secundus $WORKLOAD_SERVICE_ACCOUNT“

export WORKLOAD_IMAGE_DIGEST=$(gcloud artifacts docker images describe ${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG  --format="value(image_summary.digest)" --project ${PRIMUS_PROJECT_ID})

gcloud config set project $PRIMUS_PROJECT_ID

gcloud iam workload-identity-pools providers create-oidc $PRIMUS_WIP_PROVIDER \
  --location="global" \
  --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'" \
  --attribute-condition="assertion.swname == 'CONFIDENTIAL_SPACE' && 
'STABLE' in assertion.submods.confidential_space.support_attributes && 
assertion.submods.container.image_digest == '${WORKLOAD_IMAGE_DIGEST}' &&
 assertion.submods.container.image_reference == '${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG' && 
'$WORKLOAD_SERVICEACCOUNT@$SECUNDUS_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts"

Arbeitslast ausführen

In diesem Schritt führen wir die Arbeitslast in der Confidential Space-VM aus. Erforderliche TEE-Argumente werden mit dem Metadata-Flag übergeben. Argumente für den Arbeitslastcontainer werden über den Teil „tee-cmd“ des Flags übergeben. Das Ergebnis der Workload-Ausführung wird in $SECUNDUS_RESULT_STORAGE_BUCKET veröffentlicht.

gcloud compute instances create ${WORKLOAD_VM} \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --project=${SECUNDUS_PROJECT_ID} \
 --maintenance-policy=MIGRATE \
 --scopes=cloud-platform --zone=${SECUNDUS_PROJECT_ZONE} \
 --image-project=confidential-space-images \
 --image-family=confidential-space \
 --service-account=${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_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}

Ergebnisse ansehen

Nachdem die Arbeitslast erfolgreich abgeschlossen wurde, wird das Ergebnis der ML-Arbeitslast in $SECUNDUS_RESULT_STORAGE_BUCKET veröffentlicht.

gsutil cat gs://$SECUNDUS_RESULT_STORAGE_BUCKET/result

Hier sind einige Beispiele dafür, wie die Inferenzergebnisse auf Beispielbildern aussehen können:

Image: sample_image_1.jpeg, Response: {'predicted_class': 531, 'top_k_predictions': [{'class_index': 531, 'score': 12.08437442779541}, {'class_index': 812, 'score': 10.269512176513672}, {'class_index': 557, 'score': 9.202644348144531}, {'class_index': 782, 'score': 9.08737564086914}, {'class_index': 828, 'score': 8.912498474121094}]}

Image: sample_image_2.jpeg, Response: {'predicted_class': 905, 'top_k_predictions': [{'class_index': 905, 'score': 9.53619384765625}, {'class_index': 557, 'score': 7.928380966186523}, {'class_index': 783, 'score': 7.70129919052124}, {'class_index': 531, 'score': 7.611623287200928}, {'class_index': 906, 'score': 7.021416187286377}]}

Image: sample_image_3.jpeg, Response: {'predicted_class': 905, 'top_k_predictions': [{'class_index': 905, 'score': 6.09878396987915}, {'class_index': 447, 'score': 5.992854118347168}, {'class_index': 444, 'score': 5.9582319259643555}, {'class_index': 816, 'score': 5.502010345458984}, {'class_index': 796, 'score': 5.450454235076904}]}

Für jedes Beispielbild in einem Secundus-Speicher-Bucket wird ein Eintrag in den Ergebnissen angezeigt. Dieser Eintrag enthält zwei wichtige Informationen:

Index von „predicted_class“:Dies ist ein numerischer Index, der die Klasse angibt, der das Modell das Bild zuordnet.
Top_k_predictions::Hier werden bis zu k Vorhersagen für das Bild ausgegeben, sortiert nach Wahrscheinlichkeit. In diesem Codelab ist der Wert von k auf 5 festgelegt. Sie können ihn jedoch im Code der Arbeitslast anpassen, um mehr oder weniger Vorhersagen zu erhalten.

Eine Liste der verfügbaren Labels, mit denen der Klassenindex in einen visuell lesbaren Klassennamen umgewandelt werden kann, finden Sie hier. Wenn Sie beispielsweise den Klassenindex 2 sehen, entspricht dies dem Klassenlabel „Karpfen“ in der Labelliste.

In diesem Codelab haben wir gezeigt, dass ein Modell, das Primus gehört, nur für die Arbeitslast freigegeben wird, die in einem TEE ausgeführt wird. Secundus führt die ML-Arbeitslast in einem TEE aus und diese Arbeitslast kann das Modell von Primus nutzen, während Primus die vollständige Kontrolle über das Modell behält.

Nicht autorisierte Arbeitslast ausführen

Secundus ändert das Arbeitslast-Image, indem er ein anderes Arbeitslast-Image aus seinem eigenen Artefakt-Repository abruft, das nicht von Primus autorisiert ist. Der Workload Identity-Pool von Primus hat nur das Arbeitslast-Image ${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG autorisiert.

Arbeitslast noch einmal ausführen

Wenn Secundus versucht, die ursprüngliche Arbeitslast mit diesem neuen Arbeitslast-Image auszuführen, schlägt dies fehl. Wenn Sie den Fehler sehen möchten, löschen Sie die ursprüngliche Ergebnisdatei und die VM-Instanz und versuchen Sie dann noch einmal, die Arbeitslast auszuführen.

Achten Sie darauf, dass in der Artifact Registry von Secundus (als us-docker.pkg.dev/${SECUNDUS_PROJECT_ID}/custom-image/${WORKLOAD_IMAGE_NAME}:${WORKLOAD_IMAGE_TAG}) ein neues Docker-Image veröffentlicht wurde und dass das Arbeitslast-Dienstkonto ($WORKLOAD_SERVICEACCOUNT) dem Artifact Registry-Leser die Berechtigung zum Lesen dieses neuen Arbeitslast-Images erteilt hat. So wird sichergestellt, dass die Arbeitslast nicht beendet wird, bevor das von der Arbeitslast vorgelegte Token von der WIP-Richtlinie von Primus abgelehnt wird.

Vorhandene Ergebnisdatei und VM-Instanz löschen

Legen Sie das Projekt auf $SECUNDUS_PROJECT_ID fest.

gcloud config set project $SECUNDUS_PROJECT_ID

Löschen Sie die Ergebnisdatei.

gsutil rm gs://$SECUNDUS_RESULT_STORAGE_BUCKET/result

Löschen Sie die Confidential VM-Instanz.

gcloud compute instances delete ${WORKLOAD_VM} --zone=${SECUNDUS_PROJECT_ZONE}

Führen Sie die nicht autorisierte Arbeitslast aus:

gcloud compute instances create ${WORKLOAD_VM} \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=MIGRATE \
 --scopes=cloud-platform --zone=${SECUNDUS_PROJECT_ZONE} \
 --image-project=confidential-space-images \
 --image-family=confidential-space \
 --service-account=${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com \
 --metadata  ^~^tee-image-reference=us-docker.pkg.dev/${SECUNDUS_PROJECT_ID}/custom-image/${WORKLOAD_IMAGE_NAME}:${WORKLOAD_IMAGE_TAG}

Fehler ansehen

Anstelle der Ergebnisse der Arbeitslast wird ein Fehler (The given credential is rejected by the attribute condition) angezeigt.

gsutil cat gs://$SECUNDUS_RESULT_STORAGE_BUCKET/result

5. Bereinigen

Hier finden Sie das Script, mit dem Sie die im Rahmen dieses Codelabs erstellten Ressourcen bereinigen können. Im Rahmen dieser Bereinigung werden die folgenden Ressourcen gelöscht:

Eingabespeicher-Bucket von Primus ($PRIMUS_INPUT_STORAGE_BUCKET).
Primus-Dienstkonto ($PRIMUS_SERVICEACCOUNT)
Artifact-Repository von Primus ($PRIMUS_ARTIFACT_REPOSITORY).
Primus-Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL)
Arbeitslastdienstkonto von Secundus ($WORKLOAD_SERVICEACCOUNT)
Eingabe-Storage-Bucket von Secundus ($SECUNDUS_INPUT_STORAGE_BUCKET).
Workload Compute-Instanzen
Ergebnis-Storage-Bucket von Secundus ($SECUNDUS_RESULT_STORAGE_BUCKET)

$ ./cleanup.sh

Wenn Sie mit der explorativen Datenanalyse 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 dann zum Löschen geplant.

Was liegt als Nächstes an?

Sehen Sie sich diese ähnlichen Codelabs an: