Ćwiczenie z programowania dotyczące podpisanego kontenera

1. Przegląd

To ćwiczenie jest kontynuacją ćwiczenia dotyczącego Poufnej przestrzeni. Obsługa podpisanych obrazów kontenerów z opcją uwierzytelniania kontenera za pomocą atestowanego klucza publicznego zamiast określania skrótu obrazu w zasadach puli tożsamości zadań.

Co się zmieniło w obsłudze podpisanych obrazów kontenerów w Poufnej przestrzeni:

Ulepszona użyteczność: dzięki wprowadzeniu funkcji podpisywania obrazów kontenerów możemy teraz przejść od podejścia opartego na skrócie obrazu zadania do podejścia opartego na sygnaturze kontenera w przypadku współpracowników lub audytorów autoryzujących obraz.

W przypadku bezpośredniego używania skrótów obrazów właściciele zasobów muszą aktualizować swoje zasady za pomocą skrótu obrazu za każdym razem, gdy autoryzują nowy obraz. Dzięki użyciu sygnatur obrazów zasady zawierają odcisk klucza publicznego, którego odpowiedni klucz prywatny jest własnością współpracownika lub audytora i jest używany do podpisywania sprawdzanych obrazów.
W przypadku niektórych modeli zabezpieczeń wygodniejsze jest odwoływanie się do zaufanego klucza podpisywania obrazów 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 poprzednim podejściem do skrótu obrazu, ponieważ granice zaufania pozostają takie same. W przypadku podejścia opartego na sygnaturze kontenera właściciel zasobu autoryzuje klucz weryfikacyjny, określając odcisk cyfrowy zaufanego klucza publicznego w zasadach WIP. Sprawdzanie autoryzacji jest przeprowadzane przez usługę weryfikacji atestów i WIP. Usługa weryfikacji atestów sprawdza, czy sygnatura jest powiązana z uruchomionym obciążeniem, a zasady WIP sprawdzają, czy klucz publiczny potwierdzony przez usługę jest autoryzowany przez zasady.

Wysoki poziom bezpieczeństwa: używanie podpisów obrazów kontenerów pozwala przekazać pewną część zaufania do osoby podpisującej obraz. Określając odcisk klucza publicznego zaufanego sygnatariusza w zasadach atestu, właściciel zasobu upoważnia tego sygnatariusza do tworzenia adnotacji, które wskazują, które obrazy kontenerów spełniają zasady. Usługa weryfikacji atestu sprawdza, czy podpis jest powiązany z uruchomionym obciążeniem, a zasady sprawdzają, czy klucz publiczny, który utworzył podpis, jest autoryzowany przez zasady. Dzięki temu dodatkowa warstwa pośrednia, którą zapewnia podpisywanie obrazów, zachowuje silne gwarancje bezpieczeństwa Poufnej przestrzeni.

Jedyną różnicą między tymi podejściami jest to, że w drugim przypadku używana jest dodatkowa warstwa pośrednia, w której obrazy obciążeń są autoryzowane za pomocą klucza podpisywania. Nie wprowadza to żadnych 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ący audytowi 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 poufnej przestrzeni
Jak uruchomić zadanie w Poufnej przestrzeni z obsługą podpisanego obrazu kontenera

Z tego modułu dowiesz się, jak używać Poufnej przestrzeni do poświadczenia zdalnego obrazu kontenera podpisanego zaufanym kluczem, który jest uruchomiony w Google Compute Engine.

Czego potrzebujesz

Ukończ ćwiczenia z programowania dotyczące Poufnej przestrzeni.
Projekt Google Cloud Platform
przeglądarkę, np. Chrome lub Firefox;
Znajomość standardowych edytorów tekstu systemu Linux, takich jak Vim, Emacs lub Nano.
ma podstawową wiedzę o Sigstore cosign;
Podstawowa wiedza o Google Compute Engine ( codelab), maszynach wirtualnych poufnych, kontenerach i repozytoriach zdalnych.
Podstawowa wiedza o Cloud KMS ( codelab)
Podstawowa wiedza o kontach usługi, federacji tożsamości zadań i warunkach atrybutów.
podstawową wiedzę o Artifact Registry;
Podstawowa wiedza o podpisach cyfrowych

Role w poufnej przestrzeni z podpisanym obrazem kontenera

W tym laboratorium Primus Bank będzie audytorem i właścicielem zasobu, który będzie odpowiedzialny za:

Konfigurowanie wymaganych zasobów za pomocą przykładowych danych.
Sprawdzanie kodu zadania.
Używanie cosign do podpisywania obrazu zadania.
przesyłanie podpisu do repozytorium,
Konfigurowanie zasad WIP w celu ochrony danych klientów.

Secundus Bank będzie autorem i operatorem zadania oraz będzie odpowiadać za:

skonfigurowanie wymaganych zasobów do przechowywania wyniku;
Pisanie kodu zadania.
Publikowanie obrazu zadania.
Uruchamianie obciążenia w Poufnej przestrzeni z obsługą podpisanych obrazów kontenerów.

Bank Secundus opracuje i opublikuje obciążenie, które będzie wysyłać zapytania do danych klientów przechowywanych w zasobniku pamięci w chmurze należącym do banku Primus. Bank Primus przeprowadzi audyt zadania, podpisze obraz kontenera i skonfiguruje zasady puli tożsamości zadań, 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 zaangażowane w konfigurację Poufnej przestrzeni

W tym samouczku pojawia się kilka zmiennych, które należy ustawić na odpowiednie wartości dla projektu GCP. Polecenia w tym samouczku zakładają, że te zmienne zostały ustawione. (na przykład export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' może służyć do ustawienia nazwy wejściowego zasobnika pamięci banku Primus). Jeśli zmienne resource-names nie zostały ustawione, zostaną wygenerowane na podstawie identyfikatora projektu GCP.

W projekcie Primus skonfiguruj te ustawienia:

$PRIMUS_INPUT_STORAGE_BUCKET: zasobnik, w którym jest przechowywany plik danych klienta.
$PRIMUS_WORKLOAD_IDENTITY_POOL: pula tożsamości zadań, która weryfikuje roszczenia.
$PRIMUS_WIP_PROVIDER: dostawca puli tożsamości zadań, który zawiera warunek autoryzacji do użycia w przypadku tokenów podpisanych przez usługę weryfikacji atestu.
$PRIMUS_SERVICEACCOUNT: konto usługi, którego $PRIMUS_WORKLOAD_IDENTITY_POOL używa do uzyskiwania dostępu do chronionych zasobów. Na tym etapie ma uprawnienia do wyświetlania danych klientów 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:

$PRIMUS_COSIGN_REPOSITORY: Artifact Registry do przechowywania podpisów obrazów obciążeń.
$PRIMUS_SIGNING_KEY: klucz KMS używany do podpisywania obrazu obciążenia przez audytora lub współpracowników w zakresie danych (w tym przypadku np.bank Primus).

W projekcie Secundus skonfiguruj te ustawienia:

$SECUNDUS_ARTIFACT_REGISTRY: rejestr artefaktów, do którego zostanie przesłany obraz Dockera obciążenia.
$WORKLOAD_IMAGE_NAME: nazwa obrazu Dockera obciążenia.
$WORKLOAD_IMAGE_TAG: tag obrazu Dockera obciążenia.
$WORKLOAD_SERVICEACCOUNT: konto usługi, które ma uprawnienia dostępu do maszyny wirtualnej poufnej, na której działa zadanie.
$SECUNDUS_RESULT_BUCKET: zasobnik, w którym są przechowywane wyniki zbioru zadań.

Inne materiały:

primus_customer_list.csv zawiera dane klientów. Prześlemy te dane do $PRIMUS_INPUT_STORAGE_BUCKET i utworzymy obciążenie, które będzie wykonywać na nich zapytania.

Istniejący przepływ pracy

Gdy uruchomisz zadanie w Poufnej przestrzeni, przy użyciu skonfigurowanych zasobów zostanie przeprowadzony ten proces:

Zadanie wysyła z WIP żądanie ogólnego tokena dostępu do Google dla usługi $PRIMUS_SERVICEACCOUNT. Oferuje token usługi weryfikacji atestu z deklaracjami dotyczącymi obciążenia i środowiska.
Jeśli roszczenia dotyczące pomiaru obciążenia w tokenie usługi weryfikacji zaświadczeń pasują do warunku atrybutu w tożsamości puli tożsamości, zwraca token dostępu do $PRIMUS_SERVICEACCOUNT..
Obciążenie używa tokena dostępu konta usługi powiązanego z $PRIMUS_SERVICEACCOUNT, aby uzyskać dostęp do danych klienta w zasobniku $PRIMUS_INPUT_STORAGE_BUCKET.
Zadanie wykonuje operację na tych danych.
Zadanie używa konta usługi $WORKLOAD_SERVICEACCOUNT do zapisywania wyników tej operacji w zasobniku $SECUNDUS_RESULT_STORAGE_BUCKET.

Nowy proces z obsługą podpisanych kontenerów

Obsługa podpisanych kontenerów zostanie zintegrowana z dotychczasowym procesem, jak pokazano poniżej. Gdy uruchamiasz obciążenie w Poufnej przestrzeni z obsługą podpisanych obrazów kontenerów, przy użyciu skonfigurowanych zasobów przebiega ten proces:

Poufna przestrzeń wykrywa wszystkie podpisy kontenerów powiązane z aktualnie uruchomionym obrazem zbioru zadań i wysyła je do weryfikatora atestu. Weryfikator atestu weryfikuje podpis i uwzględnia w roszczeniach atestu wszystkie prawidłowe podpisy.
Zadanie wysyła z WIP żądanie ogólnego tokena dostępu do Google dla usługi $PRIMUS_SERVICEACCOUNT. Oferuje token usługi weryfikacji atestu z deklaracjami dotyczącymi obciążenia i środowiska.
Jeśli roszczenia dotyczące podpisu kontenera w tokenie usługi weryfikacji atestu są zgodne z warunkiem atrybutu w profilu tożsamości obciążenia, usługa zwraca token dostępu do $PRIMUS_SERVICEACCOUNT.
Obciążenie używa tokena dostępu konta usługi powiązanego z $PRIMUS_SERVICEACCOUNT, aby uzyskać dostęp do danych klienta w zasobniku $PRIMUS_INPUT_STORAGE_BUCKET.
Zadanie wykonuje operację na tych danych.
Obciążenie używa funkcji $WORKLOAD_SERVICEACCOUNT do zapisywania wyników tej operacji w zasobniku $SECUNDUS_RESULT_STORAGE_BUCKET.

2. Konfigurowanie zasobów w chmurze

W ramach konfiguracji Poufnej przestrzeni najpierw utworzysz wymagane zasoby w projektach GCP banków Primus i Secundus. Oto nowe zasoby w tym ćwiczeniu:

W projekcie Primus:

Klucz podpisywania KMS używany do podpisywania zadań Secundus po sprawdzeniu kodu.
repozytorium Artifact Registry do przechowywania podpisów Cosign,

W projekcie Secundus nie ma nowych zasobów. Po skonfigurowaniu tych zasobów utworzysz konto usługi dla obciążenia z wymaganymi rolami i uprawnieniami. Następnie utworzysz obraz zbioru zadań, a audytor, bank Primus, go podpisze. Zadanie zostanie następnie autoryzowane przez podmioty współpracujące w zakresie danych (w tym przypadku bank Primus), a operator zadania (w tym przypadku bank Secundus) uruchomi zadanie.

W ramach konfiguracji Poufnej przestrzeni utworzysz wymagane zasoby w chmurze w projektach GCP Primus i Secundus.

Zanim zaczniesz

Sklonuj to repozytorium za pomocą poniższego polecenia, aby uzyskać wymagane skrypty używane w tym laboratorium.

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

Zmień katalog tego ćwiczenia.

cd confidential-space/codelabs/signed_container_codelab/scripts

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>

Ustaw zmienne nazw zasobów wymienione powyżej za pomocą tego polecenia. 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 na wartości oparte na identyfikatorze projektu w przypadku nazw zasobów.

source config_env.sh

Zainstaluj cosign, postępując zgodnie z instrukcjami podanymi tutaj.

Konfigurowanie zasobów banku Primus

W ramach tego kroku skonfigurujesz wymagane zasoby w chmurze dla banku Primus. Aby skonfigurować zasoby dla banku Primus, uruchom ten skrypt. W ramach tych działań 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 weryfikowania roszczeń na podstawie warunków atrybutów skonfigurowanych u jej dostawcy.
Konto usługi ($PRIMUS_SERVICEACCOUNT) dołączone do wspomnianej wyżej puli tożsamości zadań ($PRIMUS_WORKLOAD_IDENTITY_POOL) z tymi uprawnieniami IAM:
roles/cloudkms.cryptoKeyDecrypter – odszyfrowanie danych za pomocą klucza KMS.
objectViewer – odczytywać dane z zasobnika Cloud Storage.
roles/iam.workloadIdentityUser – do połączenia tego konta usługi z pulą tożsamości zadań.

./setup_primus_bank_resources.sh

Konfigurowanie zasobów banku Secundus

W ramach tego kroku skonfigurujesz wymagane zasoby w chmurze dla banku Secundus. Aby skonfigurować zasoby dla banku Secundus, uruchom ten skrypt. W ramach tych kroków zostaną utworzone te zasoby:

Zasobnik Cloud Storage ($SECUNDUS_RESULT_STORAGE_BUCKET) do przechowywania wyników wykonania zbioru zadań przez bank Secundus.

./setup_secundus_bank_resources.sh

3. Tworzenie i podpisywanie zadania

Tworzenie konta usługi zadania

Teraz utworzysz konto usługi dla obciążenia z wymaganymi rolami i uprawnieniami. Uruchom ten skrypt, aby utworzyć konto usługi obciążenia w projekcie banku Secundus. To konto usługi będzie używane przez maszynę wirtualną, na której działa obciążenie.

To konto usługi obciążenia ($WORKLOAD_SERVICEACCOUNT) będzie miało przypisane te role:
confidentialcomputing.workloadUser, aby uzyskać token atestu.
logging.logWriter – zapisywanie logów w Cloud Logging.
objectViewer – odczytywanie danych z zasobnika Cloud Storage $PRIMUS_INPUT_STORAGE_BUCKET.
objectAdmin, aby zapisać wynik zbioru zadań w zasobniku Cloud Storage $SECUNDUS_RESULT_STORAGE_BUCKET.

./create_workload_serviceaccount.sh

Tworzenie zadania

W ramach tego kroku utworzysz obraz Dockera zbioru zadań. Obciążenie użyte w tym module to prosta aplikacja w Go oparta na interfejsie CLI, która zlicza klientów (na podstawie danych klientów banku Primus) z podanej w argumencie lokalizacji geograficznej. Uruchom ten skrypt, aby utworzyć zadanie, w którym wykonywane są te czynności:

Utwórz Artifact Registry($SECUNDUS_ARTIFACT_REGISTRY) należący do banku Secundus.
Zaktualizuj kod zbioru zadań, podając nazwy wymaganych zasobów. Tutaj znajdziesz kod zadania użyty w tym ćwiczeniu z programowania.
Skompiluj plik binarny Go i utwórz plik Dockerfile do utworzenia obrazu Dockera z kodem obciążenia. Tutaj znajdziesz plik Dockerfile użyty w tych ćwiczeniach z programowania.
Utwórz obraz Dockera i opublikuj go w Artifact Registry ($SECUNDUS_ARTIFACT_REGISTRY) należącym do banku Secundus.
Przyznaj usłudze $WORKLOAD_SERVICEACCOUNT uprawnienia do odczytu $SECUNDUS_ARTIFACT_REGISTRY. Jest to potrzebne, aby kontener zbioru zadań mógł pobrać obraz Dockera zbioru zadań z Artifact Registry.

./create_workload.sh

Podpisywanie zadania

Do podpisania obrazu obciążenia użyjemy Cosign. Cosign domyślnie przechowuje podpisy w tym samym repozytorium co obraz, który podpisuje. Aby określić inne repozytorium podpisów, możesz ustawić zmienną środowiskową COSIGN_REPOSITORY.

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

Utwórz repozytorium Dockera w Artifact Registry.

gcloud config set project $PRIMUS_PROJECT_ID

gcloud artifacts repositories create $PRIMUS_COSIGN_REPOSITORY \
  --repository-format=docker --location=${PRIMUS_PROJECT_REPOSITORY_REGION}

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=${PRIMUS_PROJECT_LOCATION}

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

W przypadku Artifact Registry oczekiwana jest pełna nazwa obrazu, np. $LOCATION/$PROJECT/$REPOSITORY/$IMAGE_NAME. Do repozytorium możesz przesłać dowolny obraz kontenera, aby przechowywać w nim sygnatury.

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

Przypisz rolę Przeglądający w repozytorium $PRIMUS_COSIGN_REPOSITORY do konta usługi $WORKLOAD_SERVICEACCOUNT. Dzięki temu usługa Poufna przestrzeń może wykrywać wszystkie podpisy obrazów kontenerów przesłane 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, aby Cosign podpisywał za pomocą pary kluczy. Podpisywanie bez użycia klucza Cosign nie jest obsługiwane w przypadku tej funkcji podpisywania obrazów kontenerów.

Podczas podpisywania za pomocą pary kluczy masz 2 opcje:

Podpisywanie za pomocą lokalnej pary kluczy wygenerowanej przez Cosign.
Podpisywanie za pomocą pary kluczy przechowywanej w innym miejscu (np. w usłudze KMS).

Jeśli nie masz pary kluczy, wygeneruj ją w Cosign. Więcej informacji znajdziesz w sekcji Podpisywanie za pomocą kluczy zarządzanych samodzielnie. Podaliśmy tutaj 2 sposoby generowania pary kluczy i podpisywania obciążenia (lokalnie i za pomocą dostawcy KMS). Aby podpisać kontener obciążenia, skorzystaj z jednego z nich.

// 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 <provider>://<key> ciągiem znaków 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ą narzędzia Cosign. Wykonaj niedopełnione kodowanie base64 klucza publicznego.

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

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

Podpisz obciążenie za pomocą narzędzia Cosign z dołączonymi 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 [REQUIRED] określa, którego klucza podpisywania należy użyć. W przypadku klucza zarządzanego przez dostawcę KMS używaj formatu URI podanego w sekcji Obsługa KMS w Sigstore. W przypadku klucza wygenerowanego przez Cosign użyj cosign.key.
$IMAGE_REFERENCE [REQUIRED] określa obraz kontenera do podpisania. Format IMAGE_REFERENCE można określić na podstawie tagu lub skrótu 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]
– [REQUIRED] określa adnotacje dołączone do ładunku podpisu. W przypadku podpisanych obrazów kontenerów Poufnej przestrzeni do ładunku podpisu muszą być dołączone klucz publiczny i algorytmy podpisu.

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

