Проверка базового образа и 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 и контроль доступа
- Реализовать безопасное управление ключами подписи
- Настроить мониторинг и оповещения о нарушениях политик
- Регулярно менять ключи подписи и обновлять политики безопасности