Ta strona została przetłumaczona przez Cloud Translation API.

Ćwiczenie z programowania dotyczące podpisanego kontenera

1. Omówienie

To ćwiczenie w Codelabs jest oparte na ćwiczeniach z programowania Poufnej przestrzeni. Obsługa podpisanego obrazu kontenera udostępnia opcję uwierzytelniania kontenera za pomocą potwierdzonego klucza publicznego zamiast określania skrótu obrazu w zasadzie puli Workload Identity (WIP).

Co się zmieniło w związku z obsługą obrazów podpisanego kontenera w Pokoju poufnym:

Większa łatwość obsługi: dzięki wprowadzeniu funkcji podpisanego obrazu kontenera możemy teraz przejść z podejścia do podsumowania obrazu zbioru zadań na podejście do podpisu kontenerów w przypadku współpracowników i audytów autoryzujących obraz.

Aby bezpośrednio korzystać z podsumowań obrazów, właściciele zasobów muszą aktualizować swoje zasady o podsumowanie obrazu za każdym razem, gdy autoryzują nowy obraz. Dzięki użyciu podpisów obrazów zasada zawiera odcisk cyfrowy klucza publicznego, którego odpowiedni klucz prywatny należy do współpracownika lub audytora i jest używany do podpisywania skontrolowanych obrazów.
W przypadku niektórych modeli zabezpieczeń odwoływanie się do klucza podpisywania zaufanego obrazu jest wygodniejsze niż aktualizowanie listy nowych wartości skrótu obrazu.

Brak regresji bezpieczeństwa: to podejście do podpisywania kontenerów nie spowoduje żadnej regresji bezpieczeństwa w porównaniu z poprzednią metodą podsumowywania obrazów, ponieważ granice zaufania pozostają takie same. W ramach metody podpisu kontenera właściciel zasobu autoryzuje klucz weryfikacyjny, określając odcisk cyfrowy zaufanego klucza publicznego w zasadzie WIP. Kontrola autoryzacji jest wykonywana przez usługę weryfikatora atestu oraz WIP. Usługa weryfikatora atestów sprawdza, czy podpis jest powiązany z uruchomionym zadaniem, a zasada WIP sprawdza, czy klucz publiczny potwierdzony przez usługę jest autoryzowany przez zasadę.

Silne zabezpieczenia: korzystając z podpisów obrazów kontenerów, można przekazać pewien stopień zaufania podmiotowi zabezpieczeń. Określając w zasadach atestu odcisk cyfrowy klucza publicznego zaufanego sygnatariusza, właściciel zasobu upoważnia tę osobę do wystawiania rekomendacji, które obrazy kontenerów są zgodne z zasadami. Usługa weryfikatora atestów sprawdza, czy podpis jest powiązany z uruchomionym zadaniem, a zasada sprawdza, czy klucz publiczny, który utworzył podpis, jest autoryzowany przez zasadę. Dzięki temu dodatkowa warstwa pośrednia, którą zapewnia podpisywanie obrazów, zapewnia silne gwarancje bezpieczeństwa przestrzeni poufnej.

Jedyną różnicą między tymi podejściami jest to, że w tym drugim przypadku zastosowano dodatkową warstwę pośrednią, w której obrazy zadań są autoryzowane za pomocą klucza podpisywania. Nie tworzy to nowych luk w zabezpieczeniach, ponieważ granice zaufania pozostają takie same.

Czego się nauczysz

Z tego ćwiczenia w Codelabs dowiesz się, jak używać podpisu obrazu kontenera do autoryzowania dostępu do chronionych zasobów:

Jak podpisać obraz kontenera podlegającego kontroli za pomocą cosign
Jak przesyłać podpisy obrazów kontenerów do rejestrów OCI w celu wykrywania i przechowywania podpisów
Jak skonfigurować zasoby w chmurze niezbędne do uruchomienia przestrzeni poufnej
Jak uruchomić zadanie w obszarze poufnym z obsługą podpisanego obrazu kontenera

Dzięki temu ćwiczeniu w Codelabs dowiesz się, jak używać przestrzeni poufnej do zdalnego poświadczania obrazu kontenera podpisanego zaufanym kluczem działającym w Google Compute Engine.

Czego potrzebujesz

