Ранее мы составляли мегаобзор проектов песочницы CNCF, которые появились там в 2023 году. Время пролетело незаметно, и мы готовы рассказать о проектах, которые появились в CNCF Sandbox в 2024 году. 

Мы рассмотрим 23 проекта, но расскажем о них в несколько этапов. В этом обзоре пройдёмся по проектам, которые относятся к двум категориям ландшафта CNCF: Provisioning и Observability & Analysis (Работа с ресурсами, Наблюдаемость и аналитика).

В этой статье разберём следующие проекты:

Atlantis
bpfman
Kubean
KusionStack
OSCAL Compass
Perses
Ratify

Atlantis

Atlantis — это проект с открытым исходным кодом для совместной работы с Terraform. Он представляет собой self-hosted сервис, написанный на GoLang. Atlantis позволяет перехватывать с помощью вебхуков запросы к Terraform прямо из пул-реквестов в системе контроля версий и выполнять команды terraform plan и terraform apply. Результаты выполнения возвращаются обратно в пул-реквест в виде комментария.

Это позволяет:

• сделать изменения в Terraform видимыми всем членам команды; 

• представить инженерам не из команд обслуживания инфраструктуры доступ к управлению последней; 

• стандартизировать рабочие процессы управления Terraform.

На рисунке ниже изображена схема привычной работы с Terraform:

Здесь работы производятся с главной веткой репозитория (master или main), Terraform запускается локально, а затем изменения отправляются в репозиторий.

В такой схеме довольно сложно осуществлять ревью изменений, поэтому в неё можно добавить пул-реквесты:

Теперь можно отправить изменения в виде пул-реквеста и предложить коллегам посмотреть, что изменилось. Но всё равно потребуется локально запустить Terraform, так как довольно мелкие изменения в коде…

...могут вести к большим изменениям в плане развёртывания инфраструктуры:

Увидеть эти изменения возможно тоже только после локального запуска команды terraform plan. Если не проводить проверку плана, а сразу смержить изменения в репозиторий, последствия могут быть ощутимыми.

Atlantis призван решить эту проблему, так как позволяет выполнить промежуточные шаги просмотра нового плана Terraform прямо в процессе работы над пул-реквестом:

Для этого достаточно настроить проект, подключить сервис Atlantis и вызвать его комментарием в пул-реквесте:

Atlantis выполнит запуск terraform plan и вернёт результат в виде комментария. Если всё устраивает, можно сразу же выполнить и terraform apply:

Помимо того, что Atlantis облегчает работу, ещё он обеспечивает дополнительный слой безопасности: разработчикам нет необходимости иметь доступ к инфраструктуре напрямую, а всю работу они могут производить, управляя Terraform через настроенный сервис в комментариях пул-реквестов.

Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

bpfman

bpfman — менеджер eBPF для упрощения развёртывания и администрирования программ eBPF. Его особенности:

• Обзор системы — даёт представление о том, как eBPF используется в вашей системе.

• Загрузчик программ eBPF — включает встроенный загрузчик программ, который поддерживает взаимодействие программ XDP и TC, а также развёртывание программ eBPF из образов OCI.

• Управление файловой системой eBPF — управляет файловой системой eBPF, облегчая развёртывание приложений eBPF без необходимости повышения привилегий.

Загрузчик программ и менеджер файловой системы eBPF обеспечивают безопасное развёртывание приложений eBPF. Кроме того, bpfman включает оператор Kubernetes, расширяя эти возможности до кластеров Kubernetes. Это позволяет пользователям уверенно развёртывать eBPF через пользовательские определения ресурсов по узлам в кластере.

bpfman написан на Rust и использует под капотом Rust-библиотеку Aya, предназначенную для работы с eBPF. В состав проекта входят следующие компоненты:

• bpfman — системный демон, поддерживающий загрузку, выгрузку, изменение и мониторинг программ eBPF, предоставляемых через API gRPC.

