• Русский
  • Понимание 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Важные параметрыКонфигурация храненияСценарии использованияПример конфигурацииКонфигурация подписиСценарии использованияПример конфигурацииСсылки

    Терминология

    ТерминОписание
    SLSASupply-chain Levels for Software Artifacts — рамочная система безопасности целостности цепочки ПО
    SignatureКриптографическое доказательство, подтверждающее подлинность и целостность данных происхождения
    AttestationАутентифицированные метаданные о программных артефактах в формате in-toto attestation
    VerificationПроцесс проверки подлинности и целостности данных аттестации
    Type HintingСпециально именованные результаты/параметры, которые помогают Tekton Chains понимать входы и выходы
    Storage BackendСистема, в которой Tekton Chains хранит происхождение и подписи

    Аттестация имеет несколько типов предикатов.

    Тип предикатаОписание
    SLSA ProvenanceМетаданные, описывающие, как был произведён артефакт, включая процесс сборки, входные данные и окружение
    SBOMДокумент, перечисляющий все компоненты программного продукта и их взаимосвязи
    Vulnerability Scan ResultsОтчёт, содержащий список всех обнаруженных уязвимостей в программном продукте
    Custom MetadataПользовательские метаданные о программном продукте

    Зачем нужен Tekton Chains

    Проблема безопасности цепочки поставок программного обеспечения

    В традиционных конвейерах разработки и доставки программного обеспечения обеспечение целостности и безопасности артефактов на протяжении всей цепочки поставок представляет значительные трудности:

    • Отсутствие трассируемости: Без надлежащей информации о происхождении сложно проверить, откуда пришли артефакты и как они были построены
    • Риски подделки: Артефакты могут быть изменены на различных этапах без обнаружения
    • Сложности проверки: Потребители артефактов не имеют надёжного способа проверить их подлинность
    • Проблемы с соответствием требованиям: Организациям сложно соответствовать растущим нормативным требованиям по безопасности цепочки поставок ПО

    Эти проблемы привели к громким атакам на цепочки поставок, таким как SolarWinds, когда вредоносный код был внедрён в процесс сборки, затронув тысячи организаций.

    Решение Tekton Chains

    Tekton Chains решает эти задачи посредством:

    1. Автоматической генерации происхождения: Захвата подробных метаданных о процессе сборки
    2. Криптографической подписи: Обеспечения целостности и подлинности данных происхождения
    3. Стандартизированных форматов: Поддержки отраслевых стандартов, таких как SLSA provenance
    4. Гибкого хранения: Предоставления нескольких вариантов хранения и извлечения происхождения
    5. Интеграции с существующими инструментами: Работы с такими инструментами, как 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. Рабочий процесс включает следующие шаги:

    1. Наблюдение: Контроллер отслеживает завершённые TaskRun и PipelineRun
    2. Снимок состояния: После завершения запуска Chains делает снимок его состояния
    3. Форматирование: Chains генерирует происхождение в настроенном формате (например, SLSA)
    4. Подпись: Происхождение криптографически подписывается с использованием настроенного метода
    5. Хранение: Происхождение и подпись сохраняются в настроенных хранилищах

    Tekton Chains Workflow

    Генерация происхождения

    Tekton Chains использует type hinting для понимания входов и выходов процесса сборки. Эта информация затем используется для генерации происхождения в указанном формате:

    1. Сбор входных данных: Chains определяет входные артефакты через type hints
    2. Запись процесса сборки: Фиксируются детали окружения и шагов сборки
    3. Определение выходных данных: Выходные артефакты идентифицируются через type hints
    4. Сборка происхождения: Вся информация собирается в стандартизированный формат

    Процесс подписи

    Tekton Chains поддерживает несколько методов подписи для удовлетворения различных требований безопасности:

    1. Получение ключа: Ключ подписи извлекается из настроенного источника
    2. Подготовка полезной нагрузки: Данные происхождения готовятся к подписи
    3. Генерация подписи: Создаётся криптографическая подпись
    4. Данные для проверки: Включаются дополнительные данные, необходимые для проверки

    Примеры конфигурации

    Базовая конфигурация SLSA v1.0

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: chains-config
      namespace: tekton-chains
    data:
      artifacts.taskrun.format: "slsa/v1"
      artifacts.taskrun.storage: "oci"
      artifacts.taskrun.signer: "x509"
      artifacts.pipelinerun.format: "slsa/v1"
      artifacts.pipelinerun.storage: "oci"
      artifacts.pipelinerun.signer: "x509"
      artifacts.oci.format: "simplesigning"
      artifacts.oci.storage: "oci"
      artifacts.oci.signer: "x509"

    Type Hinting

    TIP

    Более подробную информацию о 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-репозитории
    • Используются для отслеживания деталей репозитория исходного кода
    • Помогают в генерации происхождения для исходного кода
    results:
      - name: CHAINS-GIT_URL
        type: string
      - name: CHAINS-GIT_COMMIT
        type: string
    Пример TaskRun
    apiVersion: tekton.dev/v1
    kind: TaskRun
    metadata:
      name: git-clone
    spec:
      taskSpec:
        params:
          - name: url
            description: URL репозитория для клонирования.
            type: string
            default: "https://github.com/tektoncd/pipeline"
          - name: revision
            description: Ревизия для checkout (ветка, тег, sha, ref и т.д.)
            type: string
            default: "main"
        results:
          - name: CHAINS-GIT_URL
            type: string
            description: Точный URL, который был получен этой задачей.
          - name: CHAINS-GIT_COMMIT
            type: string
            description: Точный SHA коммита, который был получен этой задачей.
        steps:
          - name: dummy-clone
            image: bash:latest
            script: |
              #!/usr/bin/env bash
              echo -n "https://github.com/tektoncd/pipeline" | tee $(results.CHAINS-GIT_URL.path)
              echo -n "7f2f46e1b97df36b2b82d1b1d87c81b8b3d21601" | tee $(results.CHAINS-GIT_COMMIT.path)

    2. *ARTIFACT_INPUTS

    Примечание:

    • * означает любое выражение
    • Используется для указания входных артефактов, которые повлияли на процесс сборки
    • Помогает отслеживать зависимости и исходные материалы
    results:
      - name: first-ARTIFACT_INPUTS
        type: object
        properties:
          uri: {}
          digest: {}
    Пример TaskRun
    apiVersion: tekton.dev/v1
    kind: TaskRun
    metadata:
      name: git-clone
    spec:
      taskSpec:
        params:
          - name: url
            description: URL репозитория для клонирования.
            type: string
            default: "https://github.com/tektoncd/pipeline"
          - name: revision
            description: Ревизия для checkout (ветка, тег, sha, ref и т.д.)
            type: string
            default: "main"
        results:
          - name: source_repo_ARTIFACT_INPUTS
            description: Артефакт репозитория исходного кода
            type: object
            properties:
              uri: {}
              digest: {}
        steps:
          - name: dummy-clone
            image: bash:latest
            script: |
              #!/usr/bin/env bash
              echo -n "{\"uri\":\"https://github.com/tektoncd/pipeline\", \"digest\":\"sha1:7f2f46e1b97df36b2b82d1b1d87c81b8b3d21601\"}" > $(results.source_repo_ARTIFACT_INPUTS.path)

    3. Комбинация *IMAGE_URL и *IMAGE_DIGEST

    results:
      - name: first-image-IMAGE_URL
        type: string
      - name: first-image-IMAGE_DIGEST
        type: string
    Пример TaskRun
    apiVersion: tekton.dev/v1
    kind: TaskRun
    metadata:
      name: image-build
    spec:
      taskSpec:
        results:
          - name: first-image-IMAGE_URL
            type: string
            description: Точный URL построенного OCI образа.
          - name: first-image-IMAGE_DIGEST
            type: string
            description: Алгоритм и дайджест построенного OCI образа.
        steps:
          - name: dummy-build
            image: bash:latest
            script: |
              #!/usr/bin/env bash
              echo -n "gcr.io/foo/bar" | tee $(results.first-image-IMAGE_URL.path)
              echo -n "sha256:586789aa031fafc7d78a5393cdc772e0b55107ea54bb8bcf3f2cdac6c6da51ee" | tee $(results.first-image-IMAGE_DIGEST.path)

    4. IMAGES

    • Можно указать несколько образов, разделённых запятыми или переводами строк
    • Каждый образ должен содержать полный дайджест
    results:
      - name: IMAGES
        type: string
    Пример TaskRun
    apiVersion: tekton.dev/v1
    kind: TaskRun
    metadata:
      name: image-build
    spec:
      taskSpec:
        results:
          - name: IMAGES
            description: Несколько артефактов образов
            type: string
        steps:
          - name: dummy-build
            image: bash:latest
            script: |
              #!/usr/bin/env bash
              echo -n "img1@sha256:digest1, img2@sha256:digest2" | tee $(results.IMAGES.path)

    5. Комбинация *ARTIFACT_URI / *ARTIFACT_DIGEST

    • Аналогично IMAGE_URL/IMAGE_DIGEST, но с другой схемой именования
    • Используется для указания местоположения артефакта и его дайджеста
    results:
      - name: first-ARTIFACT_URI
        type: string
      - name: first-ARTIFACT_DIGEST
        type: string

    6. *ARTIFACT_OUTPUTS

    • Использует результаты типа object
    • Должны содержать поля uri и digest
    results:
      - name: first-ARTIFACT_OUTPUTS
        type: object
        properties:
          uri: {}
          digest: {}
    Пример TaskRun
    apiVersion: tekton.dev/v1
    kind: TaskRun
    metadata:
      name: image-build
    spec:
      taskSpec:
        results:
          - name: first-ARTIFACT_OUTPUTS
            description: Первый построенный артефакт
            type: object
            properties:
              uri: {}
              digest: {}
        steps:
          - name: dummy-build
            image: bash:latest
            script: |
              #!/usr/bin/env bash
              echo -n "{\"uri\":\"gcr.io/foo/bar\", \"digest\":\"sha256:586789aa031fafc7d78a5393cdc772e0b55107ea54bb8bcf3f2cdac6c6da51ee\"}" > $(results.first-ARTIFACT_OUTPUTS.path)

    Важные параметры

    Конфигурация хранения

    Хранилища определяют, где сохраняются происхождение и подписи. Это критично для обеспечения доступности происхождения при необходимости проверки.

    Сценарии использования

    • Tekton Storage: полезно для отладки и внутренней проверки
    • OCI Storage: идеально для хранения происхождения вместе с контейнерными образами
    • GCS/DocDB Storage: подходит для централизованного хранения и управления

    Пример конфигурации

    artifacts.taskrun.storage: "tekton,oci"
    artifacts.pipelinerun.storage: "tekton"
    artifacts.oci.storage: "oci"

    Конфигурация подписи

    Конфигурация подписи определяет, как происхождение криптографически подписывается, что важно для проверки его подлинности.

    Сценарии использования

    • x509: стандартная подпись на основе сертификатов
    • KMS: облачное управление ключами для повышения безопасности
    • Keyless: подпись с нулевым доверием с использованием эфемерных ключей

    Пример конфигурации

    artifacts.taskrun.signer: "x509"
    artifacts.pipelinerun.signer: "x509"
    artifacts.oci.signer: "x509"

    Ссылки