Ukończ ćwiczenie z programowania dotyczące poufnej przestrzeni
Projekt Google Cloud Platform
Przeglądarka, np. Chrome lub Firefox
znajomość standardowych edytorów tekstu systemu Linux, takich jak Vim, Emacs lub Nano;
Podstawowa znajomość usługi Cosignstore
Podstawowa znajomość Google Compute Engine ( codelab), poufnych maszyn wirtualnych, kontenerów i zdalnych repozytoriów
Podstawowa znajomość usługi Cloud KMS ( codelab)
Podstawowa znajomość kont usługi, federacji tożsamości zadań i warunków atrybutów.
Podstawowa znajomość Artifact Registry
Podstawowa wiedza na temat podpisów cyfrowych

Role powiązane z obszarem poufnym z podpisanym obrazem kontenera

W tym ćwiczeniu w Codelabs Primus Bank będzie audytorem i właścicielem zasobów odpowiedzialnym za:

Konfiguruję wymagane zasoby z przykładowymi danymi.
Kontrola kodu zadania.
Użycie cosign do podpisywania obrazu zadania.
Przesyłam podpis do repozytorium.
Konfigurowanie zasady WIP w celu ochrony danych klientów.

Secundus Bank będzie autorem i operatorem zbioru zadań oraz będzie odpowiedzialny za:

Konfiguruję zasoby wymagane do przechowywania wyniku.
Piszę kod zadania.
Publikuję obraz zadania.
Uruchamianie zadania w obszarze poufnym z obsługą podpisanego obrazu kontenera.

Secundus Bank opracuje i opublikuje zadanie, które będzie wysyłać zapytania do danych klientów przechowywanych w zasobniku Cloud Storage należącym do Primus Banku. Primus Bank sprawdzi zadanie, podpisze obraz kontenera i skonfiguruje zasady WIP, aby umożliwić zatwierdzonym zadaniom dostęp do swoich danych. Wynik wykonania tego zadania zostanie zapisany w zasobniku Cloud Storage należącym do banku Secundus.

Zasoby związane z konfiguracją Obszaru poufnego

To ćwiczenie w Codelabs odwołuje się do szeregu zmiennych, które należy ustawić na odpowiednie wartości dla Twojego projektu GCP. W poleceniach z tego ćwiczenia w programie zakładamy, że te zmienne zostały ustawione. Za pomocą export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' można na przykład określić nazwę wejściowego zasobnika pamięci masowej banku Primus. Jeśli zmienne nazw zasobów nie zostały ustawione, zostaną wygenerowane na podstawie identyfikatora projektu GCP.

Skonfiguruj te ustawienia w projekcie Primus:

$PRIMUS_INPUT_STORAGE_BUCKET: zasobnik, w którym jest przechowywany plik danych klienta.
$PRIMUS_WORKLOAD_IDENTITY_POOL: pula tożsamości zadań (WIP), która weryfikuje żądania.
$PRIMUS_WIP_PROVIDER: dostawca puli Workload Identity, który zawiera warunek autoryzacji, który ma być używany w przypadku tokenów podpisanych przez usługę weryfikatora atestu.
$PRIMUS_SERVICEACCOUNT: konto usługi, za pomocą którego $PRIMUS_WORKLOAD_IDENTITY_POOL uzyskuje dostęp do zabezpieczonych zasobów. Na tym etapie ma uprawnienia do wyświetlania danych klienta przechowywanych w zasobniku $PRIMUS_INPUT_STORAGE_BUCKET.
$PRIMUS_ENC_KEY: klucz KMS używany do szyfrowania danych przechowywanych w $PRIMUS_INPUT_STORAGE_BUCKET.

Nowe materiały w tym ćwiczeniu z programowania:

$PRIMUS_COSIGN_REPOSITORY: Artifact Registry do przechowywania podpisów obrazów zadań.
$PRIMUS_SIGNING_KEY: klucz KMS używany do podpisywania obrazu zbioru zadań przez audytora/narzędzia do współpracy nad danymi (w tym przypadku z banku Primus).

Skonfiguruj te ustawienia w projekcie Secundus:

