Управление подписанными образами с помощью Docker Content Trust в Реестре контейнеров Azure

Реестр контейнеров Azure реализует модель Docker Content Trust (DCT), чтобы включить отправку и извлечение подписанных образов. Эта статья поможет вам включить DCT в реестрах контейнеров. DCT — это функция уровня служб Premium реестра контейнеров.

Ограничения

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

Как работает DCT

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

В качестве издателя изображений можно использовать DCT для подписывания образов, которые вы отправляете в реестр. Потребители образов (люди или системы, извлекающие образы из реестра), могут настроить свои клиенты для извлечения только подписанных образов. Когда получатель извлекает подписанный образ, Docker-клиент проверяет его целостность. В этой модели потребители уверены, что вы опубликовали подписанные образы в реестре и что изображения не были изменены после публикации.

Доверенные образы

DCT работает с тегами в репозитории. Репозитории изображений могут содержать изображения, имеющие как подписанные, так и неподписанные теги. Например, вы могли бы подписать только изображения myimage:stable и myimage:latest, но не myimage:dev.

Ключи подписывания

Вы управляете DCT с помощью набора криптографических ключей подписывания. Эти ключи связаны с конкретным репозиторием в реестре.

Есть несколько типов таких ключей, с помощью которых Docker-клиенты и ваш реестр управляют доверием к тегам в репозитории. Когда вы включаете DCT и интегрируете его в рабочий процесс для публикации и использования контейнеров, необходимо внимательно управлять этими ключами. Дополнительные сведения см. в разделе "Управление ключами " далее в этой статье и управление ключами для доверия к содержимому в документации Docker.

Включить DCT для реестра

Первым шагом является включение DCT на уровне реестра. После включения DCT клиенты (пользователи или службы) могут отправлять подписанные образы в реестр.

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

Чтобы включить DCT для реестра с помощью портала Azure, перейдите в реестр. В разделе «Политики» выберите «Доверие к контенту»>Включено>Сохранить. Вы также можете использовать команду az acr config content-trust update в Azure CLI.

Включение DCT для клиента

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

Чтобы включить DCT для сеанса оболочки, задайте для переменной DOCKER_CONTENT_TRUST среды значение 1. Например, в оболочке Bash используйте следующий код:

# Enable DCT for a shell session
export DOCKER_CONTENT_TRUST=1

Если вы хотите включить или отключить DCT для одной команды, несколько команд Docker поддерживают --disable-content-trust аргумент.

Чтобы включить DCT для одной команды, используйте следующий код:

# Enable DCT for a single command
docker build --disable-content-trust=false -t myacr.azurecr.io/myimage:v1 .

Если вы включили DCT для сеанса оболочки и хотите отключить его для одной команды, используйте следующий код:

# Disable DCT for a single command
docker build --disable-content-trust -t myacr.azurecr.io/myimage:v1 .

Предоставление разрешений на подписывание образов

Только пользователи или системы, которым предоставляется разрешение, могут отправлять доверенные образы в реестр. Чтобы предоставить этому принудительному разрешению пользователю (или системе с помощью субъекта-службы), назначьте AcrImageSigner роль удостоверению Microsoft Entra пользователя. Это разрешение дополняет роль AcrPush (или ее эквивалент), необходимую для перемещения образов в реестр. Дополнительные сведения см. в разделе "Разрешения реестра контейнеров Azure" и общие сведения о назначениях ролей.

По состоянию на июль 2021 года роль включает как действие AcrImageSigner, так и Microsoft.ContainerRegistry/registries/sign/write и действия с данными Microsoft.ContainerRegistry/registries/trustedCollections/write.

Портал Azure

Чтобы предоставить AcrImageSigner роль с помощью портала Azure, выполните следующие действия.

1. Выберите Управление доступом (IAM).

2. Выберите Добавить>Добавить назначение роли, чтобы открыть панель Добавить назначение роли.

3. Назначьте следующую роль. В этом примере роль назначается отдельному пользователю. Подробные инструкции см. в статье Назначение ролей Azure с помощью портала Microsoft Azure.

   Настройки	Значение
   Роль	AcrImageSigner
   Назначьте доступ	User
   Участники	Ален

   

Azure CLI (Интерфейс командной строки для Azure)

Чтобы предоставить пользователю разрешения на подписывание с помощью Azure CLI, назначьте пользователю роль AcrImageSigner в рамках вашего реестра. Команда имеет следующий формат.

az role assignment create --scope <registry ID> --role AcrImageSigner --assignee <user name>

Например, чтобы назначить роль не административному пользователю, можно выполнить следующие команды в сеансе Azure CLI, прошедшем проверку подлинности. Измените значение REGISTRY в соответствии с именем реестра контейнеров Azure.

# Grant signing permissions to an authenticated Azure CLI user
REGISTRY=myregistry
REGISTRY_ID=$(az acr show --name $REGISTRY --query id --output tsv)

az role assignment create --scope $REGISTRY_ID --role AcrImageSigner --assignee [email protected]

Также можно выдать служебному принципалу права на отправку доверенных образов в реестр. Использование служебного принципала полезно для систем сборки и других систем, работающих без участия человека, которым необходимо отправлять доверенные образы в ваш реестр. Формат похож на предоставление пользователю разрешений, но укажите идентификатор субъекта-службы для значения --assignee:

az role assignment create --scope $REGISTRY_ID --role AcrImageSigner --assignee <service principal ID>

Значение <service principal ID> может быть значением субъекта-службы appId , его objectId значением или одним из его servicePrincipalNames значений. Дополнительные сведения о работе с субъектами-службами и реестром контейнеров Azure см. в статье "Проверка подлинности реестра контейнеров Azure с помощью субъектов-служб".

Размещение доверенного образа

Чтобы отправить доверенный тег образа в реестр контейнеров, включите DCT и используйте docker push. После первого завершения отправки подписанного тега вам будет предложено создать парольную фразу как для корневого ключа подписи, так и для ключа подписи репозитория. Оба ключа, корневой и ключ репозитория, создаются и хранятся локально на вашей машине.

$ docker push myregistry.azurecr.io/myimage:v1
[...]
The push refers to repository [myregistry.azurecr.io/myimage]
ee83fc5847cb: Pushed
v1: digest: sha256:aca41a608e5eb015f1ec6755f490f3be26b48010b178e78c00eac21ffbe246f1 size: 524
Signing and pushing trust metadata
You are about to create a new root signing key passphrase. This passphrase
will be used to protect the most sensitive key in your signing system. Please
choose a long, complex passphrase and be careful to keep the password and the
key file itself secure and backed up. It is highly recommended that you use a
password manager to generate the passphrase and keep it safe. There will be no
way to recover this key. You can find the key in your config directory.
Enter passphrase for new root key with ID 4c6c56a:
Repeat passphrase for new root key with ID 4c6c56a:
Enter passphrase for new repository key with ID bcd6d98:
Repeat passphrase for new repository key with ID bcd6d98:
Finished initializing "myregistry.azurecr.io/myimage"
Successfully signed myregistry.azurecr.io/myimage:v1

После первого docker push действия с поддержкой DCT клиент Docker использует тот же корневой ключ для последующих push-уведомлений. Каждый раз при последующей отправке в тот же репозиторий вас просят указать только ключ репозитория. Каждый раз, когда вы загружаете доверенный образ в новый репозиторий, вас попросят ввести парольную фразу для нового ключа репозитория.

Извлечение доверенного образа

Чтобы извлечь доверенный образ, включите DCT и выполните команду docker pull как обычно. Для извлечения надежных образов обычным пользователям будет достаточно роли AcrPull. Дополнительные роли (например, роль AcrImageSigner) не требуются. Потребители, у которых включен DCT, могут извлекать только изображения с подписанными тегами. Вот пример извлечения подписанного тега:

$ docker pull myregistry.azurecr.io/myimage:signed
Pull (1 of 1): myregistry.azurecr.io/myimage:signed@sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b
sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b: Pulling from myimage
8e3ba11ec2a2: Pull complete
Digest: sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b
Status: Downloaded newer image for myregistry.azurecr.io/myimage@sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b
Tagging myregistry.azurecr.io/myimage@sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b as myregistry.azurecr.io/myimage:signed

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

$ docker pull myregistry.azurecr.io/myimage:unsigned
Error: remote trust data does not exist

Закулисье

При запуске docker pull клиент Docker использует ту же библиотеку, что и утилиты Notary CLI, чтобы запросить отображение тега на дайджест SHA-256 для вытягиваемого тега. После проверки подписей в данных доверия клиент указывает Docker Engine выполнить "извлечение по дайджесту". Во время извлечения Docker Engine использует контрольную сумму SHA-256 в качестве адреса содержимого для запроса и проверки манифеста образа из реестра контейнеров Azure.

Управление ключами

Как указано в выходных данных docker push, корневой ключ является наиболее чувствительным при загрузке вашего первого доверенного образа. По умолчанию Docker-клиент хранит ключи подписывания здесь:

~/.docker/trust/private

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

umask 077; tar -zcvf docker_private_keys_backup.tar.gz ~/.docker/trust/private; umask 022

Наряду с локально сгенерированными ключами корня и репозитория, Container Registry создает и сохраняет несколько других ключей при отправке доверенного образа. Подробное обсуждение различных ключей в реализации DCT, включая руководство по управлению, см. в разделе "Управление ключами доверия к содержимому " в документации По Docker.

Потеря корневого ключа

Если вы потеряете доступ к корневому ключу, вы потеряете доступ к подписанным тегам в любом репозитории, теги которого подписаны ключом. Реестр контейнеров не может восстановить доступ к тегам изображений, подписанным с потерянным корневым ключом. Чтобы удалить все данные доверия (подписи) для реестра, отключите и повторно включите DCT для реестра.

Чтобы отключить DCT для реестра, перейдите в реестр на портале Azure. В разделе "Политики" выберите "Доверие к содержимому">, затем "Отключено">, и Сохранить. Вас предупреждают о потере всех подписей в реестре. Нажмите кнопку "ОК" , чтобы окончательно удалить все подписи в реестре.

Связанный контент

• Дополнительные сведения о DCT, включая docker trust команды и делегирование доверия, см. в разделе Docker "Доверие к содержимому".
• Пример того, как использовать DCT при сборке и отправке образа Docker, см. раздел в документации Azure Pipelines.