Поделиться через


Подписывание образов контейнеров с помощью Нотации и Azure Key Vault с помощью выданного ЦС сертификата

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

Ниже приведены некоторые важные компоненты, которые помогают подписывать и проверять образы контейнеров сертификатом, выданным доверенным ЦС:

  • Нотация — это средство безопасности цепочки поставок с открытым исходным кодом, разработанное сообществом Нотари Проекта и поддерживаемое корпорацией Майкрософт, которое поддерживает подписывание и проверку образов контейнеров и других артефактов.
  • Azure Key Vault (AKV), облачная служба для управления криптографическими ключами, секретами и сертификатами поможет обеспечить безопасное хранение и управление сертификатом с помощью ключа подписи.
  • Подключаемый модуль Нотации AKV azure-kv, расширение Нотации использует ключи, хранящиеся в Azure Key Vault, для подписывания и проверки цифровых подписей образов контейнеров и артефактов.
  • Реестр контейнеров Azure (ACR) позволяет присоединять эти подписи к подписанному изображению и помогает хранить эти образы контейнеров и управлять ими.

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

Содержание этой статьи

  • Установка интерфейса командной строки нотации и подключаемого модуля AKV
  • Создание или импорт сертификата, выданного ЦС в AKV
  • Создание и отправка образа контейнера с помощью задачи ACR
  • Подписывание образа контейнера с помощью интерфейса командной строки нотации и подключаемого модуля AKV
  • Проверка подписи образа контейнера с помощью интерфейса командной строки нотации
  • Установка меток времени

Необходимые компоненты

Примечание.

Рекомендуется создать azure Key Vault только для хранения сертификатов.

Установка интерфейса командной строки нотации и подключаемого модуля AKV

  1. Установите нотацию версии 1.2.0 в среде Linux amd64. Следуйте инструкциям по установке нотации, чтобы скачать пакет для других сред.

    # Download, extract and install
    curl -Lo notation.tar.gz https://github.com/notaryproject/notation/releases/download/v1.2.0/notation_1.2.0_linux_amd64.tar.gz
    tar xvzf notation.tar.gz
    
    # Copy the notation cli to the desired bin directory in your PATH, for example
    cp ./notation /usr/local/bin
    
  2. Установите подключаемый модуль azure-kv Нотации Azure Key Vault версии 1.2.0 в среде Linux amd64.

    Примечание.

    Url-адрес и контрольная сумма SHA256 для подключаемого модуля Нотации Azure Key Vault можно найти на странице выпуска подключаемого модуля.

    notation plugin install --url https://github.com/Azure/notation-azure-kv/releases/download/v1.2.0/notation-azure-kv_1.2.0_linux_amd64.tar.gz --sha256sum 06bb5198af31ce11b08c4557ae4c2cbfb09878dfa6b637b7407ebc2d57b87b34
    
  3. Список доступных подключаемых модулей и убедитесь, что azure-kv подключаемый модуль с версией 1.2.0 включен в список.

    notation plugin ls
    

Настройка переменных среды

Примечание.

В этом руководстве используются переменные среды для удобства при настройке AKV и ACR. Обновите значения этих переменных среды для определенных ресурсов.

  1. Настройка переменных среды для AKV и сертификатов

    AKV_SUB_ID=myAkvSubscriptionId
    AKV_RG=myAkvResourceGroup
    AKV_NAME=myakv 
    
    # Name of the certificate created or imported in AKV 
    CERT_NAME=wabbit-networks-io 
    
    # X.509 certificate subject
    CERT_SUBJECT="CN=wabbit-networks.io,O=Notation,L=Seattle,ST=WA,C=US"
    
  2. Настройте переменные среды для ACR и изображений.

    ACR_SUB_ID=myAcrSubscriptionId
    ACR_RG=myAcrResourceGroup
    # Name of the existing registry example: myregistry.azurecr.io 
    ACR_NAME=myregistry 
    # Existing full domain of the ACR 
    REGISTRY=$ACR_NAME.azurecr.io 
    # Container name inside ACR where image will be stored 
    REPO=net-monitor 
    TAG=v1 
    # Source code directory containing Dockerfile to build 
    IMAGE_SOURCE=https://github.com/wabbit-networks/net-monitor.git#main  
    

Вход с помощью Azure CLI

az login

Дополнительные сведения о Azure CLI и его входе см. в статье "Вход с помощью Azure CLI".

Создание или импорт сертификата, выданного ЦС в AKV

Требования к сертификатам

