Эта страница переведена с помощью Cloud Translation API.

Кодовая лаборатория подписанного образа контейнера

1. Обзор

Эта кодовая лаборатория основана на кодовой лаборатории Confidential Space . Поддержка подписанного образа контейнера дает возможность аутентифицировать контейнер с использованием подтвержденного открытого ключа вместо указания дайджеста образа в политике пула идентификации рабочей нагрузки (WIP).

Что изменилось с поддержкой подписанных образов контейнеров в Confidential Space:

Повышенное удобство использования. С появлением функции подписанного образа контейнера мы теперь можем перейти от подхода к дайджесту образа рабочей нагрузки к подходу к подписи контейнера для соавторов/аудиторов, авторизующих образ.

При непосредственном использовании дайджестов изображений владельцы ресурсов должны обновлять свои политики, добавляя дайджесты изображений каждый раз, когда они авторизуют новое изображение. Используя подписи изображений, политика содержит отпечаток открытого ключа, соответствующий закрытый ключ которого принадлежит соавтору/аудитору и используется для подписи проверяемых изображений.
Для некоторых моделей безопасности ссылка на доверенный ключ подписи образа более удобна, чем обновление списка новых значений дайджеста образа.

Никакой регрессии безопасности: этот подход к подписи контейнера не приведет к снижению безопасности по сравнению с предыдущим подходом дайджеста образа, поскольку границы доверия остаются прежними. При использовании подписи контейнера владелец ресурса авторизует ключ проверки, указывая отпечаток доверенного открытого ключа в политике WIP, а проверка авторизации выполняется службой проверки аттестации и WIP; Служба проверки аттестации проверяет связь подписи с выполняемой рабочей нагрузкой, а политика WIP проверяет, авторизован ли открытый ключ, заявленный службой, политикой.

Надежная безопасность: использование подписей образов контейнеров позволяет делегировать некоторую степень доверия подписавшему образ. Указывая отпечаток открытого ключа доверенного подписывающего лица в политике аттестации, владелец ресурса разрешает этому подписывающему лицу давать подтверждение того, какие образы контейнеров соответствуют политике. Служба проверки аттестации проверяет связь подписи с выполняемой рабочей нагрузкой, а политика проверяет, авторизован ли открытый ключ, создавший подпись, политикой. Благодаря этому дополнительный уровень косвенности, обеспечиваемый подписью образа, обеспечивает надежные гарантии безопасности конфиденциального пространства.

Единственное различие между этими подходами заключается в том, что последний подход использует дополнительный уровень косвенности, при котором образы рабочей нагрузки авторизуются с помощью ключа подписи. Это не создает никаких новых уязвимостей безопасности, поскольку границы доверия остаются прежними.

Что вы узнаете

В этой лабораторной работе вы узнаете, как использовать подпись образа контейнера для авторизации доступа к защищенным ресурсам:

Как подписать проверенный образ контейнера с помощью cosign
Как загрузить подписи образов контейнеров в реестры OCI для обнаружения и хранения подписей
Как настроить необходимые облачные ресурсы для работы Confidential Space
Как запустить рабочую нагрузку в конфиденциальном пространстве с поддержкой подписанного образа контейнера

В этой лаборатории кода показано, как использовать Confidential Space для удаленной проверки образа контейнера, подписанного доверенным ключом, работающего в Google Compute Engine.

Что вам понадобится

Полная лаборатория кода Confidential Space
Проект облачной платформы Google
Браузер, например Chrome или Firefox.
Знакомство со стандартными текстовыми редакторами Linux, такими как Vim, Emacs или Nano.
Базовые знания косайна Sigstore.
Базовые знания Google Compute Engine ( кодовая лаборатория ), конфиденциальной виртуальной машины , контейнеров и удаленных репозиториев.
Базовые знания Cloud KMS ( codelab )
Базовые знания об учетных записях служб , федерации удостоверений рабочей нагрузки и условиях атрибутов .
Базовые знания реестра артефактов
Базовые знания цифровых подписей.

