Понимание Tekton Chains
Tekton Chains — это мощный компонент безопасности в экосистеме Tekton, который помогает защищать вашу цепочку поставок программного обеспечения, создавая, подписывая и сохраняя происхождение артефактов, построенных с помощью Tekton Pipelines. В этом документе представлено подробное объяснение работы Tekton Chains и его ключевых компонентов.
Содержание
ТерминологияЗачем нужен Tekton ChainsПроблема безопасности цепочки поставок программного обеспеченияРешение Tekton ChainsПреимуществаСценарииСценарий 1: Проверка подписи образаСценарий 2: Проверка происхождения системы сборкиСценарий 3: Проверка репозитория исходного кодаСценарий 4: Сканирование уязвимостей и проверкаСценарий 5: Проверка базового образа и SBOMСценарий 6: Проверка соответствия лицензиямСценарий 7: Проверка подписи без ключейОграничения и недостаткиПринципыКак работает Tekton ChainsГенерация происхожденияПроцесс подписиПримеры конфигурацииБазовая конфигурация SLSA v1.0Type Hinting1. Комбинация CHAINS-GIT_URL и CHAINS-GIT_COMMIT2. *ARTIFACT_INPUTS3. Комбинация IMAGE_URL и IMAGE_DIGEST4. IMAGES5. Комбинация ARTIFACT_URI / ARTIFACT_DIGEST6. *ARTIFACT_OUTPUTSВажные параметрыКонфигурация храненияСценарии использованияПример конфигурацииКонфигурация подписиСценарии использованияПример конфигурацииСсылкиТерминология
Аттестация имеет несколько типов предикатов.
Зачем нужен Tekton Chains
Проблема безопасности цепочки поставок программного обеспечения
В традиционных конвейерах разработки и доставки программного обеспечения обеспечение целостности и безопасности артефактов на протяжении всей цепочки поставок представляет значительные трудности:
- Отсутствие трассируемости: Без надлежащей информации о происхождении сложно проверить, откуда пришли артефакты и как они были построены
- Риски подделки: Артефакты могут быть изменены на различных этапах без обнаружения
- Сложности проверки: Потребители артефактов не имеют надёжного способа проверить их подлинность
- Проблемы с соответствием требованиям: Организациям сложно соответствовать растущим нормативным требованиям по безопасности цепочки поставок ПО
Эти проблемы привели к громким атакам на цепочки поставок, таким как SolarWinds, когда вредоносный код был внедрён в процесс сборки, затронув тысячи организаций.
Решение Tekton Chains
Tekton Chains решает эти задачи посредством:
- Автоматической генерации происхождения: Захвата подробных метаданных о процессе сборки
- Криптографической подписи: Обеспечения целостности и подлинности данных происхождения
- Стандартизированных форматов: Поддержки отраслевых стандартов, таких как SLSA provenance
- Гибкого хранения: Предоставления нескольких вариантов хранения и извлечения происхождения
- Интеграции с существующими инструментами: Работы с такими инструментами, как Cosign, Syft, Trivy, Kyverno, Rekor и облачными KMS-сервисами
- Cosign: инструмент для подписи, проверки и управления подписями контейнерных образов
- Syft: инструмент для генерации SBOM для контейнерных образов
- Trivy: инструмент для генерации SBOM и результатов сканирования уязвимостей для контейнерных образов, а также для сканирования уязвимостей
- Kyverno: движок политик для Kubernetes, который можно использовать для применения политик безопасности к контейнерным образам
- Rekor: публичный журнал прозрачности для подписанных артефактов
Внедряя Tekton Chains, организации могут повысить уровень безопасности цепочки поставок и соответствовать требованиям SLSA.
Преимущества
- Автоматизация: Автоматически генерирует и подписывает происхождение без ручного вмешательства
- Стандартизация: Поддерживает отраслевые стандарты, такие как SLSA и in-toto
- Гибкость: Работает с различными механизмами подписи и системами хранения
- Интеграция: Бесшовно интегрируется с экосистемой Tekton Pipelines
- Прозрачность: Обеспечивает ясное понимание того, как были произведены артефакты
- Соответствие требованиям: Помогает выполнять нормативные и отраслевые требования по безопасности цепочки поставок
Сценарии
Сценарий 1: Проверка подписи образа
Команда разработчиков хочет обеспечить целостность своих контейнерных образов, внедрив криптографические подписи. Используя Tekton Chains, они могут автоматически подписывать построенные образы и проверять эти подписи на протяжении всего процесса развертывания. Это помогает предотвратить несанкционированные изменения и гарантирует, что развертываются только доверенные образы.
Сценарий 2: Проверка происхождения системы сборки
Организации необходимо проверить подлинность процесса сборки и убедиться, что он соответствует их требованиям безопасности. Внедряя Tekton Chains, они могут генерировать SLSA Provenance для своих контейнерных образов, предоставляя подробную информацию о том, как был построен каждый образ. Это помогает поддерживать безопасный и аудируемый процесс сборки.
Сценарий 3: Проверка репозитория исходного кода
Команда хочет убедиться, что их контейнерные образы построены из доверенных репозиториев исходного кода. Используя Tekton Chains, они могут автоматически генерировать происхождение, включающее информацию о репозитории исходного кода и деталях коммита. Это помогает им проверить, что образы построены из правильного исходного кода и конкретных коммитов.
Сценарий 4: Сканирование уязвимостей и проверка
Команде безопасности необходимо убедиться, что контейнерные образы не содержат известных уязвимостей перед развертыванием. Внедряя Tekton Chains с инструментами сканирования уязвимостей, они могут автоматически сканировать образы на наличие проблем безопасности и проверять результаты сканирования. Это помогает поддерживать безопасный реестр контейнерных образов и предотвращать развертывание уязвимых образов.
Сценарий 5: Проверка базового образа и SBOM
Организация хочет вести полный учёт компонентов своих контейнерных образов и убедиться, что используются доверенные базовые образы. Используя Tekton Chains с инструментами генерации SBOM, они могут автоматически создавать и проверять спецификации состава программного обеспечения для своих образов. Это помогает отслеживать зависимости и обеспечивать соответствие политикам безопасности.
Сценарий 6: Проверка соответствия лицензиям
Юридическая команда должна убедиться, что все программные компоненты в контейнерных образах соответствуют лицензионным требованиям. Внедряя Tekton Chains с проверкой SBOM, они могут автоматически проверять лицензии всех компонентов в образах. Это помогает поддерживать соответствие лицензионным требованиям и избегать потенциальных юридических проблем.
Сценарий 7: Проверка подписи без ключей
Команда разработчиков хочет внедрить подход подписания с нулевым доверием без управления ключами подписи. Используя Tekton Chains с возможностями подписи без ключей, они могут автоматически подписывать свои артефакты с помощью эфемерных ключей и журналов прозрачности. Это помогает устранить накладные расходы на управление ключами при сохранении высокой безопасности.
Ограничения и недостатки
- Зависимость от Kubernetes: Требуется кластер Kubernetes с установленным Tekton Pipelines
- Сложность конфигурации: Для точного происхождения требуется правильная настройка type hinting
- Управление ключами: Необходимо безопасное управление ключами подписи
- Требования к хранению: Для происхождения и подписей требуется дополнительное хранилище
- Влияние на производительность: Подписание и сохранение происхождения добавляют некоторую нагрузку на процесс сборки
Принципы
Как работает Tekton Chains
Tekton Chains работает через контроллер, который наблюдает за ресурсами TaskRun и PipelineRun в кластере Kubernetes. Рабочий процесс включает следующие шаги:
- Наблюдение: Контроллер отслеживает завершённые TaskRun и PipelineRun
- Снимок состояния: После завершения запуска Chains делает снимок его состояния
- Форматирование: Chains генерирует происхождение в настроенном формате (например, SLSA)
- Подпись: Происхождение криптографически подписывается с использованием настроенного метода
- Хранение: Происхождение и подпись сохраняются в настроенных хранилищах

