Проверяйте подписи образов контейнера с помощью Ratify и Политики Azure

Безопасность контейнеров имеет решающее значение в облачной среде для защиты рабочих нагрузок. Чтобы повысить безопасность на протяжении всего жизненного цикла образов контейнеров, корпорация Майкрософт представила платформу "Безопасная цепочка поставок контейнеров" (CSSC). На этапе развертывания платформы образы контейнеров развертываются в рабочих средах, таких как кластеры Службы Azure Kubernetes (AKS).

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

Ratify — это Cloud Native Computing Foundation (CNCF) проект в песочнице, поддерживаемый корпорацией Майкрософт. Это надежный механизм проверки, который проверяет метаданные безопасности образов контейнеров, таких как сигнатуры. Он позволяет развертывать только изображения, соответствующие заданным политикам.

Сценарии

В этой статье рассматриваются два основных сценария реализации проверки подписи образов контейнеров с помощью средства "Утвердить" в AKS. Сценарии отличаются в зависимости от способа управления сертификатами для подписывания и проверки: использование Azure Key Vault для традиционного управления сертификатами или использование службы подписи Microsoft Artifact для управления жизненным циклом сертификатов нулевого касания. Выберите сценарий, соответствующий текущему подходу к управлению сертификатами и требованиям к безопасности.

Использование Key Vault для управления сертификатами

Производитель образов создает и отправляет образы контейнеров в реестр контейнеров Azure в рамках непрерывной интеграции и конвейеров непрерывной доставки (CI/CD). Эти образы предназначены для потребителей образов для развертывания и запуска облачных рабочих нагрузок в кластерах AKS.

Производитель образов подписывает образы контейнеров в реестре контейнеров с помощью инструментов Notary Project (в частности, Notation) в конвейерах CI/CD. Ключи и сертификаты для подписывания безопасно хранятся в Key Vault.

Подписи нотаричного проекта создаются и хранятся в реестре контейнеров, где они ссылаются на соответствующие образы. Потребитель образов настраивает Ratify и политики на кластере AKS для проверки подписей проекта Notary для образов в процессе развертывания. Образы, которые не проходят проверку подписи, будут отклонены при развертывании, если для политики установлено значение Deny. Эта конфигурация помогает убедиться, что в кластере AKS развертываются только доверенные и неизмененные образы.

Как производитель образов, вы можете следовать этим статьям, чтобы подписать образы контейнеров в реестре контейнеров с помощью Key Vault:

Используйте подписание артефактов для управления сертификатами

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

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

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

Как производитель изображений, вы можете следовать этим статьям для подписывания образов контейнеров с помощью подписи артефактов:

Эта статья направляет вас, как потребителя образов, через процесс проверки подписей образов контейнеров с помощью Ratify и политики Azure на кластерах AKS.

Это важно

Если вы предпочитаете использовать управляемое решение вместо того, чтобы напрямую работать с open-source Ratify, вы можете выбрать политику целостности изображений AKS (предварительная версия), чтобы обеспечить целостность изображений в кластерах AKS.

Обзор проверки подписи

Ниже приведены высокоуровневые шаги для проверки подписи:

  1. Настройте удостоверения и элементы управления доступом для реестра контейнеров: настройте удостоверение, которое Ratify использует для доступа к реестру контейнеров с необходимыми ролями.

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

  3. Настройте Ratify в кластере AKS: настройте Ratify с помощью установки Helm chart как стандартную службу Kubernetes.

  4. Настройте настраиваемую политику Azure: создайте и назначьте настраиваемую политику Azure с требуемым эффектом политики: Deny или Audit.

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

  • С действием политики Deny для развертывания разрешены только образы, которые проходят проверку подписи. Изображения, которые не подписаны или подписаны ненадежными удостоверениями, запрещены.
  • С помощью эффекта политики Audit образы можно развернуть, но компоненты считаются несоответствующими для целей аудита.

