Доверие к содержимому в реестре контейнеров Azure

Реестр контейнеров Azure реализует модель доверия к содержимому Docker, обеспечивая отправку и извлечение подписанных образов. Эта статья поможет приступить к реализации модели доверия к содержимому в ваших реестрах контейнеров.

Ограничения

• Токен с разрешениями на уровне репозитория в настоящее время не поддерживает команды docker push и pull для подписанных образов.

Как работает функция доверия к содержимому

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

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

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

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

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

Управление функцией доверия к содержимому осуществляется с помощью набора ключей подписывания, Эти ключи связаны с конкретным репозиторием в реестре. Есть несколько типов таких ключей, с помощью которых Docker-клиенты и ваш реестр управляют доверием к тегам в репозитории. Если функция доверия к содержимому включена и интегрирована в конвейер публикации и получения в контейнере, следует управлять этими ключами с осмотрительностью. Подробные сведения см. в разделе Управление ключами этой статьи, а также на странице Manage keys for content trust (Управление ключами функции доверия к содержимому) документации Docker.

Включение доверия к содержимому в реестре

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

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

Включение доверия к содержимому клиента

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

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

# Enable content trust for shell session
export DOCKER_CONTENT_TRUST=1

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

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

Если вы включили доверие к содержимому для сеанса оболочки и хотите отключить его для одной команды:

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

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

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

Далее описано, как назначить роль AcrImageSigner на портале Azure и в интерфейсе командной строки Azure CLI.

Портал Azure

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

2. Выберите Добавить>Добавить назначение ролей, чтобы открыть страницу "Добавление назначения ролей".

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

   Настройки	Значение
   Роль	AcrImageSigner
   Назначить доступ для	Пользователь
   Участники	Alain

   

Azure CLI

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

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

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

# Grant signing permissions to 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 с помощью субъектов-служб.

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

Чтобы отправить доверенный тег образа в реестр контейнеров, включите функцию доверия к содержимому и отправьте образ с помощью 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 с включенным доверенным контентом Docker-клиент использует тот же корневой ключ в следующих отправках. Каждый раз при последующей отправке в тот же репозиторий вас просят указать только ключ репозитория. Каждый раз, когда вы загружаете доверенный образ в новый репозиторий, вас попросят ввести парольную фразу для нового ключа репозитория.

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

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

$ 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

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

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

Закулисье

При запуске docker pull клиент Docker использует ту же библиотеку, что и в Notary CLI, для запроса сопоставления тега с хешем SHA-256 для извлекаемого вами тега. После проверки подписей в данных доверия клиент инструктирует движок Docker выполнить «скачивание по хэш-коду». Во время скачивания движок использует контрольную сумму 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

Другие ключи, наряду с корневыми ключами и ключами репозитория, созданными локально, создаются и хранятся в Реестре контейнеров Azure при отправке доверенного образа. Подробное описание различных типов ключей, а также советы по управлению ими в функции доверия к содержимому в Docker см. на странице Manage keys for content trust (Управление ключами функции доверия к содержимому) документации Docker.

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

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

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

Следующие шаги

• См. Доверие содержимого в Docker для получения дополнительной информации о доверии содержимого, включая команды docker trust и доверительные делегирования. В этой статье мы затронули лишь ключевые моменты обширной темы доверия к содержимому, которая более подробно рассматривается в документации Docker.

• Пример того, как применяется функция доверия к содержимому при создании и отправке образа Docker, см. в документации по Azure Pipelines.