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

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

1. Обзор

Данный практический пример основан на практическом примере «Конфиденциальное пространство» . Добавлена поддержка подписанных образов контейнеров с возможностью аутентификации контейнера с использованием подтвержденного открытого ключа вместо указания дайджеста образа в политике пула идентификаторов рабочей нагрузки (WIP).

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

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

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

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

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

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

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

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

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

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

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

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

Роли, связанные с работой в конфиденциальном пространстве с подписанным изображением контейнера.

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

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

Банк Secundus будет выступать в роли разработчика и оператора рабочих нагрузок и отвечать за следующее:

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

Банк Secundus разработает и опубликует рабочую нагрузку, которая будет запрашивать данные клиентов, хранящиеся в облачном хранилище, принадлежащем банку Primus. Банк Primus проведет аудит рабочей нагрузки, подпишет образ контейнера и настроит политики 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 и создадим рабочую нагрузку, которая будет запрашивать эти данные.

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

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

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

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

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

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

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

В рамках настройки конфиденциального пространства сначала вам нужно будет создать необходимые облачные ресурсы в проектах GCP для Primus и Secundus bank. Вот новые ресурсы для этого практического занятия:

В проекте Primus:

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

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

В рамках настройки конфиденциального пространства вам потребуется создать необходимые облачные ресурсы в проектах Primus и Secundus GCP.

Прежде чем начать

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

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

Измените каталог для этого практического занятия.

cd confidential-space/codelabs/signed_container_codelab/scripts

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

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. Запустите следующий скрипт , чтобы настроить ресурсы для банка 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 для рабочей нагрузки. В этом практическом занятии используется простое приложение Go на основе командной строки, которое подсчитывает количество клиентов (из данных о клиентах банка 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 .

В качестве примера мы будем использовать Artifact Registry . Вы также можете выбрать другие реестры на основе OCI , такие как Docker Hub или AWS CodeArtifact, в зависимости от ваших предпочтений.

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

gcloud config set project $PRIMUS_PROJECT_ID

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

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

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}

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

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

Примечание: разные реестры могут ожидать разные форматы для "репозитория".

Реестр GCR ожидает следующий формат:

$ export COSIGN_REPOSITORY=gcr.io/primus-signatures

Реестр артефактов ожидает полное имя образа, например, $LOCATION-docker.pkg.dev/$PROJECT/$REPOSITORY/$STORAGE_IMAGE, а не просто имя репозитория. Например,

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

Указание простого репозитория, например, us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}, не будет работать в реестре артефактов.

Предоставьте учетной записи службы $WORKLOAD_SERVICEACCOUNT роль «Просмотрщик» для репозитория $PRIMUS_COSIGN_REPOSITORY . Это позволит 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. Дополнительные сведения см. в разделе «Подписание с помощью самостоятельно управляемых ключей» . Здесь мы указали оба способа (локально и с использованием поставщика KMS) генерации пары ключей и подписи рабочей нагрузки. Пожалуйста, воспользуйтесь одним из этих способов для подписи контейнера рабочей нагрузки.

// 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 [ОБЯЗАТЕЛЬНО] указывает, какой образ контейнера следует подписать. Формат 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.

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

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

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

В проекте 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 Bank ( $PRIMUS_SERVICEACCOUNT ).
Реестр артефактов Primus Bank, содержащий подписи изображений ( $PRIMUS_COSIGN_REPOSITORY ).
Пул идентификаторов рабочих нагрузок Primus Bank ( $PRIMUS_WORKLOAD_IDENTITY_POOL ).
Счетчик обслуживания рабочих нагрузок банка Secundus ( $WORKLOAD_SERVICEACCOUNT ).
Экземпляр вычислительных ресурсов для рабочей нагрузки.
Сегмент хранения результатов Secundus Bank ( $SECUNDUS_RESULT_STORAGE_BUCKET ).
Реестр артефактов банка Секундус ( $SECUNDUS_ARTIFACT_REGISTRY ).
Виртуальная машина рабочей нагрузки банка Secundus ( $WORKLOAD_VM ).

./cleanup.sh

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

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

Поздравляем!

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

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

Что дальше?

Посмотрите похожие обучающие материалы по программированию...