$SECUNDUS_ARTIFACT_REGISTRY: artefakt, w którym zostanie wypchnięty obraz Dockera zadań.
$WORKLOAD_IMAGE_NAME: nazwa obrazu Dockera zadania.
$WORKLOAD_IMAGE_TAG: tag obrazu Dockera zadania.
$WORKLOAD_SERVICEACCOUNT: konto usługi z uprawnieniami dostępu do poufnej maszyny wirtualnej, na której działa zadanie.
$SECUNDUS_RESULT_BUCKET: zasobnik, w którym są przechowywane wyniki zadania.

Inne zasoby:

Pole primus_customer_list.csv zawiera dane klienta. Wczytamy te dane do usługi $PRIMUS_INPUT_STORAGE_BUCKET i utworzymy zadanie, które będzie wysyłać zapytania dotyczące tych danych.

Istniejący przepływ pracy

Gdy uruchomisz zadanie w obszarze poufnym, zachodzi poniższy proces z użyciem skonfigurowanych zasobów:

Zadanie wysyła z WIP ogólny token dostępu Google dla platformy $PRIMUS_SERVICEACCOUNT. Oferuje token usługi weryfikatora atestów z deklaracjami zadań i środowiska.
Jeśli żądania pomiaru zbiorów zadań w tokenie usługi weryfikatora atestu pasują do warunku atrybutu w trakcie opracowywania, zwraca token dostępu dla $PRIMUS_SERVICEACCOUNT.
Zadanie używa tokena dostępu konta usługi powiązanego z zasadą $PRIMUS_SERVICEACCOUNT, aby uzyskiwać dostęp do danych klienta w zasobniku $PRIMUS_INPUT_STORAGE_BUCKET.
Zbiór zadań wykonuje operację na tych danych.
Zbiór zadań używa konta usługi $WORKLOAD_SERVICEACCOUNT do zapisywania wyników tej operacji w zasobniku $SECUNDUS_RESULT_STORAGE_BUCKET.

Nowy przepływ pracy z obsługą podpisanego kontenera

Obsługa podpisanego kontenera zostanie zintegrowana z istniejącym przepływem pracy, jak zaznaczono poniżej. Gdy uruchomisz zadanie w Pokoju poufnym z obsługą obrazu podpisanego kontenera, wykona się poniższy proces z wykorzystaniem skonfigurowanych zasobów:

Poufny obszar wykrywa wszystkie podpisy kontenerów związane z bieżącym obrazem zadania i wysyła je do weryfikatora atestu. Weryfikator atestu weryfikuje podpis, a w potwierdzeniach umieszcza wszystkie ważne podpisy.
Zadanie wysyła z WIP ogólny token dostępu Google dla platformy $PRIMUS_SERVICEACCOUNT. Oferuje token usługi weryfikatora atestów z deklaracjami zadań i środowiska.
Jeśli deklaracja podpisu kontenera w tokenie usługi weryfikatora atestu pasuje do warunku atrybutu w trakcie pracy, zwraca token dostępu dla $PRIMUS_SERVICEACCOUNT.
Zadanie używa tokena dostępu konta usługi powiązanego z zasadą $PRIMUS_SERVICEACCOUNT, aby uzyskiwać dostęp do danych klienta w zasobniku $PRIMUS_INPUT_STORAGE_BUCKET.
Zbiór zadań wykonuje operację na tych danych.
Zbiór zadań używa funkcji $WORKLOAD_SERVICEACCOUNT do zapisywania wyników tej operacji w zasobniku $SECUNDUS_RESULT_STORAGE_BUCKET.

2. Skonfiguruj zasoby Cloud

W ramach konfiguracji Poufnej przestrzeni najpierw utworzysz wymagane zasoby w chmurze w projektach GCP w banku Primus i Secundus. Oto zasoby, które po raz pierwszy ukażą się w tym ćwiczeniu z programowania:

W projekcie Primus:

Klucz podpisywania KMS używany do podpisywania zadań Secundus po kontroli kodu.
Repozytorium Artifact Registry, w którym będą przechowywane podpisy Cosign.

W projekcie Secundus nie ma nowych zasobów. Po skonfigurowaniu tych zasobów utworzysz konto usługi dla zadania z wymaganymi rolami i uprawnieniami. Utworzysz obraz zadania, a audytor Primus bank go podpisze. Zadanie zostanie następnie autoryzowane przez osoby współpracujące z nami za pomocą danych (bank Prrimus w tym ćwiczeniu), a operator zbioru zadań (w tym przypadku Secundus Bank) uruchomi to zadanie.