Przesyłanie podpisów do repozytorium Dockera

Cosign sign automatycznie przesyła podpisy do określonego COSIGN_REPOSITORY.

4. Autoryzowanie i uruchamianie zbioru zadań

Autoryzowanie zadania

W ramach tego kroku skonfigurujemy dostawcę tożsamości do Workload Identity w puli tożsamości zadań ($PRIMUS_WORKLOAD_IDENTITY_POOL). Dla Workload Identity skonfigurowane są warunki atrybutów, jak pokazano poniżej. Jednym z warunków jest sprawdzenie odcisku palca podpisu obrazu zadania z odciskiem palca klucza publicznego podpisywania. Dzięki temu warunkowi atrybutu, gdy Secundus Bank opublikuje nowy obraz obciążenia, Primus Bank przeprowadzi audyt kodu obciążenia i podpisze nowy obraz obciążenia bez konieczności aktualizowania zasad 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))"

Uruchamianie zadania

W ramach tego kroku uruchomimy zadanie na poufnej maszynie wirtualnej. Wymagane argumenty TEE są przekazywane za pomocą flagi metadanych. Argumenty kontenera zbioru zadań są przekazywane za pomocą części „tee-cmd” flagi. Zbiór zadań jest zakodowany tak, aby publikować wyniki w $SECUNDUS_RESULT_STORAGE_BUCKET.