Роли, участвующие в конфиденциальном пространстве с подписанным образом контейнера

В этой кодовой лаборатории Примус Банк будет выступать в роли аудитора и владельца ресурса, который будет отвечать за следующее:

Настройка необходимых ресурсов с помощью примеров данных.
Аудит кода рабочей нагрузки.
Использование cosign для подписи образа рабочей нагрузки.
Загрузка подписи в репозиторий.
Настройка политики WIP для защиты данных клиентов.

Secundus Bank будет автором и оператором рабочей нагрузки и будет отвечать за:

Настройка необходимых ресурсов для хранения результата.
Написание кода рабочей нагрузки.
Публикация изображения рабочей нагрузки.
Запуск рабочей нагрузки в конфиденциальном пространстве с поддержкой подписанных образов контейнеров.

Secundus Bank разработает и опубликует рабочую нагрузку, которая будет запрашивать данные клиентов, хранящиеся в облачном хранилище и принадлежащие Primus Bank. Примус Банк проведет аудит рабочей нагрузки, подпишет образ контейнера и настроит политики WIP, чтобы разрешить доступ к своим данным одобренным рабочим нагрузкам. Результат выполнения этой рабочей нагрузки будет храниться в облачном хранилище, принадлежащем банку Secundus.

Ресурсы, участвующие в настройке конфиденциального пространства