W ramach konfigurowania Obszaru poufnego utworzysz wymagane zasoby w chmurze w projektach GCP Primus i Secundus.

Zanim zaczniesz

Skopiuj to repozytorium za pomocą poniższego polecenia, aby uzyskać wymagane skrypty używane w ramach tego ćwiczenia z programowania.

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

Sprawdź, czy masz ustawione wymagane projekty, jak pokazano poniżej.

$ export PRIMUS_PROJECT_ID=<GCP project id of primus bank>
$ export SECUNDUS_PROJECT_ID=<GCP project id of secundus bank>

Użyj tego polecenia, aby ustawić zmienne dla wymienionych powyżej nazw zasobów. Nazwy zasobów możesz zastąpić za pomocą tych zmiennych (np.export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket')
Uruchom ten skrypt, aby ustawić pozostałe nazwy zmiennych zgodnie z identyfikatorem projektu dla nazw zasobów.

$ source config_env.sh

Zainstaluj cosign zgodnie z tymi instrukcjami.

Skonfiguruj zasoby banku Primus

W tym kroku skonfigurujesz wymagane zasoby w chmurze na potrzeby banku Primus. Uruchom ten skrypt, aby skonfigurować zasoby dla Primus Bank. W ramach tych czynności zostaną utworzone te zasoby:

Zasobnik Cloud Storage ($PRIMUS_INPUT_STORAGE_BUCKET) do przechowywania zaszyfrowanego pliku danych klientów banku Primus.
Klucz szyfrowania ($PRIMUS_ENC_KEY) i pęk kluczy ($PRIMUS_ENC_KEYRING) w KMS do szyfrowania pliku danych banku Primus.
Pula tożsamości zadań ($PRIMUS_WORKLOAD_IDENTITY_POOL) do weryfikacji deklaracji na podstawie warunków atrybutów skonfigurowanych u jej dostawcy.
Konto usługi ($PRIMUS_SERVICEACCOUNT) podłączone do wymienionej powyżej puli Workload Identity ($PRIMUS_WORKLOAD_IDENTITY_POOL) z tymi uprawnieniami:
roles/cloudkms.cryptoKeyDecrypter w celu odszyfrowania danych przy użyciu klucza KMS.
objectViewer, aby odczytać dane z zasobnika Cloud Storage.
roles/iam.workloadIdentityUser za połączenie tego konta usługi z pulą Workload Identity.

$ ./setup_primus_bank_resources.sh

Konfigurowanie zasobów banku Secundus

W tym kroku skonfigurujesz wymagane zasoby w chmurze na potrzeby banku Secundus. Uruchom ten skrypt, aby skonfigurować zasoby dla banku Secundus. W ramach tych czynności zostaną utworzone wymienione poniżej zasoby:

Zasobnik Cloud Storage ($SECUNDUS_RESULT_STORAGE_BUCKET) do przechowywania wyniku wykonania zadania przez bank Secundus.

$ ./setup_secundus_bank_resources.sh

3. Utwórz i podpisz zadanie

Utwórz konto usługi zadań

Teraz utworzysz konto usługi dla zadania z wymaganymi rolami i uprawnieniami. Uruchom ten skrypt, aby utworzyć konto usługi zadań w projekcie bankowym Secundus. To konto usługi będzie używane przez maszynę wirtualną, która uruchamia zbiór zadań.

To konto usługi zadań ($WORKLOAD_SERVICEACCOUNT) będzie miało przypisane te role:
confidentialcomputing.workloadUser, aby uzyskać token atestu
logging.logWriter, aby zapisać logi w Cloud Logging.
objectViewer, aby odczytać dane z zasobnika Cloud Storage $PRIMUS_INPUT_STORAGE_BUCKET.
objectAdmin, aby zapisać wynik zadania w zasobniku Cloud Storage $SECUNDUS_RESULT_STORAGE_BUCKET.

$ ./create_workload_serviceaccount.sh

Utwórz zadanie

W tym kroku utworzysz obraz Dockera zadania. Zbiór zadań używany w tym ćwiczeniach z Codelabs to prosta aplikacja w języku Go oparta na interfejsie wiersza poleceń, która zlicza klientów (z danych klientów banku Primus) z podanej lokalizacji geograficznej w argumencie. Uruchom ten skrypt, aby utworzyć zadanie, w którym wykonywane są te kroki:

Tworzenie Artifact Registry($SECUNDUS_ARTIFACT_REGISTRY) należącego do banku Secundus.
Zaktualizuj kod zadania o wymagane nazwy zasobów. Tutaj znajdziesz kod zbioru zadań użyty w tym ćwiczeniu z programowania.
Utwórz plik binarny Go i utwórz plik Dockerfile, aby utworzyć obraz Dockera kodu zadania. Tutaj znajdziesz plik Dockerfile użyty w tym ćwiczeniu z programowania.
Skompiluj i opublikuj obraz Dockera w Artifact Registry ($SECUNDUS_ARTIFACT_REGISTRY), którego właścicielem jest bank Secundus.
Przyznaj maszynie wirtualnej $WORKLOAD_SERVICEACCOUNT uprawnienia do odczytu dla: $SECUNDUS_ARTIFACT_REGISTRY. Jest to konieczne, aby kontener zbioru zadań mógł pobierać z Artifact Registry obraz Dockera zadania.

$ ./create_workload.sh

Podpisz zadanie

Będziemy używać Cosign do podpisywania obrazu zadania. W usłudze Cosign będzie domyślnie przechowywać podpisy w tym samym repozytorium co obraz, który podpisuje. Aby określić inne repozytorium na potrzeby podpisów, możesz ustawić zmienną środowiskową COSIGN_REPOSITORY.

Jako przykładu użyjemy Artifact Registry. W zależności od potrzeb możesz też wybrać inne rejestry oparte na OCI, takie jak Docker Hub czy AWS CodeArtifact.

Tworzenie repozytorium Dockera w Artifact Registry

$ gcloud config set project $PRIMUS_PROJECT_ID

$ gcloud artifacts repositories create $PRIMUS_COSIGN_REPOSITORY \
  --repository-format=docker --location=us

Utwórz pęk kluczy i klucz w KMS do podpisywania obrazu zadania.

$ gcloud config set project $PRIMUS_PROJECT_ID

$ gcloud kms keyrings create $PRIMUS_SIGNING_KEYRING \
  --location=global

$ gcloud kms keys create $PRIMUS_SIGNING_KEY \
  --keyring=$PRIMUS_SIGNING_KEYRING \
  --purpose=asymmetric-signing \
  --default-algorithm=ec-sign-p256-sha256
  --location=us

W przypadku Artifact Registry wymagana jest pełna nazwa obrazu, na przykład $LOCATION/$PROJECT/$REPOSITORY/$IMAGE_NAME. Do repozytorium, aby przechowywać podpis, możesz przesłać dowolny obraz kontenera.

$ export COSIGN_REPOSITORY=us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}/demo

