Технологии
«Каковы ключевые тренды безопасности контейнеризации?», «Какие технологии защиты зрелые, а какие только начинают развиваться?», «Чем защищать свои критически важные ресурсы и системы в промышленной среде?», «Может, проще отказаться от контейнеризации?» — это вопросы, которые задают руководители отделов безопасности при выборе средств защиты контейнеров.
И если ответ на последний вопрос можно получить только при формировании стратегии трансформации инфраструктуры под использование гибридного облака (и контейнеризации как его части), то с остальными вопросами поможет разобраться уже довольно зрелое сообщество Cloud Native Compute Foundary (CNCF). Так, первый коммит в репозиторий специализированной группы TAG Security был сделан еще 18 марта 2018 г.
CNCF выпускает разнообразные рекомендации, например CNCF Technology Radar DevSecOps (последний — за 2021 г., см. рис. 1):
В таких репортах CNCF отражает уровень зрелости продуктов и технологий безопасной разработки на основе опроса более 140 компаний по всему миру.
Кроме того, в индустрии регулярно проходят мероприятия, посвященные безопасности контейнеризации и связанных с ней технологий, а наиболее развивающиеся подходы оформляются в выделенные проекты и сообщества. О некоторых инструментах мы поговорим ниже.
eBPF — стандарт де-факто в наблюдаемости (observability) и мониторинге контейнеров
Одно из наиболее развивающихся сообществ на текущий момент занимается разработкой и развитием технологии eBFP (enhanced Berkley Packet Filter). Она позволяет запускать в ядре Linux программный код в изолированной виртуальной машине. Используется для расширения возможностей ядра без необходимости изменения его исходного кода или загрузки модулей. Разработчики приложений могут использовать программы eBPF для включения дополнительных возможностей в ОС во время выполнения. При этом операционная система гарантирует безопасность и эффективность их работы, как если бы она была изначально скомпилирована с помощью JIT-компилятора и механизма проверки.
Ядро Linux — event-driven-система. Практически все, что происходит в ядре, да и в системе в целом можно представить в виде набора событий: прерывание, получение пакета по сети, передача процессора другому процессу, запуск функции. eBPF дает возможность писать небольшие программы, которые будут запущены ядром в ответ на события. Эти программы могут как пролить свет на происходящее в системе, так и управлять ею.
Программа eBPF включает код, загружаемый в пользовательскую часть и в защищенную часть ядра ОС (см. рис. 2).
Сейчас появляется большое число стартапов и открытых проектов, использующих eBPF. Технология применяется для мониторинга, управления сетевыми взаимодействиями, обеспечения анализа аномалий как в контейнерах, так и на Linux-узлах.
В приведенном на рис. 1 радаре технологий, то есть на 2021 г., только один проект — Cilium — находился в стадии Assess. Такой статус означает апробацию решения в компаниях. Однако на момент написания статьи, то есть через два года после появления радара, количество решений на карте технологий CNCF Landscape уже перевалило за 30. Наиболее развитые из них, такие как Calico, Cilium и Tetragon, выпустили релизные версии, готовые к промышленной эксплуатации.
Почему eBPF уже стандарт де-факто в мониторинге и наблюдаемости (observability) для контейнеров:
- Зрелость технологии
Свое начало eBPF берет от разработки Berkley Packet Filter, выпущенной еще в 1992 г. Стивеном МакКейном и Ваном Якобсеном. BPF разрабатывалась для создания программ по анализу сетевого трафика, основной идеей было предоставление доступа к сетевым интерфейсам ОС.
С использованием этой технологии реализованы такие инструменты, как tcpdump и seccomp. eBPF расширяет возможности BPF по фильтрации событий в пространстве ядра.
- Экосистема
В рамках проекта разрабатываются:
— набор библиотек для популярных языков разработки (Python, Go, Rust, C++);
— несколько компиляторов (gcc, llvm compiller);
— инструменты тестирования (BPF Conformance, PREVAIL).
За это eBFP любят стартапы и разработчики.
- Кроссплатформенность
Можно использовать eBPF не только внутри ядра Linux, но и в других event-driven-системах. Например, инструментарий eBPF for Windows позволяет реализовать мониторинг вызовов в ядре этой ОС и является альтернативой Sysinternals и Kernel-Mode Security.
Containers are the new normal, and WebAssembly is the future
Так аналитики описали заинтересованность сообщества в технологии WebAssembly в исследовании CNCF Annual Survey 2022.
Определение технологии:
«WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications».
Таким образом, Wasm не является ни языком программирования, ни конкретной виртуальной машиной (реализацией), но описывает набор спецификаций и методов, позволяющих компилировать портируемый байт-код. В 2019 г. была утверждена Core-спецификация Wasm 1.0, а уже в 2022-м — 2.0. Изначально технология была предназначена для компиляции кода на C++ и Rust для запуска в браузере, однако сообщество уже разработало проекты, которые позволяют запускать код WebAssembly не только вне браузера, но даже на IoT-устройствах (WASMEdge).
Ключевые маркеры перспективности WebAssembly похожи на таковые у eBPF:
- Зрелость технологии
Как мы уже сказали, Core-спецификация WebAssembly версии 2.0 была утверждена в 2022 г., технология уже пережила первый пик хайпа и стадию разочарования. Сейчас большинство пользователей адаптируют Wasm под себя.
На текущий момент спецификация интерфейсов взаимодействия виртуальной машины WebAssembly с функциями ОС (WASI) находится в pre-release и не может быть использована для высоконагруженных продуктивных систем. Однако это не относится к реализации плагинов и переиспользованию кода библиотек.
- Экосистема
WebAssembly полностью соответствует требованиям проектов под эгидой CNCF:
— более 30 проектов виртуальных машин;
— в код Wasm компилируются наиболее востребованные языки (Go, Rust, Python, C++, JavaScript, C#, Kotlin);
— под Wasm специально создаются языки;
— есть инструменты отладки кода (Wabt, WAI);
— для Wasm создана отдельная карта проектов (Landscape CNCF), активно разрабатываются около 10 проектов по интеграции Wasm-программ с контейнерами (Kwasm, KubeEdge).
Не исключение — проекты в сфере ИБ. Например, в стадии релиза находится Admission Controller для k8s — Kubewarden, который в качестве правил использует модули Wasm. А проект Open Policy Engine в последних релизах реализовал возможность компиляции rego-политик в Wasm-модули.
PT Container Security
Как технологическая компания, мы не могли остаться в стороне от темы защиты контейнеров и разработали продукт PT Container Security. Он обеспечивает автоматизацию управления уязвимостями и недостатками в конфигурации образов и контейнеров на этапе их сборки, развертывания и промышленной эксплуатации, а также позволяет реагировать на инциденты ИБ в рантайме контейнеров.
Как уже можно догадаться, «под капотом» у продукта eBPF и Wasm. И это может вызвать вопросы. Да что уж там, мы задавали их сами себе на этапе выбора инструментов.
Даёт ли использование передовых технологий преимущество, или мы стреляем себе в ногу?
Ни одна компания не застрахована от ошибок, и выбор технологического стека в том числе влияет на ограничения продукта. Даже самые крупные компании признают ошибки и делают развороты на 180º. Взять ту же Microsoft и ее разворот в сторону Linux и проектов с открытым исходным кодом; AppleScript был вполне себе языком автоматизации для инфраструктуры «яблочных» устройств; все эксперименты в Google даже сложно перечислить.
Однако четкая постановка целей и определение стратегии позволяют минимизировать потери и дать командам возможность экспериментировать и выбирать действительно стоящие технологии. С недавнего времени мы в Positive Technologies выбрали стратегию активного участия в open source. В компании была создана специальная группа: наши разработчики участвуют в открытых проектах и создают собственные.
Команда PT Container Security не осталась в стороне. Мы никогда не скрывали, что используем проекты с открытым кодом для реализации функций нашего продукта, например, библиотеку _syft_ для сбора software bill of material (SBOM) в образах контейнеров, проект Cilium Tetragon для реализации основного сенсора событий рантайма контейнеров.
Но мы не просто используем их «задарма», а участвуем в их развитии. В послужном списке команды PT Container Security уже есть принятые Pull Request в Cilium Tetragon, так что мы можем считать себя причастными к релизу 1.0 этого проекта (см. рис. 3).
Что делать с недостатками?
История знает случаи, когда действительно передовые технологии не находили своего применения после первой волны успеха. Перед тем как перейти к рассказу о том, как мы используем eBPF и Wasm в PT Container Security, скажем о паре подводных камней, с которыми столкнулись.
- Глубокие знания ядра Linux. Даже с наличием абстракций от Cilium Tetragon необходимо обладать знаниями работы ядра ОС. При создании политик на базе системных вызовов (syscall) и Kernel Probes необходимо досконально знать, как компоненты приложения взаимодействуют с ОС на уровне ядра. Ситуацию несколько упрощает наличие документации (мы про kernel.org), однако даже такие политики могут обойти злоумышленники, воспользовавшись доступом к конкретным вызовам функций ядра.
- Ограничения библиотек и функций языков программирования при компиляции в байт-код WebAssembly. Существует много реализаций Wasm, которые позволяют компилировать ваш код в модули, и у каждой из них есть ограничения на компоненты используемого языка программирования. Например, реализация через компиляцию с использованием компилятора tinygo и машины wazero не позволяет применять стандартную библиотеку для обработки JSON-файлов encoding/json языка Golang. Наши разработчики хотят максимально упростить задачу для будущих пользователей, реализуя методы взаимодействия с событиями рантайма и Admission Controller.
Как это работает
- Архитектура PT Container Security
У нас проработаны три ключевых сценария применения eBPF и Wasm:
— использование сенсоров eBPF для сбора и анализа событий внутри контейнеров;
— использование модулей Wasm для реализации логики обработки событий и детектирования угроз:
— при обработке запросов к Kubernetes API через Admission Controller;
— при обработке в реальном времени событий, полученных от сенсоров eBPF.
Схема архитектуры продукта приведена на рис. 4.
- Сбор событий рантайма контейнеров
Для обеспечения сбора событий от сенсоров eBPF реализован компонент Runtime Monitor. Он через открытый API управляет настройками сенсора и фильтрами событий. Это позволяет в режиме реального времени изменять поток событий, который поступает в систему для анализа:
— для сглаживания возможных всплесков при тестировании новых политик мониторинга eBPF;
— для расширения потока событий от сенсоров, например когда необходимо протестировать новую гипотезу об атаках;
— для проверки работоспособности детекторов на конкретном наборе событий.
Runtime Monitor перемещает события от сенсоров на дальнейшую обработку детекторами.
- Что есть «из коробки»
Сейчас доступны следующие политики eBPF (TracingPolicy):
— мониторинг сетевой активности;
— мониторинг запуска процессов;
— мониторинг файловой активности в чувствительных директориях (/etc, /var, /tmp, /opt);
— мониторинг операций повышения привилегий.
Рассмотрим пример события отправки сообщения по сети. Событие содержит информацию о самом соединении (адреса, порты, протокол), данные о родительском процессе (идентификатор, исполняемый файл, аргументы, capabilities ядра) и о контейнере, в котором оно произошло. Такой подробный формат позволяет аналитику безопасности при разборе событий делать более конкретные предположения о происходящей в контейнерах активности. Затем идет перенос этих предположений в логику детекторов, например:
```json
{
"nodeName": "gdb-four",
"processKprobe": {
"action": "KPROBE_ACTION_POST",
"args": [
{
"sockArg": {
"cookie": "18446617656548991744",
"daddr": "10.36.0.25",
"dport": 5432,
"family": "AF_INET",
"protocol": "IPPROTO_TCP",
"saddr": "10.36.0.22",
"sport": 60286,
"state": "TCP_ESTABLISHED",
"type": "1536"
}
},
...
"policyName": "connect",
"process": {
"arguments": "news.py run",
"auid": 4294967295,
"binary": "/usr/local/bin/python3.11",
"cap": {
"effective": [
"CAP_CHOWN",
...
"CAP_SETFCAP"
],
"permitted": [
"CAP_CHOWN",
...
"CAP_SETFCAP"
]
},
"cwd": "/",
"docker": "db0efcd74edf09026ffb067ffac75dc",
"execId": "Z2RiLWZvdXI6MTMxNzM5MDAwMDAwMDo1NTQ3NQ==",
"flags": "procFS auid rootcwd",
"ns": {
...
},
"parentExecId": "Z2RiLWZvdXI6MTIwMTY4MDAwMDAwMDo0NzE4NA==",
"pid": 55475,
"pod": {
"container": {
"id": "containerd://db0efcd74edf09026ffb067ffac75dc3c09ae1e5aad866951c4bfb7afbe0fa3d",
"image": {
"id": "10.156.16.103:5000/news@sha256:c19688e37daab03e26931e8ff80279898ecf2a4c8c44eaf24188693512d7b66d",
"name": "10.156.16.103:5000/news:50"
},
"name": "news",
"pid": 1,
"startTime": "2023-11-24T18:54:51Z"
},
"name": "news-service-deployment-8c48748d-6nfnn",
"namespace": "default",
"podLabels": {
"app": "news-service",
"pod-template-hash": "8c48748d"
},
"workload": "news-service-deployment",
"workloadKind": "Deployment"
},
"processCredentials": {
...
},
"refcnt": 2,
"startTime": "2023-11-24T18:54:50.953556018Z",
"tid": 57217,
"uid": 0
}
},
"time": "2023-11-28T08:33:38.373964437Z"
}
```
- Детекторы вредоносной активности
Мы не могли бы называть свой продукт Container Security, если бы он не выявлял атаки на контейнерную инфраструктуру и вредоносную активность в ней.
Для этого используются модули Wasm, каждый из которых реализует логику конкретного детектора. Модули могут быть загружены в систему как при запуске специализированного сервиса (Event Processor), так и динамически с использованием API PT Container Security.
- Детекторы событий рантайма
Этот тип детекторов позволяет выявлять вредоносную активность по результатам анализа событий от сенсоров eBPF. В детекторе реализуется логика обработки полей событий. Рассмотрим простой детектор, написанный на языке программирования Golang:
```go
package main
import (
"context"
"strings"
"../detector/api"
"../detector/api/tetragon"
)
const (
ID = "DEMO_DETECTOR"
Name = "hello world detector"
Description = "Detect hello world in events"
Version = 1
)
var bins = []string{"hello", "world", "helloworld"}
func main() {
api.RegisterDetector(Detector{})
}
type Detector struct{}
func (d Detector) Detect(ctx context.Context, req.DetectReq) (*api.DetectResp, error){
// Основная функция, где выполняется проверка
resp := &api.DetectResp{
Id: ID,
Name: Name,
Description: Description,
Version: Version,
Severity: api.DetectResp_CRITICAL,
}
event := req.GetEvent().GetEvent()
ev := event.(type)
if ev == *tetragon.GetEventsResponse_ProcessExec {
exec := ev.ProcessExec
bin := exec.GetProcess().GetBinary()
for _, b := range bins {
if b == bin {
return resp, nil
}
}
}
}
```
Используя такую реализацию, можно заложить любую логику для выявления аномалий. Ограничения накладывают только возможности языка, на котором создано правило.
- Детекторы событий Admission Controller
Эти детекторы имеют похожую структуру, однако вместо API сенсоров eBPF Tetragon использует API клиента Kubernetes.
Давайте рассмотрим пример — демо-детектор, который будет помечать как критические все запросы к API, связанные с ресурсом типа Deployment и выбранным именем.
```go
package admission
import (
enforcer "..." //Реализует Admission review
v1 "k8s.io/api/admission/v1"
)
var pod_names = []string{"hello", "world", "helloworld"}
type ExecDetector struct{}
func (e ExecDetector) Info() DetectorInfo {
return DetectorInfo{
ID: "ADMISSION_DEMO",
Name: "Hello world Detector",
Version: 1,
Description: "Detector checks pods with hello name",
}
}
func (e ExecDetector) Detect(req *v1.AdmissionRequest) enforcer.Severity {
for _, name := range pod_names {
if req.Resource.Resource == "deployments" && req.Resource.Name == name {
return enforcer.CriticalSeverity
}
return enforcer.NoneSeverity
}
```
***
Вы спросите — зачем это все? Открытые технологии «под капотом» PT Container Security позволяют нам отчуждать экспертизу и открыть для сообщества дополнительные возможности для совместной разработки и обмена опытом.