• eBPF CRDS — набор CRD (XdpProgram, TcProgram и т. д.), которые позволяют выразить намерение загрузить программы eBPF, а также сгенерированный bpfman CRD (BpfProgram), используемый для представления состояния выполнения загруженных программ.

• bpfman-agent — агент запускается в контейнере в наборе демонов bpfman и обеспечивает, чтобы запрошенные программы eBPF для данного узла находились в желаемом состоянии.

• bpfman-operator — оператор, который управляет установкой и жизненным циклом bpfman-agent и CRD в кластере Kubernetes.

Преимущества bpfman:

• Безопасность:

  • Только демон bpfman, который может быть жёстко контролируемым, имеет привилегии, необходимые для загрузки программ eBPF, в то время как доступ к API может контролироваться стандартными методами RBAC. В bpfman только один поток сохраняет эти возможности, в то время как другие потоки (обслуживающие RPC) их не имеют.

  • Предоставляет администраторам контроль над тем, кто может загружать программы.

  • Позволяет администраторам определять правила упорядочивания сетевых программ eBPF.

• Видимость/отладка:

  • Улучшенная видимость того, какие программы eBPF запущены в системе, что повышает отладочные возможности для разработчиков, администраторов и службы поддержки клиентов.

  • Наибольший эффект достигается, когда все приложения используют bpfman. Но даже если это не так, bpfman может обеспечить видимость всех программ eBPF, загруженных на узлы кластера.

• Поддержка нескольких программ:

  • Поддержка сосуществования нескольких программ eBPF от нескольких пользователей.

  • Использует протокол libxdp multiprog для поддержки нескольких программ XDP на одном интерфейсе.

  • Этот же протокол поддерживается и для программ TC, обеспечивая единый многопрограммный пользовательский интерфейс как для TC, так и для XDP.

• Производительность:

  • Упрощает развёртывание и управление жизненным циклом программ eBPF в кластере Kubernetes.

  • Разработчики могут перестать беспокоиться о жизненном цикле программы (загрузка, присоединение, управление выводами и т. д.) и использовать существующие библиотеки eBPF для взаимодействия со своими картами программ с помощью чётко определённых точек выводов, которыми управляет bpfman.

  • Разработчики по-прежнему могут использовать библиотеки Cilium, libbpf, Aya и т. д. для разработки eBPF, а также загружать/выгружать их с помощью bpfman.

  • Предоставляет спецификации образа байт-кода eBPF, которые позволяют осуществлять точечный отдельный контроль версий для программ пользовательского пространства и пространства ядра. Это также позволяет подписывать эти образы контейнеров для проверки права собственности на байт-код.

Также есть возможность использовать ядро утилиты как библиотеку для других утилит и проектов на Rust, вызывая напрямую API bpfman для работы с eBPF-программами. Помимо этого, существует проект bpfman-rpc, который позволяет запустить сервер bpfman и использовать его для трансляции запросов от программ, написанных на других языках. На рисунке ниже представлена схема работы с сервером из приложения на языке Go:

Запустить сервер bpfman возможно и в Kubernetes. При этом все его компоненты будут упакованы в контейнеры, а для взаимодействия с Kubernetes API будет установлен специальный bpfman-agent:

Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензиями Apache 2.0, BSD-2-Clause и GPL-2.0.

Kubean

Kubean — это готовый к использованию инструментарий управления жизненным циклом кластера, основанный на Kubespray и других кластерных LCM-движках.

Основные особенности:

• Простота — развёртывание Kubean и управление жизненным циклом кластера Kubernetes, реализуемое с помощью декларативного API.

• Поддержка офлайна — офлайн-пакеты (os-pkgs, образы, двоичные файлы) выпускаются вместе с релизом, поэтому нет необходимости беспокоиться о том, как собрать все необходимые ресурсы.

• Совместимость — поддержка многоархитектурной доставки. Например, AMD, ARM с распространёнными дистрибутивами Linux. Также доступны Kunpeng с Kylin.