Эта кодовая лаборатория ссылается на ряд переменных, которым вам следует установить соответствующие значения для вашего проекта GCP. Команды в этой кодовой лаборатории предполагают, что эти переменные установлены. (например, export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' можно использовать для установки имени входного сегмента хранения банка Primus.) Если переменные имен ресурсов не были установлены, то они будут сгенерированы на основе Идентификатор проекта GCP.

Настройте следующее в проекте Primus:

$PRIMUS_INPUT_STORAGE_BUCKET : сегмент, в котором хранится файл данных клиента.
$PRIMUS_WORKLOAD_IDENTITY_POOL : пул удостоверений рабочей нагрузки (WIP), который проверяет утверждения.
$PRIMUS_WIP_PROVIDER : поставщик пула удостоверений рабочей нагрузки, который включает условие авторизации, используемое для токенов, подписанных службой проверки аттестации.
$PRIMUS_SERVICEACCOUNT : учетная запись службы, которую $PRIMUS_WORKLOAD_IDENTITY_POOL использует для доступа к защищенным ресурсам. На этом этапе у него есть разрешение на просмотр данных о клиентах, хранящихся в корзине $PRIMUS_INPUT_STORAGE_BUCKET .
$PRIMUS_ENC_KEY : ключ KMS, используемый для шифрования данных, хранящихся в $PRIMUS_INPUT_STORAGE_BUCKET .

Новые ресурсы для этой лаборатории кода:

$PRIMUS_COSIGN_REPOSITORY : реестр артефактов для хранения подписей образов рабочей нагрузки.
$PRIMUS_SIGNING_KEY : ключ KMS, используемый для подписи образа рабочей нагрузки аудитором/сотрудниками данных (например, банком Primus в данном случае).

Настройте следующее в проекте Secundus:

$SECUNDUS_ARTIFACT_REGISTRY : реестр артефактов, в который будет отправлен образ Docker рабочей нагрузки.
$WORKLOAD_IMAGE_NAME : имя образа Docker рабочей нагрузки.
$WORKLOAD_IMAGE_TAG : тег изображения Docker рабочей нагрузки.
$WORKLOAD_SERVICEACCOUNT : учетная запись службы, имеющая разрешение на доступ к конфиденциальной виртуальной машине, на которой выполняется рабочая нагрузка.
$SECUNDUS_RESULT_BUCKET : сегмент, в котором хранятся результаты рабочей нагрузки.

Другие источники:

primus_customer_list.csv содержит данные о клиентах. Мы загрузим эти данные в $PRIMUS_INPUT_STORAGE_BUCKET и создадим рабочую нагрузку, которая будет запрашивать эти данные.

Существующий рабочий процесс

При запуске рабочей нагрузки в конфиденциальном пространстве происходит следующий процесс с использованием настроенных ресурсов:

Рабочая нагрузка запрашивает общий токен доступа Google для $PRIMUS_SERVICEACCOUNT из WIP. Он предлагает сервисный токен Attestation Verifier с утверждениями о рабочей нагрузке и среде.
Если утверждения измерения рабочей нагрузки в сервисном токене средства проверки аттестации соответствуют условию атрибута в незавершенном документе, он возвращает токен доступа для $PRIMUS_SERVICEACCOUNT.
Рабочая нагрузка использует токен доступа к учетной записи службы, связанный с $PRIMUS_SERVICEACCOUNT для доступа к данным клиента в сегменте $PRIMUS_INPUT_STORAGE_BUCKET .
Рабочая нагрузка выполняет операцию с этими данными.
Рабочая нагрузка использует учетную запись службы $WORKLOAD_SERVICEACCOUNT для записи результатов этой операции в корзину $SECUNDUS_RESULT_STORAGE_BUCKET .

Новый рабочий процесс с поддержкой подписанных контейнеров.

Поддержка подписанных контейнеров будет интегрирована в существующий рабочий процесс, как показано ниже. При запуске рабочей нагрузки в конфиденциальном пространстве с поддержкой подписанного образа контейнера происходит следующий процесс с использованием настроенных ресурсов:

Confidential Space обнаруживает любые подписи контейнера, связанные с текущим работающим образом рабочей нагрузки, и отправляет их проверяющему устройству. Средство проверки аттестации проверяет подпись и включает все действительные подписи в утверждения аттестации.
Рабочая нагрузка запрашивает общий токен доступа Google для $PRIMUS_SERVICEACCOUNT из WIP. Он предлагает сервисный токен Attestation Verifier с утверждениями о рабочей нагрузке и среде.
Если утверждения подписи контейнера в сервисном токене Attestation Verifier соответствуют условию атрибута в WIP, он возвращает токен доступа для $PRIMUS_SERVICEACCOUNT .
Рабочая нагрузка использует токен доступа к учетной записи службы, связанный с $PRIMUS_SERVICEACCOUNT для доступа к данным клиента в сегменте $PRIMUS_INPUT_STORAGE_BUCKET .
Рабочая нагрузка выполняет операцию с этими данными.
Рабочая нагрузка использует $WORKLOAD_SERVICEACCOUNT для записи результатов этой операции в корзину $SECUNDUS_RESULT_STORAGE_BUCKET .

2. Настройте облачные ресурсы

В рамках настройки Confidential Space сначала вы создадите необходимые облачные ресурсы в рамках проектов GCP банка Primus и Secundus. Это новые ресурсы для этой лаборатории кода:

В проекте Примус:

Ключ подписи KMS, используемый для подписи рабочих нагрузок Secundus после проверки кода.
Репозиторий реестра артефактов для хранения подписей Cosign.

Новых ресурсов в проекте Secundus нет. После настройки этих ресурсов вы создадите учетную запись службы для рабочей нагрузки с необходимыми ролями и разрешениями. Затем вы создадите изображение рабочей нагрузки, и аудитор, банк Primus, подпишет изображение рабочей нагрузки. Затем рабочая нагрузка будет авторизована участниками совместной работы с данными (банк Primus в этой кодовой лаборатории), и оператор рабочей нагрузки (в данном случае Secundus Bank) будет запускать рабочую нагрузку.

В рамках настройки Confidential Space вы создадите необходимые облачные ресурсы в проектах Primus и Secundus GCP.

Прежде чем вы начнете

Клонируйте этот репозиторий с помощью приведенной ниже команды, чтобы получить необходимые скрипты, которые используются как часть этой лаборатории кода.

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

Убедитесь, что вы установили необходимые проекты, как показано ниже.

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

Установите переменные для имен ресурсов, упомянутых выше, с помощью этой команды. Вы можете переопределить имена ресурсов, используя эти переменные (например, export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' ).
Запустите следующий сценарий , чтобы задать для оставшихся имен переменных значения, основанные на идентификаторе вашего проекта для имен ресурсов.

$ source config_env.sh

Установите cosign, следуя инструкциям отсюда .

Настройка ресурсов Примус банка

В рамках этого шага вы настроите необходимые облачные ресурсы для Примус банка. Запустите следующий сценарий , чтобы настроить ресурсы для банка Primus. В рамках этих шагов будут созданы нижеуказанные ресурсы:

Ведро облачного хранилища ( $PRIMUS_INPUT_STORAGE_BUCKET ) для хранения зашифрованного файла данных клиента банка Primus.
Ключ шифрования ( $PRIMUS_ENC_KEY ) и связка ключей ( $PRIMUS_ENC_KEYRING ) в KMS для шифрования файла данных банка Primus.
Пул идентификации рабочей нагрузки ( $PRIMUS_WORKLOAD_IDENTITY_POOL ) для проверки утверждений на основе условий атрибутов, настроенных в его поставщике.
Учетная запись службы ( $PRIMUS_SERVICEACCOUNT ), прикрепленная к вышеупомянутому пулу идентификаторов рабочей нагрузки ( $PRIMUS_WORKLOAD_IDENTITY_POOL ), со следующим доступом к IAM:
roles/cloudkms.cryptoKeyDecrypter для расшифровки данных с помощью ключа KMS.
objectViewer для чтения данных из сегмента облачного хранилища.
roles/iam.workloadIdentityUser для подключения этой учетной записи службы к пулу удостоверений рабочей нагрузки.

$ ./setup_primus_bank_resources.sh

Настройка ресурсов банка Secundus

В рамках этого шага вы настроите необходимые облачные ресурсы для банка Secundus. Запустите следующий сценарий , чтобы настроить ресурсы для банка Secundus. В рамках этих шагов будут созданы указанные ниже ресурсы:

Ведро облачного хранилища ( $SECUNDUS_RESULT_STORAGE_BUCKET ) для хранения результатов выполнения рабочей нагрузки банком Secundus.

$ ./setup_secundus_bank_resources.sh

3. Создайте и подпишите рабочую нагрузку

Создать учетную запись службы рабочей нагрузки

Теперь вы создадите учетную запись службы для рабочей нагрузки с необходимыми ролями и разрешениями. Запустите следующий сценарий , чтобы создать учетную запись службы рабочей нагрузки в проекте банка Secundus. Эта учетная запись службы будет использоваться виртуальной машиной, на которой выполняется рабочая нагрузка.

Эта учетная запись службы рабочей нагрузки ( $WORKLOAD_SERVICEACCOUNT ) будет иметь следующие роли:
confidentialcomputing.workloadUser для получения токена аттестации
logging.logWriter для записи журналов в Cloud Logging.
objectViewer для чтения данных из сегмента облачного хранилища $PRIMUS_INPUT_STORAGE_BUCKET .
objectAdmin для записи результатов рабочей нагрузки в корзину облачного хранилища $SECUNDUS_RESULT_STORAGE_BUCKET .

$ ./create_workload_serviceaccount.sh

Создать рабочую нагрузку

В рамках этого шага вы создадите образ Docker для рабочей нагрузки. Рабочая нагрузка, используемая в этой Codelab, представляет собой простое приложение Go на основе CLI, которое подсчитывает клиентов (на основе данных о клиентах банка Primus) из предоставленного географического местоположения в аргументе. Запустите следующий сценарий , чтобы создать рабочую нагрузку, в которой выполняются следующие шаги:

Создайте реестр артефактов ( $SECUNDUS_ARTIFACT_REGISTRY ), принадлежащий банку Secundus.
Обновите код рабочей нагрузки, указав необходимые имена ресурсов. Вот код рабочей нагрузки, используемый для этой лаборатории кода.
Создайте двоичный файл Go и создайте Dockerfile для создания образа Docker кода рабочей нагрузки. Вот Dockerfile, используемый для этой лаборатории кода.
Создайте и опубликуйте образ Docker в реестре артефактов ( $SECUNDUS_ARTIFACT_REGISTRY ), принадлежащем банку Secundus.
Предоставьте $WORKLOAD_SERVICEACCOUNT разрешение на чтение для $SECUNDUS_ARTIFACT_REGISTRY . Это необходимо, чтобы контейнер рабочей нагрузки извлекал образ Docker рабочей нагрузки из реестра артефактов.

$ ./create_workload.sh

Подписать рабочую нагрузку

Мы будем использовать Cosign для подписи образа рабочей нагрузки. Cosign по умолчанию будет хранить подписи в том же репозитории, что и подписываемое изображение. Чтобы указать другой репозиторий для подписей, вы можете установить переменную среды COSIGN_REPOSITORY .

Здесь мы будем использовать реестр артефактов в качестве примера. Вы также можете выбрать другие реестры на основе OCI, такие как Docker Hub, AWS CodeArtifact, по своему усмотрению.

Создайте репозиторий Docker реестра артефактов.

$ gcloud config set project $PRIMUS_PROJECT_ID

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

Создайте связку ключей и ключ в KMS для подписи образа рабочей нагрузки.

$ 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

Для реестра артефактов ожидается полное имя изображения, например $LOCATION/$PROJECT/$REPOSITORY/$IMAGE_NAME . Вы можете загрузить любой образ контейнера в репозиторий для хранения сигнатур.

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

Предоставьте роль наблюдателя в репозитории $PRIMUS_COSIGN_REPOSITORY сервисному аккаунту $WORKLOAD_SERVICEACCOUNT . Это позволяет Confidential Space обнаруживать любые подписи образов контейнеров, загруженные в $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 — мощный инструмент с множеством функций подписи. В нашем случае мы требуем от Cosign только подписи с помощью пары ключей. Подпись без ключа Cosign не поддерживается для этой функции подписанного образа контейнера.

При подписании парой ключей есть два варианта:

Подпишитесь с помощью локальной пары ключей, сгенерированной Cosign.
Подпишитесь с помощью пары ключей, хранящейся в другом месте (например, в KMS).

Создайте пару ключей в Cosign, если у вас ее нет. Дополнительные сведения см. в разделе Подписание с помощью самоуправляемых ключей .

// 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

В приведенном выше замените <provider>://<key> на gcpkms://projects/$PRIMUS_PROJECT_ID/locations/global/keyRings/$PRIMUS_SIGNING_KEYRING/cryptoKeys/$PRIMUS_SIGNING_KEY/cryptoKeyVersions/$PRIMUS_SIGNING_KEYVERSION

<provider>: относится к используемому вами решению KMS.
<key>: относится к пути к ключу в KMS.

Получите открытый ключ для проверки.

// 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

Подпишите рабочую нагрузку с помощью Cosign. Выполнить кодировку base64 без дополнений для открытого ключа.

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

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

Подпишите рабочую нагрузку с помощью Cosign с прикрепленными экспортированным открытым ключом и алгоритмами подписи.

$ 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 [ОБЯЗАТЕЛЬНО] указывает, какой ключ подписи использовать. При ссылке на ключ, управляемый поставщиком KMS, используйте определенный формат URI из службы поддержки Sigstore KMS . При ссылке на ключ, сгенерированный Cosign, вместо этого используйте cosign.key.
$IMAGE_REFERENCE [REQUIRED] указывает, какой образ контейнера нужно подписать. Формат IMAGE_REFERENCE можно определить по тегу или дайджесту изображения. Например: 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 [ОБЯЗАТЕЛЬНО] указывает аннотации, прикрепленные к полезным данным подписи. Для образов контейнеров, подписанных в Конфиденциальном пространстве, к полезным данным подписи необходимо прикрепить алгоритмы открытого ключа и подписи.

dev.cosignproject.cosign/sigalg принимает ТОЛЬКО три значения:
RSASSA_PSS_SHA256: алгоритм RSASSA с дополнением PSS с дайджестом SHA256.
RSASSA_PKCS1V15_SHA256: алгоритм RSASSA с дополнением PKCS#1 v1.5 и дайджестом SHA256.
ECDSA_P256_SHA256: ECDSA на кривой P-256 с дайджестом SHA256. Это также алгоритм подписи по умолчанию для пар ключей, сгенерированных Cosign.

Загрузите подписи в репозиторий докеров.

Cosign Sign автоматически загрузит подписи в указанный COSIGN_REPOSITORY.

4. Авторизация и запуск рабочей нагрузки

Авторизовать рабочую нагрузку

В рамках этого шага мы настроим поставщика удостоверений рабочей нагрузки в пуле удостоверений рабочей нагрузки ( $PRIMUS_WORKLOAD_IDENTITY_POOL ). Для удостоверения рабочей нагрузки настроены атрибуты-условия, как показано ниже. Одним из условий является проверка отпечатка подписи образа рабочей нагрузки на соответствие отпечатку открытого ключа подписи. При этом условии атрибута, когда Secundus Bank выпускает новый образ рабочей нагрузки, Primus Bank проверяет код рабочей нагрузки и подписывает новый образ рабочей нагрузки без необходимости обновлять политику WIP с помощью дайджеста образа.

$ 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))"

