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

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

Ключ

Описание

корневой ключ

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

цели

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

снимок

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

метка времени

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

делегация

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

При первом выполнении docker push с включенным доверием к содержимому для репозитория образов автоматически создаются ключи root, target, snapshot и timestamp:

  • Корневой и целевой ключи генерируются и хранятся локально на стороне клиента.

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

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

Примечание

До Docker Engine 1.11 ключ моментального снимка также генерировался и сохранялся локально на стороне клиента. Используйте интерфейс командной строки с Notary по снова управлять ключом моментального снимка локально для репозиториев, созданных в более новых версиях Docker.

Выбрать парольную фразу

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

Выполняет резервную копию ваших ключей

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

Предупреждение

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

Клиент Docker хранит ключи в каталоге ~/.docker/trust/private. Перед резервным копированием их необходимо tar в архив:

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

Аппаратное хранение и сигнатура

Docker Content Trust может хранить и подписывать с помощью корневых ключей Yubikey 4. Yubikey имеет приоритет над ключами, хранящимися в файловой системе. Когда вы инициализируете новый репозиторий с доверием к содержимому, Docker Engine локально ищет корневой ключ. Если ключ не найден, а Yubikey 4 существует, Docker Engine создаёт корневой ключ в Yubikey 4. Дополнительные сведения см. в Документация Notary.

До Docker Engine 1.11 данная функция была только в экспериментальной ветке.

Потеря ключа

Предупреждение

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

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

Warning: potential malicious behavior - trust data has insufficient signatures for remote repository docker.io/my/image: valid signatures did not meet threshold

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