• Расширяемость — возможность добавления пользовательских действий в кластер без каких-либо изменений для Kubespray.

Общая архитектура Kubean показана ниже:

Kubean работает на существующем кластере Kubernetes. Он контролирует жизненный цикл кластера (установка, удаление, обновление, масштабирование вверх и вниз и т. д.) и управляет им с помощью применения стандартных CRD, предоставляемых Kubean, и встроенных ресурсов Kubernetes. Kubean использует Kubespray в качестве базовой технологии. Это упрощает процесс развёртывания кластера и снижает порог использования. На основе возможностей Kubespray в проект добавлено много новых функций, таких как записи операций кластера и записи офлайн-версий.

Kubean запускает несколько контроллеров для отслеживания изменений Kubean CRD и взаимодействует с API-сервером базового кластера для создания собственных ресурсов Kubernetes. Он состоит из четырёх компонентов:

• Cluster Controller — отслеживает «объекты кластера». Он однозначно идентифицирует кластер, имеет информацию о доступе, а также о типе и параметрах развёртывания узла кластера и связан со всеми операциями на кластере (объекты ClusterOperation).

• ClusterOperation Controller — отслеживает объекты ClusterOperation. При их создании контроллер собирает задание для выполнения операций, определённых в объекте CRD.

• Manifest Controller — отслеживает объекты ManifestObjects. Контроллер регистрирует и поддерживает компоненты, пакеты и версии, которые используются или совместимы с текущей версией Kubean.

• LocalArtifactSet Controller — мониторы объектов LocalArtifactSet. Он записывает информацию о компонентах и ​​версиях, поддерживаемых автономным пакетом.

Сравнение Kubean с Kubespray:

• Kubespray использует Ansible в качестве базового уровня для настройки и оркестровки кластеров. Он может работать на bare metal, виртуальных машинах и в большинстве видов облачных сред. Он поддерживает широкий спектр версий Kubernetes и различных плагинов. С Kubespray возможно гибко создавать и настраивать кластеры и поддерживать их на протяжении всего их жизненного цикла.
  Kubean основан на Kubespray и может похвастаться всеми преимуществами последнего. Более того, Kubean представляет концепцию Operator для полной реализации философии Cloud Native. Kubean разработан для работы в качестве контейнера и может быть легко установлен с помощью Helm-чарта.

• Kubespray поддерживает только офлайн на уровне параметров, но не предоставляет возможностей для создания офлайн-пакета установки, что делает его очень проблемным для пользователей, которым нужно использовать его без подключения к всемирной сети.
  Kubean не только обладает продуманным рабочим процессом для создания автономных пакетов, но и упрощает настройку Kubespray, позволяя пользователям управлять жизненным циклом кластера «облачным» способом.

Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

KusionStack

KusionStack — это управляемый Platform Orchestrator, который лежит в основе  Internal Developer Platform (IDP). С помощью Kusion возможно включить разработку, ориентированную на приложения. Это позволит разработчикам писать только одну спецификацию приложения — AppConfiguration. Она определяет рабочую нагрузку и все зависимости ресурсов без необходимости предоставления значений, специфичных для среды. Kusion гарантирует, что предоставляет всё необходимое для запуска приложения.

Kusion помогает разработчикам приложений и инженерам платформ, которые отвечают за поддержку инфраструктуры приложения. Роли могут пересекаться или согласовываться по-разному в пределах организации, но Kusion призван облегчить нагрузку для любого специалиста, отвечающего за любой набор задач.

В Kusion есть два основных рабочих процесса:

1. Настройка модулей и рабочих пространств. Инженеры платформы создают общие модули для развёртывания приложений и их базовой инфраструктуры, а также определения рабочих пространств. Эти стандартизированные общие модули кодифицируют требования заинтересованных сторон по всей организации, включая безопасность, соответствие и финансы.

   Модули Kusion абстрагируют сложность базовых инфраструктурных инструментов, что позволяет разработчикам развёртывать свои приложения по модели самообслуживания.