Przypisz rolę wyświetlającego w repozytorium $PRIMUS_COSIGN_REPOSITORY do konta usługi $WORKLOAD_SERVICEACCOUNT. Umożliwi to usłudze Confidential Przestrzeń wykrywania wszelkich podpisów obrazów kontenerów przesłanych do $PRIMUS_COSIGN_REPOSITORY.

$ gcloud artifacts repositories add-iam-policy-binding ${PRIMUS_COSIGN_REPOSITORY} \
--project=${PRIMUS_PROJECT_ID} --role='roles/viewer' --location=us \
--member="serviceAccount:${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com"

Cosign to zaawansowane narzędzie z wieloma funkcjami podpisywania. W naszym przypadku użycia wymagamy tylko rozwiązania Cosign do podpisywania za pomocą pary kluczy. Podpisywanie bez klucza Cosign nie jest obsługiwane w przypadku tej funkcji obrazu podpisanego kontenera.

W przypadku podpisywania za pomocą pary kluczy dostępne są 2 opcje:

Podpisz za pomocą lokalnej pary kluczy wygenerowanej przez Cosign.
Podpisz parą kluczy zapisaną w innym miejscu (na przykład w KMS).

Jeśli nie masz jeszcze pary kluczy, wygeneruj ją w usłudze Cosign. Więcej informacji znajdziesz w artykule na temat podpisywania za pomocą kluczy zarządzanych samodzielnie.