При создании сертификатов для подписывания и проверки сертификаты должны соответствовать требованию сертификата нотаричного проекта.

Ниже приведены требования к корневым и промежуточным сертификатам:

  • Расширение должно присутствовать и помечено как критическое basicConstraints . Поле CA должно быть задано true.
  • Расширение keyUsage должно присутствовать и помечено critical. Битовые позиции для keyCertSign должны быть заданы.

Ниже приведены требования к сертификатам, выданным ЦС:

  • Свойства сертификата X.509:
    • Тема должна содержать общее имя (), страну (CNC), штат или провинцию (ST) и организацию (O). В этом руководстве $CERT_SUBJECT используется в качестве темы.
    • Флаг использования ключа X.509 должен быть DigitalSignature только.
    • Расширенные значения использования ключей (EKUs) должны быть пустыми или 1.3.6.1.5.5.7.3.3 (для назначения кода).
  • Ключевые свойства:
    • Свойство exportable должно иметь значение false.
    • Выберите поддерживаемый тип ключа и размер из спецификации нотаричного проекта.

Внимание

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

Примечание.

В этом руководстве используется версия 1.0.1 подключаемого модуля AKV. Предыдущие версии подключаемого модуля имели ограничение, требующее определенного порядка сертификатов в цепочке сертификатов. Версия 1.0.1 подключаемого модуля не имеет этого ограничения, поэтому рекомендуется использовать версию 1.0.1 или более позднюю.

Создание сертификата, выданного ЦС

Создайте запрос на подпись сертификата (CSR), выполнив инструкции по созданию запроса на подпись сертификата.

Внимание

При слиянии CSR убедитесь, что вы объединяете всю цепочку, которая возвращалась поставщиком ЦС.

Импорт сертификата в AKV

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

  1. Получите файл сертификата от поставщика ЦС со всей цепочкой сертификатов.
  2. Импортируйте сертификат в Azure Key Vault, следуя инструкциям по импорту сертификата.

Примечание.

Если сертификат не содержит цепочку сертификатов после создания или импорта, вы можете получить промежуточные и корневые сертификаты от поставщика ЦС. Вы можете попросить поставщика предоставить вам PEM-файл, содержащий промежуточные сертификаты (если таковые) и корневой сертификат. Затем этот файл можно использовать на шаге 5 подписывания образов контейнеров.

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

При работе с ACR и AKV необходимо предоставить соответствующие разрешения для обеспечения безопасного и управляемого доступа. Вы можете авторизовать доступ для различных сущностей, таких как субъекты-пользователи, субъекты-службы или управляемые удостоверения в зависимости от конкретных сценариев. В этом руководстве доступ авторизован для пользователя Azure, выполнившего вход.

Создание доступа к ACR

AcrPush Роли AcrPull необходимы для создания и подписывания образов контейнеров в ACR.

  1. Задайте подписку, содержащую ресурс ACR

    az account set --subscription $ACR_SUB_ID
    
  2. Назначение ролей

    USER_ID=$(az ad signed-in-user show --query id -o tsv)
    az role assignment create --role "AcrPull" --role "AcrPush" --assignee $USER_ID --scope "/subscriptions/$ACR_SUB_ID/resourceGroups/$ACR_RG/providers/Microsoft.ContainerRegistry/registries/$ACR_NAME"
    

Создание и отправка образов контейнеров в ACR

  1. Проверка подлинности в ACR с помощью отдельного удостоверения Azure.

    az acr login --name $ACR_NAME
    

Внимание

Если вы установили Docker в системе и использовали или docker login выполнили az acr login проверку подлинности в ACR, ваши учетные данные уже хранятся и доступны для нотации. В этом случае вам не нужно выполнять notation login проверку подлинности в ACR. Дополнительные сведения о параметрах проверки подлинности для нотации см. в статье Аутентификация с помощью реестров, совместимых с OCI.

  1. Создание и отправка нового образа с помощью задач ACR. Всегда используйте digest для идентификации изображения для подписывания, так как теги являются изменяемыми и могут быть перезаписаны.

    DIGEST=$(az acr build -r $ACR_NAME -t $REGISTRY/${REPO}:$TAG $IMAGE_SOURCE --no-logs --query "outputImages[0].digest" -o tsv)
    IMAGE=$REGISTRY/${REPO}@$DIGEST
    

В этом руководстве, если образ уже создан и хранится в реестре, тег служит идентификатором этого образа для удобства.

IMAGE=$REGISTRY/${REPO}@$TAG