2. Настройка приложения. Разработчики используют созданные инженерами рабочие пространства и модули, чтобы развёртывать приложения и поддерживать их инфраструктуру. Команда платформы поддерживает рабочие пространства и модули, что позволяет разработчикам сосредоточиться на создании приложений с использованием повторяемого процесса на стандартизированной инфраструктуре.

   

Особенности платформы:

• Platform as Code — позволяет указать желаемое намерение приложения с помощью декларативного кода конфигурации. Также даёт возможность управлять непрерывным развёртыванием с помощью любых систем CI/CD или GitOps для соответствия этому намерению. Никаких специальных скриптов и сложных рабочих процессов — только декларативный код конфигурации.

• Динамическое управление конфигурацией — позволяет командам платформы устанавливать базовые шаблоны, контролировать, как и где развёртывать рабочие нагрузки приложений и предоставлять вспомогательные ресурсы. При этом предоставляет разработчикам приложений свободу посредством спецификации и развёртывания, ориентированных на рабочие нагрузки.

• Встроенная безопасность и соответствие требованиям — обеспечивает безопасность и инфраструктурные передовые практики с помощью готовых базовых моделей, настраивает безопасность и соответствия для любого развёртывания Kusion с помощью сторонних инструментов Policy as Code. Все секреты вспомогательных ресурсов автоматически внедряются в рабочие нагрузки.

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

Сравнение Kusion с другими решениями:

• GitOps (ArgoCD, FluxCD и т. д.). Согласно принципам GitOps, системы обычно имеют желаемое состояние, выраженное декларативно, непрерывно наблюдают за фактическим состоянием системы и пытаются применить желаемое состояние в любых случаях.

  Kusion принимает процесс GitOps и улучшает его с помощью богатства функций. Декларативная модель AppConfiguration может использоваться для выражения желаемого намерения, после объявления намерения Kusion CLI берёт на себя обязательства, чтобы сделать соответственные намерению действия максимально безопасным.

• PaaS (Heroku, Vercel и т. д.). Kusion разделяет ту же цель, что и традиционные платформы PaaS, чтобы обеспечить возможности доставки и управления приложениями. Интуитивное отличие от полнофункциональных платформ PaaS заключается в том, что Kusion — это клиентская цепочка инструментов, а не полноценная платформа PaaS. Кроме того, традиционные платформы PaaS обычно ограничивают тип приложений, которые они могут запускать, но для Kusion таких ограничений нет, что означает, что Kusion обеспечивает бо́льшую гибкость.

  Kusion позволяет иметь подобные платформе функции без ограничений традиционного PaaS. Однако Kusion не пытается заменить какие-либо платформы PaaS, вместо этого его можно использовать для развёртывания на такой платформе, как Heroku.

• Helm. Концепция Helm берёт своё начало в механизме управления пакетами операционной системы. Это инструмент управления пакетами, основанный на шаблонных файлах YAML, который поддерживает выполнение и управление ресурсами в пакете. Kusion не является менеджером пакетов. Он естественным образом предоставляет надмножество возможностей Helm с моделированными парами «ключ — значение». Так что разработчики могут использовать Kusion напрямую как программируемую альтернативу, чтобы избежать мучений с написанием текстовых шаблонов. Для пользователей, которые приняли Helm, результаты компиляции стека в Kusion могут быть упакованы и использованы в формате Helm.

• Kubernetes. Kubernetes — это среда выполнения, планирования и управления контейнерами, ядро ​​«операционной системы» для контейнеров и платформа для создания платформ. Выше уровня API Kubernetes Kusion стремится предоставить абстракцию, ориентированную на приложения, и унифицированное рабочее пространство, лучший пользовательский опыт и автоматизированный рабочий процесс, а также помогает разработчикам легко и совместно создавать модель доставки приложений.

Рабочий процесс Kusion состоит из трёх шагов:

Первый шаг — Write, на котором инженеры платформы создают Kusion Modules и инициализируют Workspace. Разработчики приложений объявляют свои операционные намерения в AppConfiguration под определённым путём Project и Stack.

Вторым шагом является процесс сборки (Generate). Его результат — создание SSoT (Single Source of Truth — единого источника истины), также известного как спецификация текущей операционной задачи. Управлять созданными SSoT можно с помощью любой системы контроля версий, например привычного Git или SVN.

Третий шаг — Apply. Kusion анализирует операционное намерение на основе Spec, созданного на предыдущем шаге. Перед применением Spec Kusion выполнит команду Preview (её также можно выполнить вручную), которая будет использовать трёхсторонний алгоритм сравнения для предварительного просмотра изменений. Это необходимо, чтобы убедиться, что все изменения соответствуют их ожиданиям. Затем Apply актуализирует операционное намерение на различных инфраструктурных платформах: Kubernetes, Terraform и On-Prem. В Storage Backend будет создан файл Release для записи операции.

На схеме ниже изображена более подробная схема работы команд:

Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

OSCAL Compass

Проект OSCAL Compass представляет собой набор инструментов (Trestle, Agile Authoring и C2P), которые позволяют создавать, проверять и управлять артефактами документации для соответствия различным требованиям. Он использует OSCAL (Open Security Controls Assessment Language) от NIST в качестве стандартного формата данных для обмена между инструментами и людьми и обеспечивает обоснованный подход к принятию OSCAL.

OSCAL Compass состоит из нескольких проектов с различными циклами выпуска. В совокупности они обеспечивают сквозную автоматизацию различных процессов.

Разберем, из чего состоит набор инструментов OSCAL Compass.

Trestle — разработан для работы в качестве конвейера CI/CD, работающего поверх артефактов соответствия в Git. Он необходим для обеспечения прозрачности состояния для нескольких заинтересованных сторон в среде, удобной для разработчиков. Trestle передаёт сгенерированные артефакты в инструменты, которые организуют обеспечение соблюдения, измерения и отчётности по соответствию.

Он также предлагает удобные инструменты для управления документами OSCAL. Разделяя большие структуры данных OSCAL на более простые подструктуры, можно легче создавать и поддерживать эти артефакты. Это позволяет следовать обычным процессам в Git, таким как оценка через Pull Request, управление версиями, релизы и теги.

Trestle выполняет три взаимосвязанные функции в области обеспечения соответствия:

• управление документами OSCAL;

• преобразование документов из других форматов в OSCAL;

• поддержка и управление для создания контента, соответствующего требованиям, в форматах markdown и drawio.

Agile Authoring — это совместная платформа для людей, занимающихся вопросами соответствия. Она позволяет организовывать разные аспекты артефактов соответствия через удобный интерфейс. Платформа использует автоматизированный рабочий процесс GitOps на основе Trestle, что обеспечивает согласованность и прослеживаемость артефактов. Agile Authoring предлагает готовую конфигурацию и настройку конвейера CI/CD с использованием GitOps и Trestle для управления документами OSCAL и совместной работы.

Agile Authoring предоставляет набор шаблонов гибкой разработки, каждый из которых предварительно заполнен необходимыми скриптами и конфигурациями.

Compliance to Policy (C2P) — связывает Compliance as Code и Policy as Code. C2P берёт требования Compliance и генерирует технические политики для точек проверки политики (PVP), а также на основании собственных результатов PVP генерирует результаты оценки соответствия. C2P снижает стоимость внедрения обмена между артефактами Compliance и фирменными артефактами PVP. C2P расширяется до различных PVP с помощью плагинов.

• Compliance-to-Policy (C2P) работает в GitOps Pipeline, контроллере Kubernetes или среде Python/Go.

• C2P получает Compliance as Code, например OSCAL Component Definition, которое представляет сопоставление между элементами управления и политиками (имена/идентификаторы политик).