Запустить рабочую нагрузку

В рамках этого шага мы будем запускать рабочую нагрузку на конфиденциальной виртуальной машине. Обязательные аргументы TEE передаются с использованием флага метаданных. Аргументы для контейнера рабочей нагрузки передаются с использованием части флага « tee-cmd ». Рабочая нагрузка запрограммирована для публикации результатов в $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"

Посмотреть Результаты

В проекте Secundus просмотрите результаты рабочей нагрузки.

$ gcloud config set project $SECUNDUS_PROJECT_ID

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

Результат должен быть 3, так как именно столько людей из Сиэтла указано в файле primus_customer_list.csv !

5. Очистка

Вот сценарий, который можно использовать для очистки ресурсов, которые мы создали в рамках этой лаборатории кода. В рамках этой очистки будут удалены следующие ресурсы:

Входное хранилище банка Primus ( $PRIMUS_INPUT_STORAGE_BUCKET ).
Счет обслуживания банка Примус ( $PRIMUS_SERVICEACCOUNT ).
Реестр артефактов Primus Bank, содержащий подписи изображений ( $PRIMUS_COSIGN_REPOSITORY ).
Пул идентификации рабочей нагрузки Primus Bank ( $PRIMUS_WORKLOAD_IDENTITY_POOL ).
Учетная запись службы рабочей нагрузки Secundus Bank ( $WORKLOAD_SERVICEACCOUNT ).
Экземпляр вычислений рабочей нагрузки.
Сегмент хранения результатов банка Secundus ( $SECUNDUS_RESULT_STORAGE_BUCKET ).
Реестр артефактов Secundus Bank ( $SECUNDUS_ARTIFACT_REGISTRY ).

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

Если вы закончили изучение, рассмотрите возможность удаления проекта.

Перейдите в консоль облачной платформы.
Выберите проект, который хотите закрыть, затем нажмите «Удалить» вверху: это запланирует удаление проекта.

Поздравления

Поздравляем, вы успешно завершили работу над кодом!

Вы узнали, как использовать функцию подписанного образа контейнера для повышения удобства использования конфиденциального пространства.

Что дальше?

Посмотрите некоторые из этих похожих лабораторий кода...