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

1. Übersicht

Confidential Space bietet eine sichere Umgebung für die Zusammenarbeit zwischen mehreren Parteien. In diesem Codelab wird gezeigt, wie Confidential Space verwendet werden kann, um sensibles geistiges Eigentum wie Modelle für maschinelles Lernen zu schützen.

In diesem Codelab verwenden Sie Confidential Space, damit ein Unternehmen sein proprietäres Modell für maschinelles Lernen sicher mit einem anderen Unternehmen teilen kann, das das Modell verwenden möchte. Konkret hat Company Primus ein Machine-Learning-Modell, das nur für eine Arbeitslast in Confidential Space freigegeben wird. So behält Primus die vollständige Kontrolle über sein geistiges Eigentum. Company Secundus 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 Arbeitslastautor, der den Arbeitslastcode erstellt, und ein Mitbearbeiter, der sein geistiges Eigentum vor dem nicht vertrauenswürdigen Arbeitslastoperator Secundus schützen möchte. Secundus ist der Arbeitslastoperator der Arbeitslast für maschinelles Lernen.

Lerninhalte

So konfigurieren Sie eine Umgebung, 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
Grundkenntnisse zu Google Compute Engine ( Codelab), Confidential VM, Containern und Remote-Repositories
Grundkenntnisse zu Dienstkonten, Workload Identity-Föderation und Attributbedingungen.

Rollen bei der Einrichtung eines Confidential Space

In diesem Codelab ist Company Primus der Ressourceninhaber und Workload-Autor, der für Folgendes verantwortlich ist:

Erforderliche Cloud-Ressourcen mit einem ML-Modell einrichten
Arbeitslastcode schreiben
Arbeitslast-Image veröffentlichen
Workload Identity-Pool-Richtlinie konfigurieren, um ML-Modelle vor nicht vertrauenswürdigen Operatoren zu schützen

Secundus Company ist der Betreiber und verantwortlich für:

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

Funktionsweise von Confidential Space

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

Die Arbeitslast fordert ein allgemeines Google-Zugriffstoken für $PRIMUS_SERVICEACCOUNT aus dem Workload Identity-Pool an. Es bietet ein Attestation Verifier-Diensttoken mit Ansprüchen für Arbeitslast und Umgebung.
Wenn die Ansprüche für die Arbeitslastmessung im Token des Attestation Verifier-Dienstes mit der Attributbedingung im WIP übereinstimmen, wird das Zugriffstoken für $PRIMUS_SERVICEACCOUNT. zurückgegeben.
Die Arbeitslast verwendet das mit $PRIMUS_SERVICEACCOUNT verknüpfte Dienstkonto-Zugriffstoken, um auf das im Bucket $PRIMUS_INPUT_STORAGE_BUCKET gespeicherte Machine-Learning-Modell zuzugreifen.
Die Arbeitslast führt einen Vorgang für die Daten aus, die Secundus gehören. Sie wird von Secundus in seinem Projekt betrieben und 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 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/ml_model_protection/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 weitere Informationen 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 auch vorhandene Ressourcen verwenden, sofern sie bereits erstellt wurden. (z. B. export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket')

Sie können die folgenden Variablen mit vorhandenen Cloud-Ressourcennamen 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. Dies sind 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 die Verwendung von Tokens enthält, die vom Attestation Verifier-Dienst signiert wurden.
`$PRIMUS_SERVICE_ACCOUNT`	Primus-Dienstkonto, das `$PRIMUS_WORKLOAD_IDENTITY_POOL` für den Zugriff auf die geschützten Ressourcen (ML-Modell in diesem Codelab) verwendet. 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 für die Arbeitslast übertragen wird.

Sie können die folgenden Variablen mit vorhandenen Cloud-Ressourcennamen 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. Dies sind 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 Container-Images der Arbeitslast.
`$WORKLOAD_IMAGE_TAG`	Das Tag des Arbeitslast-Container-Images.
`$WORKLOAD_SERVICE_ACCOUNT`	Das Dienstkonto, das die Berechtigung hat, auf die Confidential VM zuzugreifen, auf der die Arbeitslast ausgeführt wird.

Sie benötigen bestimmte Berechtigungen für diese beiden Projekte. In diesem Leitfaden erfahren Sie, wie Sie IAM-Rollen über die GCP Console zuweisen:
Für $PRIMUS_PROJECT_ID benötigen Sie die Rollen „Storage-Administrator“, „Artifact Registry-Administrator“, „Dienstkontoadministrator“ und „IAM Workload Identity-Pooladministrator“.
Für $SECUNDUS_PROJECT_ID benötigen Sie die Rollen „Compute-Administrator“, „Storage-Administrator“, „Dienstkontoadministrator“, „IAM Workload Identity-Pooladministrator“ und optional „Sicherheitsadministrator“.
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

Primus Company-Ressourcen 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 Skriptausfü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) zum Validieren von Ansprüchen basierend auf Attributbedingungen, die unter dem zugehörigen Anbieter konfiguriert sind.
Dienstkonto ($PRIMUS_SERVICEACCOUNT), das dem oben genannten Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL) zugeordnet ist, mit IAM-Zugriff zum Lesen von Daten aus dem Cloud Storage-Bucket (mit der Rolle objectViewer) und zum Verbinden dieses Dienstkontos mit dem Workload Identity-Pool (mit der Rolle roles/iam.workloadIdentityUser).