• C2P генерирует политики через плагин для каждого механизма политик:

  • плагин отвечает за реализацию функции, которая принимает имена/идентификаторы политик и возвращает политики.

• Политики доставляются в механизмы политик с помощью синхронизации GitOps, задачи CI/CD, контроллера Kubernetes или программы автоматизации развёртывания.

• Результаты собираются из механизмов политик с помощью запланированной задачи или контроллера Kubernetes.

• C2P объединяет результаты механизмов политики по элементам управления через плагин для каждого механизма политики:

  • плагин отвечает за реализацию функции, которая принимает результаты работы механизма политик и возвращает вердикты (пройдено / не пройдено / ошибка), причину и/или имя ресурса для каждой соответствующей политики по её именам/идентификаторам.

• C2P выдаёт результаты оценки соответствия, например результаты оценки OSCAL, которые представляют результаты оценки каждого элемента управления.

Поддерживаются следующие механизмы политик:

• Kyverno — движок политик, разработанный для Kubernetes, где политики управляются как его ресурсы. Политики Kyverno могут проверять, изменять, генерировать и очищать ресурсы Kubernetes.

• Open Cluster Management Policy Framework (OCM) — многокластерная платформа управления, которая обеспечивает управление политиками Kubernetes. Её структура политик позволяет проводить валидацию и принудительное применение политик в нескольких кластерах.

• Auditree — автоматизация рабочего процесса на базе GitOps, которая позволяет собирать и проверять доказательства, создавая долгосрочное хранилище доказательств в «шкафу доказательств» на базе Git. Доказательства собираются с помощью скриптов кода, называемых «извлекатели», и проверяются с помощью «проверок».

Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

Perses

Perses — дашборд для визуализации данных о наблюдаемости из Prometheus/Thanos/Jaeger.

Perses стремится достичь нескольких целей:

• Стать стандартным инструментом визуализации дашбордов для Prometheus и других источников данных. Он сосредоточен на совместимости с GitOps и таким образом обеспечивает плавный рабочий процесс Dashboard as Code с помощью новой модели определения панели мониторинга.

• Предоставить различные пакеты npm, чтобы любой, кто хотел бы встроить диаграммы и панели мониторинга в свой пользовательский интерфейс, мог им воспользоваться.

• Предоставить режим Kubernetes-native, в котором определения дашбордов могут быть развёрнуты и прочитаны из отдельных пространств имён приложений (используя CRD).

• Быть дружелюбным к пользователям Dashboard as Code, предоставляя полную статическую проверку формата дашборда. Он даёт возможность проверять свои панели в CI/CD с помощью Perses CLI (названного percli).

• Поддерживать плагины, позволяющие пользователям расширять изначально предоставляемые возможности.

Для управления Perses разработчики предоставляют консольную утилиту percli. С её помощью можно управлять системой: применять шаблоны, удалять ресурсы, смотреть конфигурации и так далее. Список основных команд, доступных в утилите:

$ percli --help

Command line interface to interact with the Perses API

Usage:
  percli [command]

Available Commands:
  apply       Create or update resources through a file. JSON or YAML format supported
  completion  Generate the autocompletion script for the specified shell
  config      display local or remote config
  dac         Commands related to Dashboard as Code
  delete      Delete resources
  describe    Show details of a specific resource
  get         Retrieve any kind of resource from the API.
  help        Help about any command
  lint        Static check of the resources
  login       Log in to the Perses API
  migrate     migrate a Grafana dashboard to the Perses format
  project     Select the project used by default.
  refresh     refresh the access token when it expires
  version     Display client version.
  whoami      Display current user used

Flags:
  -h, --help                  help for percli
      --log.level string      Set the log verbosity level. Possible values: panic, fatal, error, warning, info, debug, trace (default "info")
      --percliconfig string   Path to the percliconfig file to use for CLI requests. (default "/Users/ahusson/.perses/config.json")

Use "percli [command] --help" for more information about a command.

Для доступа нужно указать утилите либо имя пользователя и пароль, либо специальный токен.

Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

