Проверка Base Image и SBOM
Если мы хотим разрешить развертывание только определенных типов base image, мы можем сохранить эту информацию в attestation образа после ее получения.
В разделе Сканирование уязвимостей и проверка attestation в формате cosign-vuln уже включают информацию о base image.
Но здесь мы будем использовать другой подход: syft для генерации SBOM для образа.
Информация SBOM также включает сведения о base image.
В ACP (Alauda Container Platform) можно использовать задачу trivy или syft в Tekton Pipeline для генерации SBOM для образа.
Здесь мы используем задачу syft для генерации SBOM.
Содержание
Обзор функциональностиСценарии использованияПредварительные требованияОбзор процессаПошаговые инструкцииШаги 1–3: Базовая настройкаШаг 4: Создать пример pipelineШаг 5: Запустить пример pipelineШаг 6: Дождаться подписи PipelineRunШаг 7: Получить образ из PipelineRunШаг 8: (Необязательно) Получить attestation SBOMШаг 9: Проверить информацию о base imageШаг 9.1: Создать политику Kyverno для проверки информации о base imageШаг 9.2: Проверить политикуШаг 10: Очистить ресурсыОжидаемые результатыСсылкиОбзор функциональности
Этот метод использует инструменты, аналогичные syft, для генерации SBOM для образа, а затем использует Kyverno для проверки SBOM:
- Использовать Tekton Task
syftдля генерации SBOM для образа и прикрепления его к образу. - Настроить правила Kyverno для проверки SBOM.
- Использовать образ для создания Pod, чтобы проверить SBOM.
Сценарии использования
Следующие сценарии требуют обращения к рекомендациям в этом документе:
- Реализация проверки base image в кластерах Kubernetes с использованием Kyverno
- Применение политик безопасности, разрешающих развертывание только определенных base image
- Настройка автоматической генерации и проверки SBOM в CI/CD pipelines
- Обеспечение соответствия base image в production-средах
- Реализация мер безопасности supply chain для container images путем проверки информации об их base image
Предварительные требования
- Кластер Kubernetes с установленными Tekton Pipelines, Tekton Chains и Kyverno
- Registry с включенной возможностью push image
- Установленный и настроенный CLI
kubectlдля доступа к кластеру - Установленный CLI
cosign - Установленный CLI
jq
Обзор процесса
Пошаговые инструкции
Шаги 1–3: Базовая настройка
Эти шаги идентичны руководству Quick Start: Signed Provenance. Следуйте инструкциям в этом руководстве для выполнения следующих действий:
- Шаг 1: Сгенерировать ключи подписи
- Шаг 2: Настроить аутентификацию
- Шаг 3: Настроить Tekton Chains
- Получить signing secret
- Важно: Это используется только для удобства, чтобы здесь применялся глобальный signing certificate Chains. В реальном использовании можно использовать отдельный сертификат для подписи информации об уязвимостях образа.
- Импортируйте secret в namespace, в котором выполняется pipeline.
Шаг 4: Создать пример pipeline
Это ресурс Pipeline, который используется для сборки образа и генерации SBOM.
В этом руководстве показан упрощенный рабочий процесс: генерация Containerfile и вывод задачи git-clone выполняются непосредственно внутри pipeline.
В production-средах обычно делают следующее:
- Используют задачу
git-cloneдля получения исходного кода из репозитория - Собирают образ с помощью
Containerfile, который уже находится в исходном коде - Такой подход обеспечивает корректное управление версиями и сохраняет разделение между кодом и конфигурацией pipeline
Пояснение полей YAML
- То же самое, что и в Шаг 4: Создать пример pipeline, но дополнительно добавлено следующее:
workspaces:signkey: workspace для закрытых ключей и паролей, используемых для подписей образов.
tasks:syft-sbom: задача для генерации SBOM для образа и загрузки attestation. :::
Сохраните это в YAML-файл с именем chains-demo-5.yaml и примените его:
Шаг 5: Запустить пример pipeline
Это ресурс PipelineRun, который используется для запуска pipeline.
:::details {title="Пояснение полей YAML"}
- То же самое, что и в Шаг 5: Запустить пример pipeline. Ниже приведены только отличия.
workspacessignkey: имя secret с ключом подписи.secret.secretName: signing secret, подготовленный на предыдущем шаге Получить signing secret. Но вам нужно создать новый secret в том же namespace, что и PipelineRun. :::
Сохраните это в YAML-файл с именем chains-demo-5.pipelinerun.yaml и примените его:
Дождитесь завершения PipelineRun.
Шаг 6: Дождаться подписи PipelineRun
Дождитесь, пока у PipelineRun появится аннотация chains.tekton.dev/signed: "true".
Когда у PipelineRun появляется аннотация chains.tekton.dev/signed: "true", это означает, что образ подписан.
Шаг 7: Получить образ из PipelineRun
Этот образ будет использоваться для проверки SBOM.
Шаг 8: (Необязательно) Получить attestation SBOM
Если вам интересно содержимое attestation SBOM, вы можете продолжить чтение следующего раздела.
Подробнее об attestation CycloneDX SBOM см. в cyclonedx SBOM attestation
Получите открытый ключ подписи согласно разделу Получить открытый ключ подписи.
Результат будет похож на следующий и содержит информацию о компонентах образа.
:::details {title="cyclonedx SBOM attestation"}
:::details {title="Описание полей"}
predicateType: тип predicate.predicate:components: компоненты образа.bom-ref: BOM reference компонента.licenses: лицензии компонента.license: лицензия компонента.name: имя лицензии.id: идентификатор лицензии.
name: имя компонента.type: тип компонента.version: версия компонента.
metadata: метаданные образа.timestamp: временная метка образа.tools:components: компоненты инструмента.author: автор инструмента.name: имя инструмента.type: тип инструмента.version: версия инструмента. :::
Шаг 9: Проверить информацию о base image
Шаг 9.1: Создать политику Kyverno для проверки информации о base image
Для этого шага требуются права cluster administrator.
Подробнее о Kyverno ClusterPolicy см. в Kyverno ClusterPolicy
Политика выглядит следующим образом:
:::details {title="Пояснение полей YAML"}
- Политика в целом совпадает с политикой из Проверка подписи образа
spec.rules[0].verifyImages[].attestations[0].conditionstype: тип attestation CycloneDX SBOM —https://cyclonedx.org/bomattestors: то же самое, что и выше.conditions: условия, которые необходимо проверить.any: должно быть выполнено любое из условий.key: "{{ components[?type=='operating-system'] | [?name=='ubuntu' && (version=='22.04' || version=='24.04')] | length(@) }}": операционная система должна быть Ubuntu 22.04 или 24.04.key: "{{ components[?type=='operating-system'] | [?name=='alpine' && (version=='3.18' || version=='3.20')] | length(@) }}": операционная система должна быть Alpine 3.18 или 3.20. :::
Сохраните политику в YAML-файл с именем kyverno.verify-base-image.yaml и примените его:
Шаг 9.2: Проверить политику
В namespace policy, где определена политика, создайте Pod для проверки политики.
Используйте собранный образ для создания Pod.
Если ваша base image — Ubuntu 22.04 или 24.04, Pod будет создан успешно.
Измените условия в ClusterPolicy, чтобы разрешить только Alpine 3.18 или 3.20.
Затем создайте Pod для проверки политики.
Вы получите такой вывод:
Шаг 10: Очистить ресурсы
Удалите Pods, созданные на предыдущих шагах.
Удалите политику.
Ожидаемые результаты
После выполнения этого руководства:
- У вас будет рабочая конфигурация Tekton Chains для генерации SBOM и Kyverno для проверки base image
- Ваши container images автоматически будут включать информацию SBOM в своих attestation
- В указанном namespace можно будет развертывать только образы с допустимыми base image
- Образы с несоответствующими base image будут автоматически блокироваться политиками Kyverno
- Вы реализовали базовый механизм безопасности supply chain путем проверки информации о base image ваших container images
Это руководство создает основу для внедрения безопасности supply chain в ваши CI/CD pipelines. В production-среде следует:
- Настроить корректную изоляцию namespace и контроль доступа
- Реализовать безопасное управление ключами для ключей подписи
- Настроить мониторинг и оповещения о нарушениях политик
- Регулярно ротировать ключи подписи и обновлять политики безопасности