Генерация происхождения
Tekton Chains использует type hinting для понимания входов и выходов процесса сборки. Эта информация затем используется для генерации происхождения в указанном формате:
- Сбор входных данных: Chains определяет входные артефакты через type hints
- Запись процесса сборки: Фиксируются детали окружения и шагов сборки
- Определение выходных данных: Выходные артефакты идентифицируются через type hints
- Сборка происхождения: Вся информация собирается в стандартизированный формат
Процесс подписи
Tekton Chains поддерживает несколько методов подписи для удовлетворения различных требований безопасности:
- Получение ключа: Ключ подписи извлекается из настроенного источника
- Подготовка полезной нагрузки: Данные происхождения готовятся к подписи
- Генерация подписи: Создаётся криптографическая подпись
- Данные для проверки: Включаются дополнительные данные, необходимые для проверки
Примеры конфигурации
Базовая конфигурация SLSA v1.0
Type Hinting
Более подробную информацию о type hinting можно найти в документации Tekton Chains Type Hinting.
Type Hinting — это специальный механизм в Tekton Chains, который помогает Chains понимать входные и выходные артефакты в PipelineRun/TaskRun через определённые соглашения об именах.
Назначение
- Помогает Chains корректно идентифицировать и записывать входные и выходные артефакты в процессе сборки
- Генерирует точные аттестации SLSA Provenance
- Обеспечивает трассируемость и целостность процесса сборки
Существует несколько способов указать входные и выходные артефакты:
1. Комбинация CHAINS-GIT_URL и CHAINS-GIT_COMMIT
- Специальные type hints для информации о Git-репозитории
- Используются для отслеживания деталей репозитория исходного кода
- Помогают в генерации происхождения для исходного кода
Пример TaskRun
2. *ARTIFACT_INPUTS
Примечание:
*означает любое выражение
- Используется для указания входных артефактов, которые повлияли на процесс сборки
- Помогает отслеживать зависимости и исходные материалы
Пример TaskRun
3. Комбинация *IMAGE_URL и *IMAGE_DIGEST
Пример TaskRun
4. IMAGES
- Можно указать несколько образов, разделённых запятыми или переводами строк
- Каждый образ должен содержать полный дайджест
Пример TaskRun
5. Комбинация *ARTIFACT_URI / *ARTIFACT_DIGEST
- Аналогично IMAGE_URL/IMAGE_DIGEST, но с другой схемой именования
- Используется для указания местоположения артефакта и его дайджеста
6. *ARTIFACT_OUTPUTS
- Использует результаты типа object
- Должны содержать поля uri и digest
Пример TaskRun
Важные параметры
Конфигурация хранения
Хранилища определяют, где сохраняются происхождение и подписи. Это критично для обеспечения доступности происхождения при необходимости проверки.
Сценарии использования
- Tekton Storage: полезно для отладки и внутренней проверки
- OCI Storage: идеально для хранения происхождения вместе с контейнерными образами
- GCS/DocDB Storage: подходит для централизованного хранения и управления
Пример конфигурации
Конфигурация подписи
Конфигурация подписи определяет, как происхождение криптографически подписывается, что важно для проверки его подлинности.
Сценарии использования
- x509: стандартная подпись на основе сертификатов
- KMS: облачное управление ключами для повышения безопасности
- Keyless: подпись с нулевым доверием с использованием эфемерных ключей