gcloud compute instances create ${WORKLOAD_VM} \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=MIGRATE \
 --scopes=cloud-platform \
 --zone=${SECUNDUS_PROJECT_ZONE} \
 --project=${SECUNDUS_PROJECT_ID} \
 --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"

Pokaż 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 usunięcia zasobów utworzonych w ramach tego ćwiczenia z programowania. W ramach tego czyszczenia zostaną usunięte te zasoby:

Zasobnik wejściowy Primus Bank ($PRIMUS_INPUT_STORAGE_BUCKET).
Konto usługi banku Primus ($PRIMUS_SERVICEACCOUNT).
Rejestr artefaktów Primus Bank, który zawiera podpisy obrazów ($PRIMUS_COSIGN_REPOSITORY).
Pula tożsamości zadań Primus Bank ($PRIMUS_WORKLOAD_IDENTITY_POOL).
Konto usługi zadania banku Secundus ($WORKLOAD_SERVICEACCOUNT).
Instancja obliczeniowa zbioru zadań.
Zasobnik na wyniki Secundus Bank ($SECUNDUS_RESULT_STORAGE_BUCKET).
Artifact Registry w Secundus Bank ($SECUNDUS_ARTIFACT_REGISTRY).
Maszyna wirtualna z obciążeniem Secundus Bank ($WORKLOAD_VM).

./cleanup.sh

Jeśli skończysz eksplorowanie, rozważ usunięcie projektu.

Otwórz konsolę Cloud Platform.
Wybierz projekt, który chcesz wyłączyć, a następnie kliknij „Usuń” u góry. Spowoduje to zaplanowanie usunięcia projektu.

Gratulacje

Gratulacje! Udało Ci się ukończyć ćwiczenie w Codelabs.

Dowiedzieliśmy się, jak wykorzystać funkcję podpisanego obrazu kontenera, aby zwiększyć użyteczność Poufnej przestrzeni.

Co dalej?

Sprawdź te podobne ćwiczenia...