Предпосылки

  • Установите и настройте последнюю версию Azure CLI или выполните команды в Azure Cloud Shell.
  • Установите Helm для установки Ratify, а также установите kubectl для устранения неполадок и проверки состояния.
  • Создайте или используйте кластер AKS с поддержкой издателя OpenID Connect (OIDC), выполнив действия по созданию поставщика OpenID Connect в службе Azure Kubernetes. Этот кластер AKS — это место, где развертываются образы контейнеров, устанавливается Ratify и применяются пользовательские политики Azure.
  • Подключите реестр контейнеров к кластеру AKS (если оно еще не подключено), выполнив действия, описанные в разделе "Проверка подлинности с помощью реестра контейнеров Azure" из службы Azure Kubernetes. Реестр контейнеров хранит образы контейнеров для развертывания в кластере AKS.
  • Включите дополнение политики Azure. Чтобы убедиться, что надстройка установлена или установить ее, если она еще не установлена, выполните действия, описанные в надстройке политики Azure для AKS.

Настройка элементов управления удостоверениями и доступом

Перед установкой Ratify в кластере AKS необходимо настроить надлежащие элементы управления удостоверениями и доступом. Ratify требует доступ к реестру контейнеров для загрузки образов и подписей контейнеров. При использовании Key Vault для управления сертификатами Ratify также требуется доступ для получения сертификатов, необходимых для проверки подписи.

Конфигурация удостоверений включает:

  • Создание управляемой идентичности, назначаемой пользователем, или использование существующей.
  • Настройка федеративных учетных данных для включения аутентификации нагрузки.
  • Предоставление соответствующих назначений ролей для доступа к реестру контейнеров.
  • Настройка разрешений доступа к Key Vault, если вы используете Key Vault для управления сертификатами.

Создание или использование управляемого удостоверения, назначаемого пользователем

Если у вас отсутствует управляемая идентичность, назначаемая пользователем, см. статью Создание управляемой идентичности, назначаемой пользователем. Ratify использует это удостоверение для доступа к ресурсам Azure, таким как Реестр контейнеров и (при необходимости) Key Vault для управления сертификатами.

Создать федеративную учетную запись для удостоверения личности

Настройте переменные среды с помощью следующего кода. Обновите значения переменных RATIFY_NAMESPACE и RATIFY_SA_NAME если вы не используете значения по умолчанию. Убедитесь, что используете те же значения при установке диаграммы Helm Ratify.

export AKS_RG=<aks-resource-group-name>
export AKS_NAME=<aks-name>
export AKS_OIDC_ISSUER=$(az aks show -n $AKS_NAME -g $AKS_RG --query "oidcIssuerProfile.issuerUrl" -otsv)

export IDENTITY_RG=<identity-resource-group-name>
export IDENTITY_NAME=<identity-name>
export IDENTITY_CLIENT_ID=$(az identity show --name  $IDENTITY_NAME --resource-group $IDENTITY_RG --query 'clientId' -o tsv)
export IDENTITY_OBJECT_ID=$(az identity show --name $IDENTITY_NAME --resource-group $IDENTITY_RG --query 'principalId' -otsv)

export RATIFY_NAMESPACE="gatekeeper-system"
export RATIFY_SA_NAME="ratify-admin"

Следующая команда создает федеративные учетные данные для управляемой идентичности. Учетные данные позволяют управляемому удостоверению проходить проверку подлинности с помощью токенов, выданных издателем OIDC, специально для учетной записи службы Kubernetes RATIFY_SA_NAME в пространстве имен RATIFY_NAMESPACE.

az identity federated-credential create \
--name ratify-federated-credential \
--identity-name "$IDENTITY_NAME" \
--resource-group "$IDENTITY_RG" \
--issuer "$AKS_OIDC_ISSUER" \
--subject system:serviceaccount:"$RATIFY_NAMESPACE":"$RATIFY_SA_NAME"

Настройка доступа к реестру контейнеров

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

export ACR_SUB=<acr-subscription-id>
export ACR_RG=<acr-resource-group>
export ACR_NAME=<acr-name>

az role assignment create \
--role acrpull \
--assignee-object-id ${IDENTITY_OBJECT_ID} \
--scope subscriptions/${ACR_SUB}/resourceGroups/${ACR_RG}/providers/Microsoft.ContainerRegistry/registries/${ACR_NAME}

Настройка доступа к Key Vault