// Set Application Default Credentials.
$ gcloud auth application-default login 

// Generate keys using a KMS provider.
$ cosign generate-key-pair --kms <provider>://<key>

// Generate keys using Cosign.
$ cosign generate-key-pair

W powyższym przykładzie zastąp <dostawcę>://<klucz> dzięki gcpkms://projects/$PRIMUS_PROJECT_ID/locations/global/keyRings/$PRIMUS_SIGNING_KEYRING/cryptoKeys/$PRIMUS_SIGNING_KEY/cryptoKeyVersions/$PRIMUS_SIGNING_KEYVERSION

<provider> : odnosi się do używanego rozwiązania KMS
<key> : odnosi się do ścieżki klucza w KMS

Pobierz klucz publiczny do weryfikacji.

// For KMS providers.
$ cosign public-key --key <some provider>://<some key> > pub.pem

// For local key pair signing.
$ cosign public-key --key cosign.key > pub.pem

Podpisz zadanie za pomocą Cosign. Wykonaj unpadded kodowanie base64 dla klucza publicznego.

$ PUB=$(cat pub.pem | openssl base64)

// Remove spaces and trailing "=" signs.
$ PUB=$(echo $PUB | tr -d '[:space:]' | sed 's/[=]*$//')

Podpisz zadanie za pomocą Cosign z dołączonym wyeksportowanym kluczem publicznym i algorytmami podpisu.

$ IMAGE_REFERENCE=us-docker.pkg.dev/$SECUNDUS_PROJECT_ID/$SECUNDUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG

// Sign with KMS support.
$ cosign sign --key <some provider>://<some key> $IMAGE_REFERENCE \
-a dev.cosignproject.cosign/sigalg=ECDSA_P256_SHA256 \
-a dev.cosignproject.cosign/pub=$PUB

// Sign with a local key pair.
$ cosign sign --key cosign.key $IMAGE_REFERENCE \
-a dev.cosignproject.cosign/sigalg=ECDSA_P256_SHA256 \
-a dev.cosignproject.cosign/pub=$PUB

--key [WYMAGANE] wskazuje klucz podpisywania, który ma być używany. Gdy odnosisz się do klucza zarządzanego przez dostawcę KMS, postępuj zgodnie z określonym formatem URI z zespołu pomocy KMS w Sigstore. Gdy odwołujesz się do klucza wygenerowanego przez Cosign, użyj cosign.key.
$IMAGE_REFERENCE [WYMAGANE] wskazuje obraz kontenera do podpisania. Format pliku IMAGE_REFERENCE można rozpoznać po tagu lub podsumowaniu obrazu. Na przykład: us-docker.pkg.dev/$SECUNDUS_PROJECT_ID/secundus-workloads/workload-container:latest or us-docker.pkg.dev/$SECUNDUS_PROJECT_ID/secundus-workloads/workload-container[IMAGE-digest]
-a [WYMAGANE] określa adnotacje dołączone do ładunku podpisu. W przypadku obrazów kontenerów podpisanych w ramach przestrzeni poufnej do ładunku podpisu wymagane jest dołączenie klucza publicznego i algorytmów podpisu.

dev.cosignproject.cosign/sigalg TYLKO akceptuje 3 wartości:
RSASSA_PSS_SHA256: algorytm RSASSA z dopełnieniem PSS ze skrótem SHA256.
RSASSA_PKCS1V15_SHA256: algorytm RSASSA z dopełnieniem PKCS#1 w wersji 1.5 ze skrótem SHA256.
ECDSA_P256_SHA256: ECDSA na krzywej P-256 ze skrótem SHA256. Jest to również domyślny algorytm podpisu dla par kluczy wygenerowanych przez funkcję Cosign.

Prześlij podpisy do repozytorium Dockera

Podpis cosign będzie automatycznie przesyłać podpisy do określonego COSIGN_REPOSITORY.

4. Autoryzuj i uruchom zadanie

Autoryzuj zadanie

