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

Ćwiczenie z programowania dotyczące podpisanego kontenera

1. Omówienie

Ten warsztat jest rozszerzeniem warsztatu Pokój poufny. Obsługa podpisanego obrazu kontenera umożliwia uwierzytelnianie kontenera za pomocą poświadczonego klucza publicznego zamiast określania skrótu obrazu w polityce puli tożsamości zadań (WIP).

Co się zmieniło w przypadku obsługi podpisanych obrazów kontenera w Confidential Space:

Ulepszony interfejs użytkownika: dzięki wprowadzeniu funkcji podpisanego obrazu kontenera możemy teraz przejść od podejścia polegającego na podsumowaniu obrazu zadania do podejścia polegającego na podpisywaniu kontenera przez współpracowników lub audytorów autoryzujących obraz.

W przypadku bezpośredniego używania podsumowania obrazu właściciele zasobów muszą aktualizować swoje zasady za każdym razem, gdy autoryzują nowy obraz. Dzięki podpisom obrazów polityka zawiera odcisk palca klucza publicznego, którego odpowiedni klucz prywatny jest własnością współpracownika lub weryfikatora i służy do podpisywania zweryfikowanych obrazów.
W przypadku niektórych modeli zabezpieczeń odwoływanie się do zaufanych kluczy podpisywania obrazów jest wygodniejsze niż aktualizowanie listy nowych wartości skrótu obrazu.

Brak regresji pod względem bezpieczeństwa: podejście z wykorzystaniem sygnatury kontenera nie spowoduje regresji pod względem bezpieczeństwa w stosunku do poprzedniego podejścia z wykorzystaniem skrótu obrazu, ponieważ granice zaufania pozostają takie same. W przypadku podejścia z podpisem kontenera właściciel zasobu autoryzuje klucz weryfikacyjny, podając zaufanego skrótu klucza publicznego w zasadach WIP. Sprawdzenie autoryzacji jest wykonywane przez usługę weryfikatora uwierzytelniania i WIP. Usługa weryfikatora uwierzytelniania sprawdza, czy podpis jest powiązany z uruchomionym zbiorem zadań, a zasady WIP sprawdzają, czy klucz publiczny podany przez usługę jest autoryzowany przez zasady.

Wysoki poziom zabezpieczeń: podpisy obrazów kontenera umożliwiają delegowanie zaufania do podpisującego obraz. Określając odcisk klucza publicznego zaufanego podpisującego w zasadach uwierzytelniania, właściciel zasobu upoważnia tego podpisującego do wydawania zaświadczeń o tym, które obrazy kontenera są zgodne z zasadami. Usługa weryfikatora zaświadczeń sprawdza, czy podpis jest powiązany z bieżącym obciążeniem, a zasada sprawdza, czy klucz publiczny, który utworzył podpis, jest autoryzowany przez zasadę. Dzięki temu dodatkowa warstwa pośrednictwa zapewniana przez podpisywanie obrazów zapewnia silne zabezpieczenia w Poufnej przestrzeni.

Jedyną różnicą między tymi podejściami jest to, że to drugie korzysta z dodatkowej warstwy pośrednictwa, w której obrazy zadań są autoryzowane za pomocą klucza podpisywania. Nie powoduje to żadnych nowych luk w zabezpieczeniach, ponieważ granice zaufania pozostają takie same.

Czego się nauczysz

Z tego ćwiczenia w Codelabs dowiesz się, jak wykorzystać podpis obrazu kontenera do autoryzacji dostępu do zasobów chronionych:

Jak podpisać zweryfikowany obraz kontenera za pomocą cosign
Jak przesyłać podpisy obrazów kontenerów do rejestrów OCI w celu ich wykrywania i przechowywania
Jak skonfigurować niezbędne zasoby w chmurze na potrzeby korzystania z pokoju poufnego
Jak uruchomić zadanie w Poufnej przestrzeni z obsługą podpisanego obrazu kontenera

Ten moduł pokazuje, jak użyć przestrzeni poufnej do zdalnego uwierzytelniania obrazu kontenera podpisanego zaufanym kluczem 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ść cosigningu Sigstore;
Podstawowa znajomość Google Compute Engine ( codelab), poufnych maszyn wirtualnych, kontenerów i repozytoriów zdalnych.
Podstawowa znajomość Cloud KMS ( codelab)
Podstawowa znajomość kont usługi, federacji tożsamości zadań i warunków atrybutów.
podstawową wiedzę o Artifact Registry,
podstawową wiedzę o podpisach cyfrowych;