Если вы используете подпись артефактов для управления сертификатами, пропустите этот шаг.

Роль Key Vault Secrets User необходима для вашей учётной записи, чтобы получить всю цепочку сертификатов из вашего хранилища ключей. Чтобы назначить роль, используйте следующий код:

export AKV_SUB=<acr-subscription-id>
export AKV_RG=<acr-resource-group>
export AKV_NAME=<acr-name>

az role assignment create \
--role "Key Vault Secrets User" \
--assignee ${IDENTITY_OBJECT_ID} \
--scope "/subscriptions/${AKV_SUB}/resourceGroups/${AKV_RG}/providers/Microsoft.KeyVault/vaults/${AKV_NAME}"

Настройка Ratify в кластере AKS с включенной политикой Azure

С правильной настройкой параметров удостоверений и управления доступом, теперь вы можете установить Ratify в кластере AKS. Ratify интегрируется с службой Azure Policy для применения политик проверки подписи. Процесс установки включает развертывание Ratify с использованием диаграмм Helm и определенными параметрами конфигурации, которые определяют, как следует проверять подписи образов контейнера.

В следующих разделах рассматриваются два ключевых аспекта установки "Утвердить".

  • Общие сведения о параметрах диаграмм Helm, необходимых для подхода к управлению сертификатами (Key Vault или подписывание артефактов)
  • Установка "Подтверждение" с соответствующей конфигурацией для включения проверки подписи

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

Узнайте свои параметры чарта Helm

При установке Helm chart для Ratify необходимо передать значения параметрам с помощью флага --set либо путем предоставления файла пользовательских значений. Эти значения используются для настройки Ratify для проверки подписи. Полный список параметров см. в документации по Helm chart.

Необходимо настроить следующее:

  • Учетная запись, настроенная ранее для доступа к реестру контейнеров и хранилищу ключей.
  • Сертификат, хранящийся в Key Vault для проверки подписи.
  • Политика доверия нотариального проекта для проверки подписи, включая registryScopes, trustStores и trustedIdentities.

Эта таблица содержит сведения о параметрах:

Параметр Description Ценность
azureWorkloadIdentity.clientId Идентификатор клиента для удостоверения рабочей нагрузки Azure "$IDENTITY_CLIENT_ID"
oras.authProviders.azureWorkloadIdentityEnabled Идентификация рабочей нагрузки Azure для аутентификации реестра контейнеров - включить или отключить true
azurekeyvault.enabled Получение сертификатов из Key Vault (включение или отключение) true
azurekeyvault.vaultURI URI ресурса Key Vault "https://$AKV_NAME.vault.azure.net"
azurekeyvault.tenantId Идентификатор клиента ресурса Key Vault "$AKV_TENANT_ID"
azurekeyvault.certificates[0].name Имя сертификата "$CERT_NAME"
notation.trustPolicies[0].registryScopes[0] URI репозитория, к которому применяется политика "$REPO_URI"
notation.trustPolicies[0].trustStores[0] Доверенные хранилища, в которых хранятся сертификаты типа ca или tsa. ca:azurekeyvault
notation.trustPolicies[0].trustedIdentities[0] Поле субъекта сертификата подписи, при этом префикс x509.subject: указывает на то, чему вы доверяете "x509.subject: $SUBJECT"

Используя метку времени для изображений, вы можете убедиться, что изображения, подписанные до истечения срока действия сертификата, по-прежнему могут быть успешно проверены. Добавьте следующие параметры для конфигурации службы отметки времени (TSA):

Параметр Description Ценность
notationCerts[0] Путь к файлу корневого сертификата TSA в формате PEM "$TSA_ROOT_CERT_FILEPATH"
notation.trustPolicies[0].trustStores[1] Другое хранилище доверия, в котором хранится корневой сертификат TSA tsa:notationCerts[0]

Если у вас несколько сертификатов для проверки подписи, укажите дополнительные параметры:

Параметр Description Ценность
azurekeyvault.certificates[1].name Имя сертификата "$CERT_NAME_2"
notation.trustPolicies[0].trustedIdentities[1] Другое поле субъекта сертификата подписи, указывающее, чему вы доверяете "x509.subject: $SUBJECT_2"

Установка диаграммы Хельма с требуемыми параметрами и значениями

Убедитесь, что версия Helm chart составляет не менее 1.15.0, что соответствует установке версии Ratify 1.4.0 или более поздней. В следующем примере используется версия 1.15.0диаграммы Helm.

Настройте дополнительные переменные среды для установки:

export CHART_VER="1.15.0"
export REPO_URI="$ACR_NAME.azurecr.io/<namespace>/<repo>"
export SUBJECT="<Subject-of-signing-certificate>"
export AKV_TENANT_ID="$(az account show --query tenantId --output tsv)"

helm repo add ratify https://notaryproject.github.io/ratify
helm repo update

helm install ratify ratify/ratify --atomic --namespace $RATIFY_NAMESPACE --create-namespace --version $CHART_VER --set provider.enableMutation=false --set featureFlags.RATIFY_CERT_ROTATION=true \
--set azureWorkloadIdentity.clientId=$IDENTITY_CLIENT_ID \
--set oras.authProviders.azureWorkloadIdentityEnabled=true \
--set azurekeyvault.enabled=true \
--set azurekeyvault.vaultURI="https://$AKV_NAME.vault.azure.net" \
--set azurekeyvault.certificates[0].name="$CERT_NAME" \
--set azurekeyvault.tenantId="$AKV_TENANT_ID" \  
--set notation.trustPolicies[0].registryScopes[0]="$REPO_URI" \
--set notation.trustPolicies[0].trustStores[0]="ca:azurekeyvault" \
--set notation.trustPolicies[0].trustedIdentities[0]="x509.subject: $SUBJECT"

Для поддержки метки времени необходимо указать дополнительные параметры: --set-file notationCerts[0]="$TSA_ROOT_CERT_FILE" и --set notation.trustPolicies[0].trustStores[1]="ca:azurekeyvault".

Это важно

Для изображений, которые не связаны с политикой доверия, проверка подписи завершается ошибкой. Например, если образы не в репозитории $REPO_URI, проверка подписи для этих образов завершается ошибкой. Можно добавить несколько репозиториев, указав дополнительные параметры. Например, чтобы добавить другой репозиторий для политики notation.trustPolicies[0]доверия, включите параметр --set notation.trustPolicies[0].registryScopes[1]="$REPO_URI_1".

Настройка настраиваемой политики Azure

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

Политика Azure предлагает два режима принудительного применения:

  • Deny: блокирует развертывание образов, которые не проходят проверку подписи, чтобы в кластере выполнялись только доверенные образы.
  • Audit: разрешает все развертывания, но помечает соответствующие ресурсы для мониторинга и отчетности.

Эффект Audit полезен на начальном этапе настройки или тестирования. Его можно использовать для проверки конфигурации без риска сбоев служб (из-за неправильных параметров) в рабочих средах.

Назначение новой политики кластеру AKS

Создайте настраиваемую политику Azure для проверки подписи:

export CUSTOM_POLICY=$(curl -L https://raw.githubusercontent.com/notaryproject/ratify/refs/tags/v1.4.0/library/default/customazurepolicy.json)
export DEFINITION_NAME="ratify-default-custom-policy"
export DEFINITION_ID=$(az policy definition create --name "$DEFINITION_NAME" --rules "$(echo "$CUSTOM_POLICY" | jq .policyRule)" --params "$(echo "$CUSTOM_POLICY" | jq .parameters)" --mode "Microsoft.Kubernetes.Data" --query id -o tsv)

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

Либо можно установить эффект политики на Audit. Этот эффект политики позволяет развертывать образы, которые не прошли проверку подписи, при этом кластер AKS и связанные рабочие нагрузки отмечаются как соответствующие требованиям.

Назначьте политику кластеру AKS с эффектом Denyпо умолчанию:

export POLICY_SCOPE=$(az aks show -g "$AKS_RG" -n "$AKS_NAME" --query id -o tsv)
az policy assignment create --policy "$DEFINITION_ID" --name "$DEFINITION_NAME" --scope "$POLICY_SCOPE"

Чтобы изменить эффект Audit политики, можно передать другой параметр в az policy assignment create команду. Рассмотрим пример.

az policy assignment create --policy "$DEFINITION_ID" --name "$DEFINITION_NAME" --scope "$POLICY_SCOPE" -p "{\"effect\": {\"value\":\"Audit\"}}"

Замечание

Выполнение задания занимает около 15 минут.

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

kubectl get constraintTemplate ratifyverification

Ниже приведен пример выходных данных для успешного назначения политики:

NAME                 AGE
ratifyverification   11m

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

Разверните ваши образы и проверьте результаты применения политики

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

Проверьте три сценария, чтобы проверить настройку:

  • Подписанные образы с доверенными сертификатами: следует успешно развернуть.
  • Неподписанные изображения: должны быть заблокированы (с использованием эффекта Deny) или помечены как соответствующие (с использованием эффекта Audit).
  • Изображения, подписанные ненадежными сертификатами: следует блокировать (с эффектом Deny ) или помечены как соответствующие (с эффектом Audit ).

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

Используйте эффект политики «Запретить»

Эффект политики Deny позволяет развёртывать только образы, подписанные доверенными идентичностями. Вы можете начать развертывание рабочих нагрузок, чтобы наблюдать за последствиями. В этой статье описывается использование команды kubectl для развертывания pod. Аналогичным образом можно развернуть рабочие нагрузки с помощью диаграммы Helm или любых шаблонов, которые активируют установку Helm.

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

export IMAGE_SIGNED=<signed-image-reference>
export IMAGE_UNSIGNED=<unsigned-image-reference>
export IMAGE_SIGNED_UNTRUSTED=<signed-untrusted-image-reference>

Выполните следующую команду. Так как $IMAGE_SIGNED ссылается на образ, подписанный доверенным удостоверением и настроенный в системе "Ratify", он разрешен для развертывания.

kubectl run demo-signed --image=$IMAGE_SIGNED

Ниже приведен пример выходных данных для успешного развертывания:

pod/demo-signed created

Переменная $IMAGE_UNSIGNED ссылается на изображение, которое не подписано. Переменная $IMAGE_SIGNED_UNTRUSTED ссылается на изображение, подписанное другим сертификатом, которым вы не доверяете. Таким образом, эти два образа запрещены для развертывания. Например, выполните следующую команду:

kubectl run demo-unsigned --image=$IMAGE_UNSIGNED

Пример выходных данных для отклоненного развертывания:

Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [azurepolicy-ratifyverification-077bac5b63d37da0bc4a] Subject failed verification: $IMAGE_UNSIGNED

Следующую команду можно использовать для просмотра журналов Ratify. Затем можно выполнить поиск по журналам с помощью текста verification response for subject $IMAGE_UNSIGNED. errorReason Проверьте поле, чтобы понять причину любого отклоненного развертывания.

kubectl logs <ratify-pod> -n $RATIFY_NAMESPACE

Использование эффекта политики аудита

Посредством эффекта Audit политики для развертывания разрешены неподписанные образы или образы, подписанные ненадежными удостоверениями. Однако кластер AKS и связанные компоненты помечены как noncompliant. Дополнительные сведения о том, как просмотреть несоответствующие ресурсы и понять причины, см. в статье "Получение данных о соответствии ресурсам Azure".

Очистка

Используйте следующие команды, чтобы удалить "Ratify" и очистить определения пользовательских ресурсов (CRD):

helm delete ratify --namespace $RATIFY_NAMESPACE
kubectl delete crd stores.config.ratify.deislabs.io verifiers.config.ratify.deislabs.io certificatestores.config.ratify.deislabs.io policies.config.ratify.deislabs.io keymanagementproviders.config.ratify.deislabs.io namespacedkeymanagementproviders.config.ratify.deislabs.io namespacedpolicies.config.ratify.deislabs.io namespacedstores.config.ratify.deislabs.io namespacedverifiers.config.ratify.deislabs.io

Удалите назначение и определение политики с помощью следующих команд:

az policy assignment delete --name "$DEFINITION_NAME" --scope "$POLICY_SCOPE"
az policy definition delete --name "$DEFINITION_NAME"

Часто задаваемые вопросы

Как настроить сертификаты для проверки подписи, если у меня нет доступа к Key Vault?

В некоторых случаях потребители изображений могут не иметь доступа к сертификатам, используемым для проверки подписи. Чтобы проверить подписи, необходимо скачать корневой сертификат УЦ в формате PEM и указать связанные параметры для установки Helm chart.

Следующая команда аналогична предыдущей команде установки, но без каких-либо параметров, связанных с сертификатами Key Vault. Доверительное хранилище нотариального проекта ссылается на файл сертификата, переданный в параметре notationCerts[0].

helm install ratify ratify/ratify --atomic --namespace $RATIFY_NAMESPACE --create-namespace --version $CHART_VER --set provider.enableMutation=false --set featureFlags.RATIFY_CERT_ROTATION=true \
--set azureWorkloadIdentity.clientId=$IDENTITY_CLIENT_ID \
--set oras.authProviders.azureWorkloadIdentityEnabled=true \
--set-file notationCerts[0]="<root-ca-certifice-filepath>"
--set notation.trustPolicies[0].registryScopes[0]="$REPO_URI" \
--set notation.trustPolicies[0].trustStores[0]="ca:notationCerts[0]" \
--set notation.trustPolicies[0].trustedIdentities[0]="x509.subject: $SUBJECT"

Так как notationCerts[0] используется для корневого сертификата ЦС, если у вас есть дополнительный файл сертификата для целей метки времени, обязательно используйте правильный индекс. Например, если notationCerts[1] используется для корневого файла сертификата TSA, используйте хранилище notation.trustPolicies[0].trustStores[1]" доверия со значением "tsa:notationCerts[1]".

Какие действия следует предпринять, если политика Azure отключена в кластере AKS?

Если политика Azure отключена в кластере AKS, необходимо установить OPA Gatekeeper в качестве контроллера политики перед установкой "Ратифицируйте".

Замечание

Политика Azure должна оставаться отключенной, так как gatekeeper конфликтует с надстройкой политики Azure в кластерах AKS. Если вы хотите включить Azure Policy позже, необходимо удалить Gatekeeper и Ratify, а затем следовать этой статье, чтобы настроить Ratify с включенной поддержкой Azure Policy.

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts

helm install gatekeeper/gatekeeper  \
--name-template=gatekeeper \
--namespace gatekeeper-system --create-namespace \
--set enableExternalData=true \
--set validatingWebhookTimeoutSeconds=5 \
--set mutatingWebhookTimeoutSeconds=2 \
--set externaldataProviderResponseCacheTTL=10s

Затем установите Ratify, как описано в предыдущих шагах. После установки примените политики с помощью следующих команд. По умолчанию для политики задано значение Deny. Вы можете обратиться к документации по нарушениям Gatekeeper, чтобы обновить файл constraint.yaml для различных эффектов политики.

kubectl apply -f https://notaryproject.github.io/ratify/library/default/template.yaml
kubectl apply -f https://notaryproject.github.io/ratify/library/default/samples/constraint.yaml

Как я могу обновить настройки Ratify после установки?

Утвержденные конфигурации — это пользовательские ресурсы Kubernetes. Эти ресурсы можно обновить, не переустановив Ratify.

  • Чтобы обновить конфигурации, связанные с Key Vault, используйте настраиваемый ресурс Ratify KeyManagementProvider с типом azurekeyvault. Чтобы обновить конфигурации, связанные с подписью артефактов, используйте настраиваемый ресурс Ratify KeyManagementProvider с типом inline. Следуйте документации.
  • Чтобы обновить политики доверия и хранилища в Notary Project, используйте настраиваемый ресурс Ratify Verifier. Следуйте документации.
  • Для аутентификации и взаимодействия с реестром контейнеров (или другими совместимыми с OCI реестрами) используйте настраиваемый ресурс Ratify Store. Следуйте документации.

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

Эта статья применима для проверки подписей нотариального проекта вне зависимости от используемых инструментов, которые могут генерировать подписи, совместимые с нотариальным проектом. Ratify также поддерживает проверку других типов подписей. Дополнительные сведения см. в руководстве пользователя «Ratify».

  • Last updated on