Создание доступа к AKV

  1. Задайте подписку, содержащую ресурс AKV

    az account set --subscription $AKV_SUB_ID
    
  2. Назначение ролей

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

    • Key Vault Secrets User для чтения секретов
    • Key Vault Certificates Userдля чтения сертификатов
    • Key Vault Crypto User для операций подписывания
    USER_ID=$(az ad signed-in-user show --query id -o tsv)
    az role assignment create --role "Key Vault Secrets User" --role "Key Vault Certificates User" --role "Key Vault Crypto User" --assignee $USER_ID --scope "/subscriptions/$AKV_SUB_ID/resourceGroups/$AKV_RG/providers/Microsoft.KeyVault/vaults/$AKV_NAME"
    

    Если сертификат не содержит цепочку, субъект должен быть назначен со следующими ролями:

    • Key Vault Certificates Userдля чтения сертификатов
    • Key Vault Crypto User для операций подписывания
    USER_ID=$(az ad signed-in-user show --query id -o tsv)
    az role assignment create --role "Key Vault Certificates User" --role "Key Vault Crypto User" --assignee $USER_ID --scope "/subscriptions/$AKV_SUB_ID/resourceGroups/$AKV_RG/providers/Microsoft.KeyVault/vaults/$AKV_NAME"
    

Дополнительные сведения о доступе Key Vault с помощью Azure RBAC см. в статье "Использование Azure RBAC" для управления доступом.

Использование политики доступа (устаревшая версия)

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

az account set --subscription $AKV_SUB_ID

Если сертификат содержит всю цепочку сертификатов, субъекту необходимо предоставить разрешение Signключа, разрешение Getсекрета и разрешения Getсертификата. Чтобы предоставить эти разрешения субъекту, выполните указанные ниже действия.

USER_ID=$(az ad signed-in-user show --query id -o tsv)
az keyvault set-policy -n $AKV_NAME --key-permissions sign --secret-permissions get --certificate-permissions get --object-id $USER_ID

Если сертификат не содержит цепочку, субъект должен быть предоставлен разрешение Signна ключ и разрешения Getна сертификат. Чтобы предоставить эти разрешения субъекту, выполните указанные ниже действия.

USER_ID=$(az ad signed-in-user show --query id -o tsv)
az keyvault set-policy -n $AKV_NAME --key-permissions sign --certificate-permissions get --object-id $USER_ID

Дополнительные сведения о назначении политики субъекту см. в статье "Назначение политики доступа".

Подписывай образы контейнеров с помощью сертификата в AKV

  1. Получите идентификатор ключа для сертификата. Сертификат в AKV может иметь несколько версий, следующая команда получает идентификатор ключа для последней $CERT_NAME версии сертификата.

    KEY_ID=$(az keyvault certificate show -n $CERT_NAME --vault-name $AKV_NAME --query 'kid' -o tsv) 
    
  2. Подпишите образ контейнера с помощью формата подписи COSE с помощью идентификатора ключа.

    Если сертификат содержит всю цепочку сертификатов, выполните следующую команду:

    notation sign --signature-format cose $IMAGE --id $KEY_ID --plugin azure-kv 
    

    Если сертификат не содержит цепочку, используйте --plugin-config ca_certs=<ca_bundle_file> параметр для передачи сертификатов ЦС в файле PEM в подключаемый модуль AKV, выполните следующую команду:

    notation sign --signature-format cose $IMAGE --id $KEY_ID --plugin azure-kv --plugin-config ca_certs=<ca_bundle_file> 
    

    Для проверки подлинности с помощью AKV по умолчанию следующие типы учетных данных, если они включены, будут проверены в порядке:

    Если вы хотите указать тип учетных данных, используйте дополнительную конфигурацию credential_typeподключаемого модуля. Например, вы можете явно задать credential_type для azurecli использования учетных данных Azure CLI, как показано ниже:

    notation sign --signature-format cose --id $KEY_ID --plugin azure-kv --plugin-config credential_type=azurecli $IMAGE
    

    В таблице ниже приведены значения различных типов учетных credential_type данных.

    Тип учетных данных Значение для credential_type
    Учетные данные среды environment
    Учетные данные удостоверения рабочей нагрузки workloadid
    Учетные данные управляемого удостоверения managedid
    Учетные данные для входа с помощью Azure CLI azurecli
  3. Просмотрите график подписанных изображений и связанных подписей.

    notation ls $IMAGE
    

    В следующем примере выходных данных сигнатура типа application/vnd.cncf.notary.signature , определяемого дайджестом sha256:d7258166ca820f5ab7190247663464f2dcb149df4d1b6c4943dcaac59157de8e , связана с $IMAGE.

    myregistry.azurecr.io/net-monitor@sha256:17cc5dd7dfb8739e19e33e43680e43071f07497ed716814f3ac80bd4aac1b58f
    └── application/vnd.cncf.notary.signature
        └── sha256:d7258166ca820f5ab7190247663464f2dcb149df4d1b6c4943dcaac59157de8e
    

