Команды, использующие подход DevSecOps, делают безопасность неотъемлемой частью всего жизненного цикла приложений. Гордон Хафф, технологический евангелист компании Red Hat, рассказывает на портале Enterprisers Project о пяти Open Source-проектах, на которые они могут опереться.

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

Ниже рассмотрены пять инструментов с открытым исходным кодом, которые призваны помочь командам, работающим по модели DevSecOps, при которой ИТ-отделы относятся к безопасности как к общей, насквозь интегрированной ответственности, а не как к обязанности, которая выполняется на поздних этапах процесса разработки. Подобные инструменты часто полностью интегрируются во взрослеющие коммерческие платформы Kubernetes. Однако и сами по себе эти проекты предлагают хорошее окно в инновации, происходящие в сфере безопасности, и возможность попробовать их в качестве дополнения к таким платформам.

1. Clair

Сканирование уязвимостей должно рассматриваться как часть автоматизированного рабочего CI/CD-процесса DevSecOps. Оно может происходить в нескольких местах рабочего процесса — и должно продолжаться после развертывания ПО в производство, поскольку обнаруживаются новые угрозы, определенные в базе данных Common Vulnerabilities and Exposures (CVE), и поскольку изменения могут происходить в развернутых образах.

Clair — проект с открытым исходным кодом для статического анализа уязвимостей в контейнерах приложений. Это движок анализа на основе API, который послойно проверяет контейнеры на наличие известных проблем безопасности.

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

2. Sigstore

sigstore представляет собой некоммерческий, общественно полезный сервис для обеспечения подписи ПО.

Правильная защита цепочки поставок ПО подразумевает нечто большее, чем просто точечное сканирование в рамках CI/CD-конвейера DevSecOps. С помощью рабочего партнерства, в которое входят Google, Linux Foundation, Red Hat и Университет Пердью, sigstore объединяет набор инструментов Fulcio, Cosign и Rekor, которыми могут воспользоваться разработчики, мейнтейнеры ПО, менеджеры пакетов и эксперты по безопасности. Сервис обрабатывает цифровую подпись, осуществляет проверку и регистрирует данные для прозрачного аудита, делая более безопасным распространение и использование любого подписанного ПО. Цель состоит в том, чтобы предоставить бесплатный и прозрачный сервис отслеживания цепочки поставок для всех.

Cosign, который выпустил свою версию 1.0 в июле 2021 г., подписывает и проверяет артефакты, хранящиеся в реестрах Open Container Initiative (OCI). Он также включает базовые спецификации для хранения и обнаружения подписей.

Fulcio — это корневой центр сертификации (Root Certificate Authority) для сертификатов Code Signing. Он выдает сертификаты на основе адреса электронной почты Open ID Connect (OIDC). Сертификаты, которые Fulcio выдает клиентам для того, чтобы они могли подписать артефакт, недолговечны. Благодаря этому результате пользователи могут подписывать различные вещи и не беспокоиться о защите приватного ключа (или необходимости отозвать его, если он скомпрометирован).

Rekor обеспечивает неизменяемую, устойчивую к взлому прозрачную учетную книгу и службу штампов времени, а также генерирует метаданные в цепочке поставок ПО. Специалисты по сопровождению ПО и системы сборки могут записывать подписанные метаданные в неизменяемую запись. Затем другие стороны могут запросить эти метаданные, чтобы принять обоснованные решения о доверии и неотказе для жизненного цикла объекта.

3. KubeLinter

KubeLinter основывается на базовой концепции сканирования уязвимостей. Традиционное сканирование уязвимостей можно представить как, по сути, модульное тестирование. Контейнеры, библиотеки и т. д. тестируются изолированно. Как и модульные тесты, это ценная практика сама по себе, но есть дополнительные преимущества при сканировании более сложных интегрированных объектов.

KubeLinter проверяет конфигурации на соответствие различным лучшим практикам с акцентом на готовность к производству и безопасность. KubeLinter выполняет проверки по умолчанию, предназначенные для предоставления полезной информации о YAML-файлах и Helm-диаграммах Kubernetes. Это помогает командам выявлять неправильные конфигурации безопасности и соответствие лучшим практикам DevSecOps. Среди распространенных примеров — запуск контейнеров от имени пользователя, не являющегося root, применение наименьших привилегий и хранение конфиденциальной информации только в секретах.

Таким образом, KubeLinter выходит за рамки сканирования на наличие уязвимостей в контейнере или библиотеке и ищет уязвимости в том, как это ПО настраивается и используется.

4. Open Policy Agent и Gatekeeper

Одна из областей безопасности Kubernetes, которая вызвала большой интерес в последние пару лет, — это управление политиками. Open Policy Agent (OPA) обладает языком политик, Rego, который абстрагирует уровни стека инфраструктуры и API. Суть в том, что OPA упрощает политику безопасности, что очень хорошо, учитывая, что сложность является распространенной причиной уязвимостей.

OPA Gatekeeper — это нативный для Kubernetes способ интеграции OPA в Kubernetes. Для описания и применения политик он использует OPA Constraint Framework, созданный с помощью Kubernetes Custom Resource Definitions (CRD). В версии 3.0 Gatekeeper интегрируется с OPA Constraint Framework для реализации политик Kubernetes на основе CRD и позволяет надежно совместно использовать декларативно настроенные политики. Это позволяет создавать шаблоны для политик Rego, создавать политики в виде CRD и хранить результаты аудита CRD-политик.

Этот проект является результатом сотрудничества Google, Microsoft, Red Hat и Styra. Подпроекты включают Rego Playground для обмена политиками, VS Code для создания политик, а также CLI и REPL — для максимального контроля.

5. Falco

Falco, изначально созданный Sysdig в 2016 г., представляет собой механизм обнаружения угроз для Kubernetes. Falco поставляется с набором правил по умолчанию, которые проверяют ядро на предмет неожиданного поведения. Например, тревожное оповещение может быть вызвано изменением пространства имен, повышением привилегий или неожиданными сетевыми подключениями.

События аудита Kubernetes теперь также включены в список поддерживаемых Falco источников событий. Это означает, что если кластер Kubernetes настроен с включенным журналом аудита, он может отправлять записи проверки в качестве событий в Falco. Вы можете написать гибкие правила Falco для чтения этих событий и обнаружения вредоносной или другой заметной активности для любого типа поведения или деятельности хоста/контейнера. Эти оповещения можно интегрировать в рабочие процессы реагирования на инциденты, чтобы сократить время реагирования и управлять всем через существующие процессы.

В сфере DevSecOps и безопасности Kubernetes существует множество Open Source-вариантов. Здесь было рассмотрено лишь то, что является относительно новым и заслуживающим внимания, но существует множество других сканеров различных типов, ПО для управления секретами различной степени зрелости, а также все классические сетевые и другие технологии безопасности, которые все еще необходимы. Это, безусловно, сложное пространство, но таков же и ландшафт угроз.