Ratify

Ratify — фреймворк проверки для Kubernetes. Он позволяет проверять метаданные безопасности артефактов и допускать к развёртыванию только те из них, которые соответствуют созданным политикам.

Особенности проекта:

• Комплексная проверка — Ratify предлагает комплексную структуру проверки, которая позволяет гарантировать, что все эталонные артефакты удовлетворяют стандартам безопасности и соответствия. Он позволяет проверять подписи, контрольные суммы и гарантировать, что артефакты являются актуальными и свободными от известных уязвимостей.

• Гибкая конфигурация — Ratify предлагает гибкую систему конфигурации, которая позволяет настраивать политики проверки в соответствии с конкретными потребностями. Он даёт возможность легко определить собственные политики для проверки подписей, артефактов и т. д., и Ratify автоматически применит эти политики в кластере Kubernetes.

• Простая интеграция — Ratify разработан для бесшовной интеграции с существующей средой Kubernetes. Всего за несколько простых шагов можно установить Ratify в кластер и начать проверку эталонных артефактов. Кроме того, Ratify предлагает набор интерфейсов, которые могут использоваться различными системами. Это упрощает интеграцию Ratify в существующую цепочку инструментов.

Конфигурировать Ratify можно как через конфигурационный файл, так и с помощью CRD в кластере Kubernetes.

В качестве главного элемента систем выступает Executor — «клей», соединяющий воедино все основанные на плагинах элементы проекта.

Основные понятия, используемые в проекте:

• Subject — проверяемый артефакт, идентифицируется ссылкой в ​​соответствии с OCI {DNS/IP}/{Repository}:[name|digest].

• Reference Type — тип артефакта OCI в реестре, ссылающийся на существующий неизменяемый контент.

• Referrer — эталонный артефакт, идентифицированный ссылкой в ​​соответствии с OCI {DNS/IP}/{Repository}:[name|digest] и ссылающийся на Subject.

• Plugin — плагины, которые обеспечивают определённую функциональность фреймворка.

• Store — хранилище артефактов, которое может хранить и распространять артефакты OCI с возможностью обнаружения типов ссылок для Subject.

• Verifier — отвечает за проверку определённого типа(ов) артефакта.

• Configuration — набор параметров для настройки фреймворка.

• Policy — набор правил для принятия различных решений в процессе проверки артефактов.

Артефакт определяется манифестом и идентифицируется ссылкой в ​​соответствии с OCI {DNS/IP}/{Repository}:[name|digest]. Артефакт связан с другим артефактом через дескриптор и позволяет формировать цепочку артефактов, как показано ниже:

Пример потока данных для проверки артефакта:

Фреймворк можно настроить с помощью набора параметров, которые используются как фреймворком, так и плагинами. При выполнении определённого плагина его соответствующие параметры будут переданы в качестве конфигурации выполнения. Параметры выполнения передаются в плагины через переменные среды ОС.

Verifier в фреймворке — компонент, который отвечает за проверку определённого типа(ов) артефакта с использованием предоставленной конфигурации. Он предлагает следующие возможности:

• учитывая артефакт ссылочного типа, определяет, поддерживает ли верификатор его проверку;

• проверяет эталонный артефакт и возвращает результат проверки.

С помощью Ratify можно настроить подписание образов контейнеров, которое гарантирует их подлинность и целостность. Развёртывая только подписанные образы, можно быть уверенным, что образы получены из надёжного источника и не были изменены с момента их создания.

Например, вот так выглядит схема включения Ratify в CI/CD с развёртыванием в кластер в Azure:

Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.

Заключение

Мы кратко рассмотрели новые проекты из ландшафта CNCF в категориях Provisioning и Observability & Analysis, добавленные в песочницу фонда за последний год. Надеемся, что они успешно пройдут стадию принятия в CNCF и станут его полноценными членами.

P. S.

Читайте также в нашем блоге:

• 25 новых проектов в песочнице CNCF: мегаобзор