Проверка подписи образа контейнера с помощью интерфейса командной строки нотации

  1. Добавьте корневой сертификат в именованное хранилище доверия для проверки подписи. Если у вас нет корневого сертификата, его можно получить из ЦС. В следующем примере корневой сертификат $ROOT_CERT добавляется в $STORE_NAME хранилище доверия.

    STORE_TYPE="ca" 
    STORE_NAME="wabbit-networks.io" 
    notation cert add --type $STORE_TYPE --store $STORE_NAME $ROOT_CERT  
    
  2. Перечислите корневой сертификат, чтобы подтвердить $ROOT_CERT успешное добавление.

    notation cert ls 
    
  3. Настройте политику доверия перед проверкой.

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

    cat <<EOF > ./trustpolicy.json
    {
        "version": "1.0",
        "trustPolicies": [
            {
                "name": "wabbit-networks-images",
                "registryScopes": [ "$REGISTRY/$REPO" ],
                "signatureVerification": {
                    "level" : "strict" 
                },
                "trustStores": [ "$STORE_TYPE:$STORE_NAME" ],
                "trustedIdentities": [
                    "x509.subject: $CERT_SUBJECT"
                ]
            }
        ]
    }
    EOF
    

    Приведенный выше trustpolicy.json файл определяет одну политику доверия с именем wabbit-networks-images. Эта политика доверия применяется ко всем артефактам, хранящимся в $REGISTRY/$REPO репозиториях. Именованное хранилище $STORE_NAME доверия типа $STORE_TYPE содержит корневые сертификаты. Кроме того, предполагается, что пользователь доверяет определенному удостоверению с субъектом $CERT_SUBJECTX.509. Дополнительные сведения см . в спецификации политики доверия и хранилища доверия.

  4. Используется notation policy для импорта конфигурации политики доверия из trustpolicy.json.

    notation policy import ./trustpolicy.json
    
  5. Отображение конфигурации политики доверия для подтверждения успешного импорта.

    notation policy show
    
  6. Используется notation verify для проверки целостности изображения:

    notation verify $IMAGE
    

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

    Successfully verified signature for myregistry.azurecr.io/net-monitor@sha256:17cc5dd7dfb8739e19e33e43680e43071f07497ed716814f3ac80bd4aac1b58f

Установка меток времени

Так как выпуск Нотации версии 1.2.0 нотация поддерживает метку времени соответствия RFC 3161 . Это улучшение расширяет доверие подписей, созданных в течение срока действия сертификата, доверяя центру метки времени (TSA), обеспечивая успешную проверку подписи даже после истечения срока действия сертификатов. В качестве подписи образа необходимо убедиться, что вы подписываете образы контейнеров метками времени, созданными доверенным TSA. Чтобы проверить метки времени, убедитесь, что вы доверяете подписывщику изображений и связанному TSA, и установить доверие с помощью хранилищ доверия и политик доверия. Метка времени снижает затраты, устраняя необходимость периодически повторного подписывания образов из-за истечения срока действия сертификата, что особенно важно при использовании краткосрочных сертификатов. Подробные инструкции по подписи и проверке с помощью метки времени см. в руководстве по метке времени нотарии проекта.

Вопросы и ответы

  • Что делать, если срок действия сертификата истек?

    Если срок действия сертификата истек, необходимо получить новый из доверенного поставщика ЦС вместе с новым закрытым ключом. Сертификат с истекшим сроком действия нельзя использовать для подписывания образов контейнеров. Для изображений, подписанных до истечения срока действия сертификата, они по-прежнему могут быть проверены успешно, если они были подписаны с меткой времени. Без метки времени проверка подписи завершится ошибкой, и вам потребуется повторно подписать эти изображения с помощью нового сертификата для успешной проверки.

  • Что делать, если сертификат отозван?

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

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

Нотация также предоставляет решения CI/CD в рабочем процессе Azure Pipeline и GitHub Actions:

Чтобы проверить развертывание подписанных образов в AKS или Kubernetes, выполните приведенные ниже действия.