W ramach tego kroku skonfigurujemy dostawcę Workload Identity w puli Workload Identity ($PRIMUS_WORKLOAD_IDENTITY_POOL). Dla Workload Identity skonfigurowano warunki atrybutów, jak pokazano poniżej. Jednym z warunków jest weryfikacja odcisku cyfrowego podpisu obrazu zadania z odciskiem cyfrowym podpisywania klucza publicznego. W przypadku tego warunku, gdy Secundus Bank opublikuje nowy obraz zadania, Primus Bank sprawdzi kod zadania i podpisuje nowy obraz zadania bez konieczności aktualizowania zasady WIP za pomocą skrótu obrazu.

$ gcloud config set project $PRIMUS_PROJECT_ID

$ PUBLIC_KEY_FINGERPRINT=$(openssl pkey -pubin -in pub.pem -outform DER | openssl sha256 | cut -d' ' -f2)

$ 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
     && '${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com' in
     assertion.google_service_accounts
     && ['ECDSA_P256_SHA256:${PUBLIC_KEY_FINGERPRINT}']
       .exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig,sig.signature_algorithm+':'+sig.key_id))"

Uruchom zadanie

W ramach tego kroku uruchomimy to zadanie na poufnej maszynie wirtualnej. Wymagane argumenty TEE są przekazywane przy użyciu flagi metadanych. Argumenty kontenera zadania są przekazywane za pomocą funkcji „tee-cmd” tej części flagi. Zbiór zadań jest zakodowany tak, aby publikował wyniki w zadaniu $SECUNDUS_RESULT_STORAGE_BUCKET.

$ gcloud config set project $SECUNDUS_PROJECT_ID

$ gcloud compute instances create signed-container-vm \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=TERMINATE \
 --scopes=cloud-platform --zone=us-west1-b \
 --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}/${SECUNDUS_ARTIFACT_REPOSITORY}/${WORKLOAD_IMAGE_NAME}:${WORKLOAD_IMAGE_TAG}~tee-restart-policy=Never~tee-cmd="[\"count-location\",\"Seattle\",\"gs://${SECUNDUS_RESULT_STORAGE_BUCKET}/seattle-result\"]"~tee-signed-image-repos=us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}/demo"

Wyświetl wyniki

W projekcie Secundus wyświetl wyniki zadania.

$ gcloud config set project $SECUNDUS_PROJECT_ID

$ gsutil cat gs://$SECUNDUS_RESULT_STORAGE_BUCKET/seattle-result

Wynik powinien wynosić 3, ponieważ tyle osób z Seattle jest wymienionych w pliku primus_customer_list.csv.

5. Czyszczenie

Tutaj znajdziesz skrypt, którego możesz użyć do wyczyszczenia zasobów, które utworzyliśmy w ramach tego ćwiczenia. W ramach tego czyszczenia zostaną usunięte te zasoby:

Wejściowy zasobnik na dane banku Primus ($PRIMUS_INPUT_STORAGE_BUCKET).
Konto usługi banku Primus ($PRIMUS_SERVICEACCOUNT).
Artifact Registry Banku, w którym znajdują się podpisy obrazów ($PRIMUS_COSIGN_REPOSITORY).
Pula tożsamości zadań Primus Bank ($PRIMUS_WORKLOAD_IDENTITY_POOL).
Konto usługi zadań w Secundus Bank ($WORKLOAD_SERVICEACCOUNT).
Instancja Workload Compute.
Zasobnik na dane wyników Secundus Bank ($SECUNDUS_RESULT_STORAGE_BUCKET).
Artifact Registry Banku Secundus ($SECUNDUS_ARTIFACT_REGISTRY).

// run the clean up script to delete the resources created as part of this codelab.
$ ./cleanup.sh

Po zakończeniu analizy rozważ usunięcie projektu.

Otwórz konsolę Cloud Platform.
Wybierz projekt, który chcesz wyłączyć, i kliknij „Usuń”. u góry: powoduje zaplanowanie usunięcia projektu

Gratulacje

Gratulujemy ukończenia ćwiczeń z programowania.

Wiesz już, jak korzystać z funkcji obrazu podpisanego kontenera, aby poprawić łatwość obsługi Poufnej przestrzeni.

Co dalej?

Zapoznaj się z podobnymi ćwiczeniami z programowania...