#Понимание Tekton Chains

Tekton Chains — это мощный компонент безопасности в экосистеме Tekton, который помогает защитить вашу цепочку поставок программного обеспечения, создавая, подписывая и сохраняя происхождение (provenance) артефактов, построенных с помощью Tekton Pipelines. В этом документе даётся подробное объяснение работы Tekton Chains и его ключевых компонентов.

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

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

#Зачем нужен 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 использует 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

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

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: {}

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

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

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: {}

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"

#Ссылки

• Документация Tekton Chains
• Фреймворк SLSA
• In-toto Attestation
• Проект Sigstore
• SBOM
• Отчёты сканирования уязвимостей Cosign