Есть ли в Docker Content Trust два корневых ключа?

Я новичок в механизме Docker Content Trust (DCT) и немного смущен корневым ключом. Когда я впервые добавляю подписывающего в новый репозиторий, меня просят ввести парольные фразы для корневого ключа и ключа репозитория. После этого в каталоге создается ключевой файл с идентификатором корневого ключа.~/.docker/trust/private. Пока все хорошо, но когда я выполняюdocker trust inspect <repo name>, Я получаю другой идентификатор корневого ключа в разделе административных ключей.

Не могли бы вы мне это объяснить?

3 ответа

Подписанные пользователем изображения

Существует два варианта закрепления доверия к изображениям, подписанным пользователем:

  • Идентификатор канонического корневого ключа нотариуса (корневой ключ DCT) — это идентификатор, который описывает только корневой ключ, используемый для подписи репозитория (точнее, его соответствующие ключи). Это корневой ключ хоста, который первоначально подписал репозиторий (т.е. ваша рабочая станция). Его можно получить с рабочей станции, подписавшей репозиторий, через $ grep -r "root" ~/.docker/trust/private/ (при условии, что ваши данные доверия находятся в ~/.docker/trust/*). Ожидается, что этот канонический идентификатор инициировал несколько репозиториев изображений (mydtr/user1/image1 и mydtr/user1/image2).
      # Retrieving Root ID
$ grep -r "root" ~/.docker/trust/private
/home/ubuntu/.docker/trust/private/0b6101527b2ac766702e4b40aa2391805b70e5031c04714c748f914e89014403.key:role: root

# Using a Canonical ID that has signed 2 repos (mydtr/user1/repo1 and mydtr/user1/repo2). Note you can use a Wildcard.

{
  "content-trust": {
    "trust-pinning": {
      "root-keys": {
         "mydtr/user1/*": [
           "0b6101527b2ac766702e4b40aa2391805b70e5031c04714c748f914e89014403"
         ]
      }
    },
    "mode": "enforced"
  }
}
  • Идентификатор корневого ключа нотариуса (идентификатор сертификата DCT) — это идентификатор, который описывает то же самое, но идентификатор уникален для каждого репозитория. Например, mydtr/user1/image1 и mydtr/usr1/image2 будут иметь уникальные идентификаторы сертификатов. Идентификатор сертификата можно получить с помощью команды $ dockertrust inspect, и он помечен как корневой ключ (ссылаясь на имя ключа нотариуса). Это предназначено для случаев, когда разные пользователи подписывают свои собственные репозитории, например, когда нет центрального сервера подписи. Поскольку идентификатор сертификата более детализирован, он будет иметь приоритет, если возникнет конфликт из-за корневого идентификатора.
      # Retrieving Cert ID
$ docker trust inspect mydtr/user1/repo1 | jq -r '.[].AdministrativeKeys[] | select(.Name=="Root") | .Keys[].ID'
9430d6e31e3b3e240957a1b62bbc2d436aafa33726d0fcb50addbf7e2dfa2168

# Using Cert Ids, by specifying 2 repositories by their DCT root ID. Example for using this may be different DTRs or maybe because the repository was initiated on different hosts, therefore having different canonical IDs.

{
  "content-trust": {
    "trust-pinning": {
      "cert-ids": {
         "mydtr/user1/repo1": [
           "9430d6e31e3b3e240957a1b62bbc2d436aafa33726d0fcb50addbf7e2dfa2168"
         ],
         "mydtr/user2/repo1": [
           "544cf09f294860f9d5bc953ad80b386063357fd206b37b541bb2c54166f38d08"
         ]
      }
    },
    "mode": "enforced"
  }
}

http://www.myclass5.cn/engine/security/trust/content_trust/

TL; DR;:Один корневой ключ предназначен для подписывающей стороны, а другой - для репозитория.

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

      $ docker trust key load --name arif key.pem
Loading key from "key.pem"...
Enter passphrase for new arif key with ID 2817c38: 
Repeat passphrase for new arif key with ID 2817c38: 
Successfully imported key from key.pem

Вы можете найти зашифрованный root ключ в .docker/trust/private как следующее,

      $ cat ../.docker/trust/private/2817c387b869ede57bd209e40a3dfce967b70eca1eb3739bc58afba44665aaef.key 
-----BEGIN ENCRYPTED PRIVATE KEY-----
role: arif

MIHuMEkGCSqGSIb3DQEFDTA8MBsGCSqGSIb3DQEFDDAOBAh/6HbWl/T/SAICCAAw
HQYJYIZIAWUDBAEqBBAZpJBc+C9ABYY6UbMT3YSRBIGgiNT5fX9QqCOrGJ3lb3qw
7JkC/4D0dtp75MYWaMbfYXvNm+muJXmVUpp5vh91onUW8Y8q+ymQTgDq3mN8+HLu
4iRp46wXxilEKUxmXsYln/mxQI+jU7UwTTiLiy6LpR1vpBKdO8hhd/WObW25P+ah
YjslB1P8fe9VeSsorAKM5zDnuaiVhHh7BjgVAiepDvmy/7zO3W7Rso4Kgg0UZkJn
SA==
-----END ENCRYPTED PRIVATE KEY-----

Затем я пытаюсь добавить подписавшего в репозиторий, и он спросит 2 вещи:

  1. Новая кодовая фраза для шифрования корневого ключа репозитория, который я хочу подписать "
  2. Новая кодовая фраза для шифрования ** ключа репозитория ** именно для этого репозитория.
      $ docker trust signer add --key cert.pem arif ec2-3-67-179-58.eu-central-1.compute.amazonaws.com/docker/haproxy 
Adding signer "arif" to ec2-3-67-179-58.eu-central-1.compute.amazonaws.com/docker/haproxy...
Initializing signed repository for ec2-3-67-179-58.eu-central-1.compute.amazonaws.com/docker/haproxy...
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 06665b8: 
Repeat passphrase for new root key with ID 06665b8: 
Enter passphrase for new repository key with ID b040c66: 
Repeat passphrase for new repository key with ID b040c66: 
Successfully initialized "ec2-3-67-179-58.eu-central-1.compute.amazonaws.com/docker/haproxy"
Successfully added signer: arif to ec2-3-67-179-58.eu-central-1.compute.amazonaws.com/docker/haproxy

В выходных данных выше мы видим, что идентификаторы двух ключей: 06665b8 а также b040c66.

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

      $ grep role .docker/trust/private/06665b8*.key
role: root

$ grep role .docker/trust/private/b040c66*.key
role: targets

Теперь, если я проверю репозиторий, я вижу следующее:

      $ docker trust inspect ec2-3-67-179-58.eu-central-1.compute.amazonaws.com/docker/haproxy
[
    {
        "Name": "ec2-3-67-179-58.eu-central-1.compute.amazonaws.com/docker/haproxy",
        "SignedTags": [],
        "Signers": [
            {
                "Name": "arif",
                "Keys": [
                    {
                        "ID": "2817c387b869ede57bd209e40a3dfce967b70eca1eb3739bc58afba44665aaef"
                    }
                ]
            }
        ],
        "AdministrativeKeys": [
            {
                "Name": "Root",
                "Keys": [
                    {
                        "ID": "5ed03b461b330c6d722c319bdfaa87e3d8b289a1213569248bdaa616a1a399c6"
                    }
                ]
            },
            {
                "Name": "Repository",
                "Keys": [
                    {
                        "ID": "b040c663463612c99130eca98ec827ef32a3bab73d2976403888443ce87899c6"
                    }
                ]
            }
        ]
    }
]

Итак, теперь у нас есть 3 ключа. Один - это корневой ключ подписывающей стороны, другой - корневой ключ репозитория, а последний - целевой ключ.

      $ ls .docker/trust/private/ -1 | wc -l
3

Вы можете найти все метаданные об этих ключах в tuf каталог

      $ cd .docker/trust/tuf/ec2-3-67-179-58.eu-central-1.compute.amazonaws.com/docker/haproxy/metadata/

$ ls 
root.json  snapshot.json  targets.json  timestamp.json

Надеюсь, теперь это имеет смысл.

Есть несколько ключей:

  • Ключ подписавшего
  • Ключ репозитория
  • Корневой ключ

Вы можете открывать файлы в ~/.docker/trust/privateчтобы увидеть роль каждого ключа. Или ты можешь бежать notary -d ~/.docker/trust key list

Для этого тоже подойдет симпатичный вариант: docker trust inspect --pretty <repo_name> чтобы получить следующий результат

      Signatures for repo_name

SIGNED TAG   DIGEST                                                             SIGNERS
latest       def822f9851ca422481ec6fee59a9966f12b351c62ccb9aca841526ffaa9f748   test

List of signers and their keys for repo_name

SIGNER    KEYS
test       c990796d79a9

Administrative keys for repo_name

  Repository Key:   06362021113fed73dc5e08e6b5edbe04cf4316193b362b0d8335fab3285fc98b
  Root Key: 317f83b55c99e2b8f9d341a3c9a3fc4b1d65d97f52a553020a65cdee85940cf3
Другие вопросы по тегам