Role związane z poufnym pokojem z podpisanym obrazem kontenera

W tym samouczku Primus Bank będzie audytować zasoby i będzie ich właścicielem. Będzie też odpowiedzialny za:

Skonfiguruj wymagane zasoby za pomocą przykładowych danych.
Sprawdzanie kodu zadania.
Użycie polecenia cosign do podpisania 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 odpowiedzialny za:

skonfigurować wymagane zasoby do przechowywania wyniku;
pisanie kodu zadania;
Publikowanie obrazu zadania.
Uruchamianie zadań w Poufnej przestrzeni z obsługą podpisanych obrazów kontenera.

Bank Secundus opracuje i publikuje obciążenie, które będzie wysyłać zapytania do danych klientów przechowywanych w zasobniku chmurowego magazynu należącego do banku Primus. Primus Bank zweryfikuje obciążenie, podpisze obraz kontenera i skonfiguruje zasady WIP, aby zezwolić na dostęp do danych za pomocą zatwierdzonych zadań. Wynik wykonania tego zbioru zadań będzie przechowywany w zasobniku usługi Cloud Storage należącym do banku Secundus.

Materiały związane z konfiguracją pokoju poufnego

Ten warsztat z programowaniem odwołuje się do kilku zmiennych, które należy ustawić na odpowiednie wartości w projekcie GCP. Polecenia w tym CodeLab zakładają, że te zmienne zostały ustawione. (na przykład export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' można użyć do ustawienia nazwy zasobnika pamięci wejściowej banku Primus). Jeśli zmienne nazw zasobów nie zostały ustawione, zostaną wygenerowane na podstawie identyfikatora projektu GCP.

W projekcie Primus skonfiguruj te ustawienia:

$PRIMUS_INPUT_STORAGE_BUCKET: zasób, w którym przechowywany jest plik danych klienta.
$PRIMUS_WORKLOAD_IDENTITY_POOL: pula tożsamości zadań (WIP) weryfikująca 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ę weryfikatora atestu.
$PRIMUS_SERVICEACCOUNT: konto usługi, którego $PRIMUS_WORKLOAD_IDENTITY_POOL używa do uzyskiwania dostępu do zasobów chronionych. Na tym etapie ma on uprawnienia do wyświetlania danych klienta przechowywanych w zasośniku $PRIMUS_INPUT_STORAGE_BUCKET.
$PRIMUS_ENC_KEY: klucz KMS używany do szyfrowania danych przechowywanych w $PRIMUS_INPUT_STORAGE_BUCKET.

Nowe zasoby w tych ćwiczeniach z programowania:

$PRIMUS_COSIGN_REPOSITORY: repozytorium Artifact Registry do przechowywania podpisów obrazów obciążenia.
$PRIMUS_SIGNING_KEY: klucz KMS używany do podpisywania obrazu obciążenia przez audytora lub współpracowników ds. danych (np. w tym przypadku 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 zadania.
$WORKLOAD_IMAGE_TAG: tag obrazu kontenera Dockera obciążenia.
$WORKLOAD_SERVICEACCOUNT: konto usługi, które ma uprawnienia dostępu do poufnej maszyny wirtualnej, na której jest wykonywane obciążenie.
$SECUNDUS_RESULT_BUCKET: zasobnik, w którym są przechowywane wyniki zbioru zadań.

Inne materiały:

primus_customer_list.csv zawiera dane klienta. Prześlemy te dane do usługi $PRIMUS_INPUT_STORAGE_BUCKET i utworzymy zadanie, które będzie je przetwarzać.

Istniejący przepływ pracy

Gdy uruchomisz zadanie w Poufnej przestrzeni, zostanie przeprowadzony następujący proces z wykorzystaniem skonfigurowanych zasobów:

Zadanie wymaga ogólnego tokena dostępu Google do $PRIMUS_SERVICEACCOUNT z WIP. Oferuje token usługi weryfikatora autentyczności z roszczeniami dotyczącymi obciążenia i środowiska.
Jeśli roszczenia dotyczące pomiaru obciążenia w tokenie usługi weryfikatora zgodności z zasadami pasują do warunku atrybutu w WIP, zwraca token dostępu dla $PRIMUS_SERVICEACCOUNT.
Dostęp do danych klienta w zasobniku $PRIMUS_INPUT_STORAGE_BUCKET zadanie to uzyskuje za pomocą tokena dostępu do konta usługi powiązanego z kontem $PRIMUS_SERVICEACCOUNT.
Zadania wykonują operacje na tych danych.
Zadania używają konta usługi $WORKLOAD_SERVICEACCOUNT do zapisywania wyników tej operacji w zasobniku $SECUNDUS_RESULT_STORAGE_BUCKET.

Nowy przepływ pracy z obsługą podpisanych kontenerów

Obsługa podpisanych kontenerów zostanie zintegrowana z istniejącym przepływem pracy, jak pokazano poniżej. Gdy uruchamiasz zadanie w Poufnej przestrzeni z obsługą podpisanych obrazów kontenera, odbywa się następujący proces z wykorzystaniem skonfigurowanych zasobów:

Poufna przestrzeń wykrywa wszystkie podpisy kontenera powiązane z bieżącym obrazem zbioru zadań i wysyła je do weryfikatora zaświadczeń. Weryfikator weryfikuje podpis i zawiera wszystkie prawidłowe podpisy w oświadczeniach.
Zadanie wymaga ogólnego tokena dostępu Google dla $PRIMUS_SERVICEACCOUNT z WIP. Oferuje token usługi weryfikatora za pomocą oświadczenia o obciążeniu i środowisku.
Jeśli oświadczenia dotyczące podpisu kontenera w tokenie usługi weryfikatora atestu są zgodne z warunkiem atrybutu w WIP, zwraca token dostępu dla $PRIMUS_SERVICEACCOUNT.
Dostęp do danych klienta w zasobniku $PRIMUS_INPUT_STORAGE_BUCKET zadanie to uzyskuje za pomocą tokena dostępu do konta usługi powiązanego z kontem $PRIMUS_SERVICEACCOUNT.
Zadania wykonują operacje na tych danych.
Pakiet używa funkcji $WORKLOAD_SERVICEACCOUNT do zapisywania wyników tej operacji w zasobniku $SECUNDUS_RESULT_STORAGE_BUCKET.

2. Konfigurowanie zasobów Cloud

W ramach konfiguracji poufnej przestrzeni najpierw utworzysz wymagane zasoby chmury w projektach GCP banku Primus i Secundus. Oto zasoby, które zostały dodane do tego ćwiczenia z programowania:

W projekcie Primus:

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

W projekcie Secundus nie ma nowych zasobów. Po skonfigurowaniu tych zasobów utwórz konto usługi dla zadań z wymaganymi rolami i uprawnieniami. Następnie utworzysz obraz zbioru zadań, a audytor, bank Primus, podpisze obraz zbioru zadań. Zadanie zostanie następnie autoryzowane przez współpracowników ds. danych (w tym przypadku jest to bank Primus), a operator zadań (w tym przypadku jest to bank Secundus) będzie je wykonywać.

W ramach konfiguracji poufnej przestrzeni utworzysz wymagane zasoby chmury w projektach GCP Primus i Secundus.

Zanim zaczniesz

Aby pobrać wymagane skrypty używane w ramach tego Codelab, sklonuj to repozytorium, używając tego polecenia.

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

Zmień katalog tego Codelab.

cd confidential-space/codelabs/signed_container_codelab/scripts

Sprawdź, czy masz skonfigurowane 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 dla wymienionych powyżej nazw zasobów za pomocą tego polecenia. Możesz zastąpić nazwy zasobów za pomocą tych zmiennych (np. export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket').
Uruchom poniższy skrypt, aby ustawić pozostałe nazwy zmiennych na wartości oparte na identyfikatorze projektu.

source config_env.sh

Zainstaluj współpodpis, 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 czynności zostaną utworzone wymienione poniżej zasoby:

Zasobnik Cloud Storage ($PRIMUS_INPUT_STORAGE_BUCKET) do przechowywania zaszyfrowanego pliku z danymi klienta banku Primus.
Klucz szyfrowania ($PRIMUS_ENC_KEY) i kluczyk ($PRIMUS_ENC_KEYRING) w KMS do szyfrowania pliku danych banku Primus.
puli tożsamości zadań ($PRIMUS_WORKLOAD_IDENTITY_POOL) do weryfikowania roszczeń na podstawie warunków atrybutów skonfigurowanych w dostawcy;
Konto usługi ($PRIMUS_SERVICEACCOUNT) przypisane do wspomnianej puli tożsamości zadań ($PRIMUS_WORKLOAD_IDENTITY_POOL) z tymi uprawnieniami dostępu IAM:
roles/cloudkms.cryptoKeyDecrypter, aby odszyfrować dane za pomocą klucza KMS.
objectViewer, aby odczytać dane z zasobnika Cloud Storage.
roles/iam.workloadIdentityUser, aby połączyć to konto 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 czynności zostaną utworzone te zasoby:

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

./setup_secundus_bank_resources.sh

3. Tworzenie i podpisywanie zadań

Tworzenie konta usługi dotyczącego obciążenia

Teraz utwórz konto usługi dla zadania 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ą, która wykonuje obciążenie.

To konto usługi zadania ($WORKLOAD_SERVICEACCOUNT) będzie mieć przypisane te role:
confidentialcomputing.workloadUser, aby uzyskać token atestacji
logging.logWriter, aby zapisywać logi w Cloud Logging.
objectViewer do odczytu danych z zasobnika chmury $PRIMUS_INPUT_STORAGE_BUCKET.
objectAdmin, aby zapisać wyniki zbioru zadań w zasobniku Cloud Storage $SECUNDUS_RESULT_STORAGE_BUCKET.

./create_workload_serviceaccount.sh

Tworzenie zbioru zadań

W ramach tego kroku utworzysz obraz Dockera zadania. Zadanie wykorzystane w tym Codelab to prosta aplikacja Go oparta na interfejsie wiersza poleceń, która zlicza klientów (z danych klientów banku Primus) z podanej w argumencie lokalizacji geograficznej. Uruchom ten skrypt, aby utworzyć zadanie, w ramach którego wykonywane są te czynności:

Utwórz Artifact Registry($SECUNDUS_ARTIFACT_REGISTRY) należącą do banku Secundus.
Zaktualizuj kod zbioru zadań, podając nazwy wymaganych zasobów. Tutaj znajdziesz kod obciążenia użyty w tym ćwiczeniu.
Utwórz binarne wydanie Go i plik Dockerfile, aby skompilować obraz Dockera kodu zadania. Tutaj znajduje się plik Dockerfile użyty w tym ćwiczeniu.
Utwórz i opublikuj obraz Dockera w repozytorium Artifact Registry ($SECUNDUS_ARTIFACT_REGISTRY) należącym do banku Secundus.
Przyznaj usłudze $WORKLOAD_SERVICEACCOUNT uprawnienie do odczytu w przypadku usługi $SECUNDUS_ARTIFACT_REGISTRY. Jest to konieczne, aby kontener zadania pobierał obraz Dockera zadania z rejestru artefaktów.

./create_workload.sh

Podpisywanie zbioru zadań

Użyjemy narzędzia Cosign do podpisania obrazu obciążenia. Domyślnie podpisy są przechowywane w tym samym repozytorium co obraz, który jest podpisywany. Aby określić inne repozytorium dla podpisów, możesz ustawić zmienną środowiskową COSIGN_REPOSITORY.

Jako przykład użyjemy rejestru artefaktów. Możesz też wybrać inne rejestry oparte na OCI, takie jak Docker Hub czy AWS CodeArtifact.

utworzyć 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 w KMS pęk kluczy i klucz do podpisywania obrazu zbioru zadań.

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 wymagana jest pełna nazwa obrazu, np. $LOCATION/$PROJECT/$REPOSITORY/$IMAGE_NAME. Do repozytorium możesz przesłać dowolny obraz kontenera na potrzeby przechowywania podpisu.

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

Przypisz do konta usługi $WORKLOAD_SERVICEACCOUNT rolę Przeglądający w gabinecie $PRIMUS_COSIGN_REPOSITORY. Umożliwia to Confidential Space wykrywanie wszystkich podpisów obrazów kontenera 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 potężne narzędzie z wieloma funkcjami podpisywania. W naszym przypadku Cosign musi tylko podpisać parą kluczy. Podpisywanie bez klucza w przypadku funkcji podpisanego obrazu kontenera nie jest obsługiwane.

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

Podpisz za pomocą lokalnej pary kluczy wygenerowanej przez Cosign.
podpisywanie za pomocą pary kluczy przechowywanej w innym miejscu (np. w KMS);

Jeśli nie masz pary kluczy, wygeneruj ją w usłudze Cosign. Więcej informacji znajdziesz w artykule Podpisywanie przy użyciu kluczy zarządzanych samodzielnie. W tym miejscu podajemy obie metody (lokalną i za pomocą dostawcy KMS) generowania pary kluczy i podpisywania zbioru zadań. Aby podpisać kontener zbioru zadań, użyj jednej z tych metod.

// 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 tekście zastąp <provider>://<key> przez 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 przez Ciebie rozwiązania KMS.
<key> : odnosi się do ścieżki klucza w KMS.

Pobierz klucz publiczny na potrzeby 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

Zaloguj się, aby podpisać zadanie przy użyciu 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 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 [REQUIRED] określa, którego klucza podpisywania należy użyć. W przypadku klucza zarządzanego przez dostawcę KMS należy przestrzegać formatu identyfikatora URI podanego w dokumentacji Sigstore dotyczącej KMS. W przypadku klucza wygenerowanego przez Cosign użyj zamiast tego klucza cosign.key.
$IMAGE_REFERENCE [WYMAGANE] określa, który obraz kontenera ma zostać podpisany. Format IMAGE_REFERENCE można zidentyfikować na podstawie tagu lub skrótu obrazu. 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 [REQUIRED] określa adnotacje dołączone do ładunku podpisu. W przypadku obrazów kontenera podpisanych w Confidential Space klucz publiczny i algorytmy podpisu muszą być dołączone do danych podpisu.

Atrybut dev.cosignproject.cosign/sigalg ONLY może przyjmować 3 wartości:
RSASSA_PSS_SHA256: algorytm RSASSA z buforem danych PSS i skrótem SHA256.
RSASSA_PKCS1V15_SHA256: algorytm RSASSA z wypeł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 też domyślny algorytm podpisywania w przypadku par kluczy utworzonych przez Cosign.

Przesyłanie podpisów do repozytorium Dockera

Cosign sign automatycznie prześle podpisy do określonego COSIGN_REPOSITORY.

4. Autoryzowanie i uruchamianie zbioru zadań

Autoryzowanie zbioru zadań

W ramach tego kroku skonfigurujemy dostawcę tożsamości zadań w ramach puli tożsamości zadań ($PRIMUS_WORKLOAD_IDENTITY_POOL). Dla tożsamości zadań skonfigurowane są warunki atrybutów, jak pokazano poniżej. Jednym z warunków jest weryfikacja odcisku palca podpisu obrazu obciążenia w porównaniu z odciskiem palca klucza publicznego. Dzięki temu atrybucie, gdy bank Secundus udostępni nowy obraz obciążenia, bank Primus sprawdzi kod obciążenia i podpisze nowy obraz obciążenia bez konieczności aktualizowania zasad WIP za pomocą podsumowania 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

Na tym etapie będziemy wykonywać zadanie w maszynie wirtualnej Confidential. Wymagane argumenty TEE są przekazywane za pomocą flagi metadanych. Argumenty dla kontenera zbioru zadań są przekazywane za pomocą części flagi „tee-cmd”. Zadanie jest zaprogramowane tak, aby opublikować wynik 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"

Wyświetl wyniki

W projekcie Secundus wyświetl wyniki obciążenia.

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óry możesz wykorzystać do wyczyszczenia zasobów utworzonych w ramach tego ćwiczenia. W ramach tego czyszczenia zostaną usunięte te zasoby:

Zasobnik wejściowy banku Primus ($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 Workload należące do Secundus Bank ($WORKLOAD_SERVICEACCOUNT).
Instancja obliczeniowa zbioru zadań.
Zasobnik wyników banku Secundus ($SECUNDUS_RESULT_STORAGE_BUCKET).
Rejestr artefaktów banku Secundus ($SECUNDUS_ARTIFACT_REGISTRY).
Maszyna wirtualna zadań banku Secundus ($WORKLOAD_VM).

./cleanup.sh

Gdy skończysz eksplorować, możesz usunąć projekt.

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

Gratulacje

Gratulacje! Udało Ci się ukończyć zajęcia.

Dowiedz się, jak wykorzystać funkcję podpisanego obrazu kontenera, aby zwiększyć użyteczność przestrzeni poufnej.

Co dalej?

Sprawdź te podobne laboratoria programistyczne…