Проверка Base Image и SBOM
Если мы хотим разрешить к развертыванию только определенные типы base image, мы можем сохранить эту информацию в image attestation после ее получения.
В разделе Сканирование и проверка уязвимостей attestation в формате cosign-vuln уже включают информацию о base image.
Но здесь мы воспользуемся другим подходом: используем syft для генерации SBOM для image.
Информация SBOM также включает сведения о base image.
В ACP (Alauda Container Platform) можно использовать задачу trivy или syft в Tekton Pipeline для генерации SBOM для image.
Здесь мы используем задачу syft для генерации SBOM.
Содержание
Обзор функциональностиСценарии использованияПредварительные требованияОбзор процессаПошаговые инструкцииШаги 1–3: Базовая настройкаШаг 4: Создание примера PipelineШаг 5: Запуск примера PipelineШаг 6: Дождаться, пока PipelineRun будет подписанШаг 7: Получить image из PipelineRunШаг 8: (Необязательно) Получить SBOM attestationШаг 9: Проверка информации о base imageШаг 9.1: Создать политику Kyverno для проверки информации о base imageШаг 9.2: Проверка политикиШаг 10: Очистка ресурсовОжидаемые результатыСсылкиОбзор функциональности
Этот метод использует инструменты, аналогичные syft, для генерации SBOM для image, а затем использует Kyverno для проверки SBOM:
- Использовать Tekton Task
syftдля генерации SBOM для image и прикрепить его к image. - Настроить правила Kyverno для проверки SBOM.
- Использовать image для создания Pod, чтобы проверить SBOM.
Сценарии использования
Следующие сценарии требуют обращения к рекомендациям в этом документе:
- Реализация проверки base image в кластерах Kubernetes с помощью Kyverno
- Принудительное применение политик безопасности, разрешающих к развертыванию только определенные base image
- Настройка автоматической генерации и проверки SBOM в CI/CD pipelines
- Обеспечение соответствия base image в production-средах
- Реализация controls безопасности supply chain для container images путем проверки информации об их base image
Предварительные требования
- Кластер Kubernetes с установленными Tekton Pipelines, Tekton Chains и Kyverno
- Registry с включенной возможностью push image
- Установленный и настроенный
kubectlCLI для доступа к кластеру - Установленный
cosignCLI tool - Установленный
jqCLI tool
Обзор процесса
Пошаговые инструкции
Шаги 1–3: Базовая настройка
Эти шаги идентичны руководству Quick Start: Signed Provenance. Следуйте инструкциям в этом руководстве для:
- Шаг 1: Generate Signing Keys
- Шаг 2: Set up Authentication
- Шаг 3: Configure Tekton Chains
- Получение signing secret
- Важно: Здесь это используется только для удобства, поэтому применяется глобальный signing certificate Chains. В реальном использовании можно использовать отдельный certificate для подписания информации об уязвимостях image.
- Импортируйте secret в namespace, где выполняется pipeline.
Шаг 4: Создание примера Pipeline
Это ресурс Pipeline, который используется для сборки image и генерации SBOM.
В этом руководстве демонстрируется упрощенный workflow, в котором Containerfile и output задачи git-clone генерируются inline внутри pipeline.
В production-средах обычно:
- Используют задачу
git-cloneдля получения исходного кода из репозитория - Собирают image с использованием Containerfile, который уже находится в исходном коде
- Такой подход обеспечивает корректный version control и сохраняет разделение между кодом и конфигурацией pipeline
Explanation of YAML fields
- То же самое, что и в Шаг 4: Create a Sample Pipeline, но добавляет следующий контент:
workspaces:signkey: workspace для private keys и passwords, используемых для подписей image.
tasks:syft-sbom: задача для генерации SBOM для image и загрузки attestation. :::
Сохраните это в yaml-файл с именем chains-demo-5.yaml и примените его:
Шаг 5: Запуск примера Pipeline
Это ресурс PipelineRun, который используется для запуска pipeline.
:::details {title="Explanation of YAML fields"}
- То же самое, что и в Шаг 5: Run a Sample Pipeline. Ниже приведены только различия.
workspacessignkey: имя secret с signing key.secret.secretName: signing secret, подготовленный на предыдущем шаге Get the signing secret. Но вам нужно создать новый secret в том же namespace, что и pipeline run. :::
Сохраните это в yaml-файл с именем chains-demo-5.pipelinerun.yaml и примените его:
Дождитесь завершения PipelineRun.
Шаг 6: Дождаться, пока PipelineRun будет подписан
Дождитесь, пока у PipelineRun появится аннотация chains.tekton.dev/signed: "true".
Когда у PipelineRun появляется аннотация chains.tekton.dev/signed: "true", это означает, что image подписан.
Шаг 7: Получить image из PipelineRun
Этот image будет использоваться для проверки SBOM.
Шаг 8: (Необязательно) Получить SBOM attestation
Если вам интересен содержимое SBOM attestation, вы можете продолжить чтение следующего раздела.
Более подробную информацию о cyclonedx SBOM attestation см. в cyclonedx SBOM attestation
Получите signing public key в соответствии с разделом Получение signing public key.
Вывод будет похож на следующий, он содержит информацию о components image.
:::details {title="cyclonedx SBOM attestation"}
:::details {title="Description of the fields"}
predicateType: тип predicate.predicate:components: components image.bom-ref: BOM reference компонента.licenses: licenses компонента.license: license компонента.name: имя license.id: идентификатор license.
name: имя компонента.type: тип компонента.version: версия компонента.
metadata: метаданные image.timestamp: временная метка image.tools:components: components инструмента.author: автор инструмента.name: имя инструмента.type: тип инструмента.version: версия инструмента. :::
Шаг 9: Проверка информации о base image
Шаг 9.1: Создать политику Kyverno для проверки информации о base image
Этот шаг требует прав cluster administrator.
Более подробную информацию о Kyverno ClusterPolicy см. в Kyverno ClusterPolicy
Политика выглядит следующим образом:
:::details {title="Explanation of YAML fields"}
- Политика в значительной степени совпадает с политикой из Image Signature Verification
spec.rules[0].verifyImages[].attestations[0].conditionstype: тип cyclonedx SBOM attestation —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 для проверки политики.
Используйте собранный image для создания Pod.
Если ваш base image — Ubuntu 22.04 или 24.04, Pod будет создан успешно.
Измените условия в ClusterPolicy, чтобы разрешить только Alpine 3.18 или 3.20.
Затем создайте Pod для проверки политики.
Получите такой вывод:
Шаг 10: Очистка ресурсов
Удалите Pod, созданные на предыдущих шагах.
Удалите политику.
Ожидаемые результаты
После завершения этого руководства:
- У вас будет рабочая конфигурация Tekton Chains для генерации SBOM и Kyverno для проверки base image
- Ваши container images будут автоматически включать информацию SBOM в свои attestations
- В указанном namespace к развертыванию будут допускаться только image с допустимыми base image
- Image с несоответствующими base image будут автоматически блокироваться политиками Kyverno
- Вы реализуете базовый control безопасности supply chain путем проверки информации о base image ваших container images
Это руководство создает основу для реализации безопасности supply chain в ваших CI/CD pipelines. В production-среде следует:
- Настроить корректную изоляцию namespace и controls доступа
- Реализовать безопасное управление ключами для signing keys
- Настроить monitoring и alerting на нарушения политик
- Регулярно ротировать signing keys и обновлять политики безопасности