Проверка базового образа и SBOM
Если мы хотим разрешить развертывание только определённых типов базовых образов,
мы можем сохранить эту информацию в аттестации образа после её получения.
В разделе Сканирование уязвимостей и проверка аттестации формата cosign-vuln уже включают информацию о базовом образе.
Но здесь мы используем другой подход — с помощью syft генерируем SBOM для образа.
Информация SBOM также включает данные о базовом образе.
В ACP (Alauda Container Platform) вы можете использовать задачи trivy или syft в Tekton Pipeline для генерации SBOM для образа.
Здесь мы используем задачу syft для генерации SBOM.
Содержание
Обзор функцииСценарии использованияПредварительные требованияОбзор процессаПошаговые инструкцииШаги 1-3: Базовая настройкаШаг 4: Создание примерного пайплайнаШаг 5: Запуск примерного пайплайнаШаг 6: Ожидание подписи PipelineRunШаг 7: Получение образа из PipelineRunШаг 8: (Опционально) Получение аттестации SBOMШаг 9: Проверка информации о базовом образеШаг 9.1: Создание политики Kyverno для проверки информации о базовом образеШаг 9.2: Проверка политикиШаг 10: Очистка ресурсовОжидаемые результатыСсылкиОбзор функции
Этот метод использует инструменты, похожие на syft, для генерации SBOM для образа, а затем применяет Kyverno для проверки SBOM:
- Использовать задачу Tekton
syftдля генерации SBOM для образа и прикрепления её к образу. - Настроить правила Kyverno для проверки SBOM.
- Использовать образ для создания Pod и проверки SBOM.
Сценарии использования
Следующие сценарии требуют обращения к рекомендациям этого документа:
- Реализация проверки базового образа в кластерах Kubernetes с помощью Kyverno
- Применение политик безопасности, разрешающих развертывание только определённых базовых образов
- Настройка автоматической генерации и проверки SBOM в CI/CD пайплайнах
- Обеспечение соответствия базового образа в продуктивных средах
- Внедрение мер безопасности цепочки поставок контейнерных образов путём проверки информации о базовом образе
Предварительные требования
- Kubernetes кластер с установленными Tekton Pipelines, Tekton Chains и Kyverno
- Реестр с разрешённой загрузкой образов
- Установленный и настроенный CLI
kubectlдля доступа к кластеру - Установленный CLI инструмент
cosign - Установленный CLI инструмент
jq
Обзор процесса
Пошаговые инструкции
Шаги 1-3: Базовая настройка
Эти шаги идентичны руководству Быстрый старт: Подписанная Provenance. Пожалуйста, следуйте инструкциям в этом руководстве для:
- Шаг 1: Генерация ключей подписи
- Шаг 2: Настройка аутентификации
- Шаг 3: Настройка Tekton Chains
- Получение секрета подписи
- Важно: Это сделано для удобства, здесь используется глобальный сертификат подписи Chains. В реальном использовании можно применять отдельный сертификат для подписи информации об уязвимостях образа.
- Импортируйте секрет в namespace, где выполняется пайплайн.
Шаг 4: Создание примерного пайплайна
Это ресурс Pipeline, который используется для сборки образа и генерации SBOM.
В этом руководстве демонстрируется упрощённый рабочий процесс, где Containerfile и вывод задачи git-clone генерируются внутри пайплайна.
В продуктивных средах обычно:
- Используют задачу
git-cloneдля получения исходного кода из репозитория - Строят образ с использованием Containerfile, который находится в исходном коде
- Такой подход обеспечивает корректное управление версиями и разделение кода и конфигурации пайплайна
Объяснение полей YAML
- Аналогично Шагу 4: Создание примерного пайплайна, но добавлено следующее:
workspaces:signkey: Рабочее пространство для приватных ключей и паролей, используемых для подписей образов.
tasks:syft-sbom: Задача для генерации SBOM для образа и загрузки аттестации. :::
Сохраните в файл с именем chains-demo-5.yaml и примените командой:
Шаг 5: Запуск примерного пайплайна
Это ресурс PipelineRun, который используется для запуска пайплайна.
:::details {title="Объяснение полей YAML"}
- Аналогично Шагу 5: Запуск примерного пайплайна. Ниже только отличия.
workspacessignkey: имя секрета с ключом подписи.secret.secretName: Секрет подписи, подготовленный на предыдущем шаге Получение секрета подписи. Но нужно создать новый секрет в том же namespace, что и PipelineRun. :::
Сохраните в файл с именем chains-demo-5.pipelinerun.yaml и примените командой:
Дождитесь завершения PipelineRun.
Шаг 6: Ожидание подписи PipelineRun
Дождитесь, пока у PipelineRun появится аннотация chains.tekton.dev/signed: "true".
Когда у PipelineRun появится аннотация chains.tekton.dev/signed: "true", это означает, что образ подписан.
Шаг 7: Получение образа из PipelineRun
Этот образ будет использоваться для проверки SBOM.
Шаг 8: (Опционально) Получение аттестации SBOM
Если вас интересует содержимое аттестации SBOM, вы можете продолжить чтение.
Более подробная информация об аттестации cyclonedx SBOM доступна по ссылке cyclonedx SBOM attestation
Получите публичный ключ подписи согласно разделу Получение публичного ключа подписи.
Вывод будет похож на следующий, содержащий информацию о компонентах образа.
:::details {title="Аттестация cyclonedx SBOM"}
:::details {title="Описание полей"}
predicateType: Тип предиката.predicate:components: Компоненты образа.bom-ref: Ссылка BOM компонента.licenses: Лицензии компонента.license: Лицензия компонента.name: Название лицензии.id: Идентификатор лицензии.
name: Название компонента.type: Тип компонента.version: Версия компонента.
metadata: Метаданные образа.timestamp: Временная метка образа.tools:components: Компоненты инструмента.author: Автор инструмента.name: Название инструмента.type: Тип инструмента.version: Версия инструмента. :::
Шаг 9: Проверка информации о базовом образе
Шаг 9.1: Создание политики Kyverno для проверки информации о базовом образе
Этот шаг требует прав администратора кластера.
Более подробная информация о Kyverno ClusterPolicy доступна по ссылке Kyverno ClusterPolicy
Политика выглядит следующим образом:
:::details {title="Объяснение полей YAML"}
- Политика в целом совпадает с политикой из раздела Проверка подписи образа
spec.rules[0].verifyImages[].attestations[0].conditionstype: Тип аттестации 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. :::
Сохраните политику в файл с именем kyverno.verify-base-image.yaml и примените командой:
Шаг 9.2: Проверка политики
В namespace policy, где определена политика, создайте Pod для проверки политики.
Используйте собранный образ для создания Pod.
Если ваш базовый образ — Ubuntu 22.04 или 24.04, Pod будет успешно создан.
Измените условия в ClusterPolicy, чтобы разрешить только Alpine 3.18 или 3.20.
Затем создайте Pod для проверки политики.
Вы получите вывод примерно такого вида:
Шаг 10: Очистка ресурсов
Удалите Pods, созданные на предыдущих шагах.
Удалите политику.
Ожидаемые результаты
После выполнения этого руководства:
- У вас настроена работа с Tekton Chains для генерации SBOM и Kyverno для проверки базового образа
- Ваши контейнерные образы автоматически включают информацию SBOM в свои аттестации
- В указанном namespace разрешено развертывание только образов с допустимыми базовыми образами
- Образы с несоответствующими базовыми образами автоматически блокируются политиками Kyverno
- Вы реализовали базовый контроль безопасности цепочки поставок, проверяя информацию о базовом образе контейнерных образов
Это руководство предоставляет основу для реализации безопасности цепочки поставок в ваших CI/CD пайплайнах. В продуктивной среде рекомендуется:
- Настроить правильную изоляцию namespace и контроль доступа
- Реализовать безопасное управление ключами подписи
- Настроить мониторинг и оповещения о нарушениях политик
- Регулярно обновлять ключи подписи и политики безопасности