Im Rahmen der Einrichtung dieser Cloud-Ressourcen verwenden wir ein TensorFlow-Modell. Wir können das gesamte Modell, einschließlich der Architektur, Gewichte und Trainingskonfiguration des Modells, in einem ZIP-Archiv speichern. In diesem Codelab verwenden wir das MobileNet V1-Modell, das mit dem ImageNet-Dataset trainiert wurde. Es ist hier verfügbar.

./setup_primus_company_resources.sh

Mit dem oben genannten Skript wird die Cloud-Ressource eingerichtet. Wir laden das Modell jetzt herunter und veröffentlichen es im Cloud Storage-Bucket, der vom Skript 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 mit dem folgenden Befehl im Cloud Storage-Bucket. Führen Sie den Befehl im Verzeichnis aus, das die Datei model.tar.gz enthält.

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

Secundus Company-Ressourcen 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. Im Rahmen dieser Schritte 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.

Hier finden Sie einige Beispielbilder für dieses Codelab.

./setup_secundus_company_resources.sh

3. Arbeitslast erstellen

Dienstkonto für Arbeitslast erstellen

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

Dieses Dienstkonto für Arbeitslasten ($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 $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 ist Python-Code für maschinelles Lernen, der auf das im Storage-Bucket von Primus gespeicherte ML-Modell zugreift und Inferenzvorgänge mit den Beispielbildern ausführt, die in einem Storage-Bucket gespeichert sind.

Das im Speicher-Bucket von Primus gespeicherte Machine-Learning-Modell wäre nur für die Arbeitslasten zugänglich, die die erforderlichen Attributbedingungen erfüllen. Diese Attributbedingungen werden im nächsten Abschnitt zum Autorisieren der Arbeitslast ausführlicher beschrieben.

Hier sehen Sie die Methode „run_inference()“ der Arbeitslast, die in diesem Codelab erstellt und verwendet wird. Den gesamten Workload-Code 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 Skript aus, um eine Arbeitslast zu erstellen, in der die folgenden Schritte ausgeführt werden:

Erstelle eine Artifact Registry($PRIMUS_ARTIFACT_REGISTRY), die Primus gehört.
Aktualisieren Sie den Arbeitslastcode mit den erforderlichen Ressourcennamen.
Erstellen Sie die ML-Arbeitslast und erstellen Sie ein Dockerfile zum Erstellen eines Docker-Images des Arbeitslastcodes. Hier finden Sie das Dockerfile, das für dieses Codelab verwendet wird.
Erstellen Sie das Docker-Image und veröffentlichen Sie es 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

Arbeitslasten können so codiert werden, dass die erwartete Version des Machine-Learning-Modells geladen wird. Dazu wird der Hash oder die Signatur des Modells geprüft, bevor es verwendet wird. Der Vorteil solcher zusätzlichen Prüfungen besteht darin, dass die Integrität des Modells für maschinelles Lernen gewährleistet wird. In diesem Fall müsste der Arbeitslastoperator auch das Arbeitslast-Image oder seine Parameter aktualisieren, wenn für die Arbeitslast unterschiedliche Versionen des ML-Modells verwendet werden sollen.

4. Arbeitslast autorisieren und ausführen

Arbeitslast autorisieren

Primus möchte Arbeitslasten autorisieren, auf das Machine-Learning-Modell zuzugreifen. Die Autorisierung soll auf Attributen der folgenden Ressourcen basieren:

Was: Code, der überprüft wird
Wo: Eine sichere Umgebung
Wer: Ein vertrauenswürdiger Betreiber

Primus verwendet die Workload Identity-Föderation, um eine Zugriffsrichtlinie basierend auf diesen Anforderungen zu erzwingen. Mit der Workload Identity-Föderation können Sie Attributbedingungen angeben. Mit diesen Bedingungen wird eingeschränkt, welche Identitäten sich mit dem Workload Identity-Pool (WIP) authentifizieren können. Sie können den Attestation Verifier Service dem WIP als Workload Identity-Poolanbieter hinzufügen, um Messungen zu präsentieren und die Richtlinie zu erzwingen.

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

Was: Die neueste Version von $WORKLOAD_IMAGE_NAME wurde in das $PRIMUS_ARTIFACT_REPOSITORY-Repository hochgeladen.
Wo: Die vertrauenswürdige Ausführungsumgebung von Confidential Space wird auf dem vollständig unterstützten Confidential Space-VM-Image ausgeführt.
Wer: Secundus-Dienstkonto $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 wird die Arbeitslast auf der Confidential Space-VM ausgeführt. Erforderliche TEE-Argumente werden mit dem Metadaten-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 Inferenz-Ergebnisse auf Beispielbildern aussehen könnten:

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 darstellt, der das Modell das Bild zuordnet.
Top_k_predictions::Hier werden bis zu k Vorhersagen für das Bild bereitgestellt, die von der wahrscheinlichsten bis zur unwahrscheinlichsten Vorhersage sortiert sind. Der Wert von k ist in diesem Codelab auf 5 festgelegt. Sie können ihn jedoch im Arbeitslastcode anpassen, um mehr oder weniger Vorhersagen zu erhalten.

Wenn Sie den Klassenindex in einen für Menschen lesbaren Klassennamen übersetzen möchten, sehen Sie sich die Liste der verfügbaren Labels hier an. Wenn Sie beispielsweise den Klassenindex 2 sehen, entspricht das dem Klassenlabel „Schleie“ in der Liste der Labels.

In diesem Codelab haben wir gezeigt, dass ein Modell, das Primus gehört, nur für die Arbeitslast freigegeben wird, die in einer TEE ausgeführt wird. Secundus führt die ML-Arbeitslast in einer TEE aus und kann das Modell von Primus verwenden, 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 ${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG-Workload-Image autorisiert.

Arbeitslast noch einmal ausführen

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

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

Vorhandene Ergebnisdatei und VM-Instanz löschen

Legen Sie das Projekt auf das $SECUNDUS_PROJECT_ID-Projekt 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 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:

Primus-Eingabe-Bucket ($PRIMUS_INPUT_STORAGE_BUCKET).
Primus-Dienstkonto ($PRIMUS_SERVICEACCOUNT).
Artefakt-Repository von Primus ($PRIMUS_ARTIFACT_REPOSITORY).
Primus-Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL).
Arbeitslast-Dienstkonto von Secundus ($WORKLOAD_SERVICEACCOUNT).
Eingabe-Storage-Bucket von Secundus ($SECUNDUS_INPUT_STORAGE_BUCKET).
Compute-Instanzen für Arbeitslasten.
Ergebnis-Storage-Bucket von Secundus ($SECUNDUS_RESULT_STORAGE_BUCKET).

$ ./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 dann zum Löschen geplant.

Nächste Schritte

Sehen Sie sich einige dieser ähnlichen Codelabs an: