На гребне волны

Сисадмин, менеджер, разработчик и тестировщик — столько профессий совмещает в себе DevOps-инженер. Он много знает о процессах и инструментах. Мы помогаем успешно плыть в океане информации и каждый месяц готовим для вас дайджест по DevOps. Welcome aboard!

Grafana Tempo обновилась до 1.4

Очередное обновление распределенной системы трассировки. Появился API-эндпойнт v2. После обновления distributors станут использовать новый эндпойнт, так что заранее позаботьтесь о настройке на ingesters. 

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

Ещё одно изменение — перенос параметров запросов, связанных с поиском. Теперь им выделен отдельный блок search.

Zitification

Prometheus — замечательная система мониторинга. Но с точки зрения сетевой безопасности сразу видна её слабость. Эта система была создана так, чтобы забирать данные HTTP-запросами у целей «в зоне видимости». Вот только часто цели находятся за файерволом и недоступны без дополнительных настроек.

Есть минимум два решения этой задачи. Первый, плохой с точки зрения безопасности — проделать «дыру» в файерволе и через неё выпускать Кракена на волю пропускать трафик Prometheus. Второй — построить оверлейную сеть для организации мониторинга, но при этом не создать очередной вектор атаки для потенциальных злоумышленников.

Здесь как раз приходит на помощь OpenZiti — ПО для создания оверлейной сети, реализующее модель безопасности Zero Trust. С одной стороны, мы используем штатные возможности Prometheus по сбору всех данных, а с другой, перестаём прослушивать порты на Ingress-контроллере. Ещё это будет означать, что больше не обязательно делать API Kubernetes доступным для публичных сетей — весь обмен можно убрать внутрь оверлейной сети.

Узнать детальнее о том, как именно выстроить схему сетевого обмена при помощи OpenZiti можно на сайте проекта: первая, вторая и третья статья.

Raspberry Pi без pi

Зачем DevOps’у одноплатные компьютеры? Это удобный и дешёвый способ построения тестовых стендов для обучения и исследования поведения ПО. Ещё такие компьютеры легко могут выполнять роль агентов в облачной инфраструктуре того же Azure. Существует много проектов, где «малинки» играют ключевую роль. Но их высокая популярность плохо сказалась на безопасности.

Исторически так сложилось, что для Raspberry Pi основной ОС всегда служил особый вариант Debian Linux. Называлась эта ОС — Raspbian. Спустя несколько лет её переименовали в Raspberry Pi OS. Объединяло эти системы наличие дефолтного пользователя pi с паролем raspberry. Часть пользователей просто не меняла реквизиты доступа по-умолчанию, а другие ограничивались только сменой пароля, оставляя старый юзернейм. Любая брутфорс-атака упрощалась, чем и пользовались мамкины хакеры.

Теперь пользователь по-умолчанию удалён из Raspberry Pi OS и при первом запуске система попросит создать пользователя отдельно. Без этого не будет доступа ни к рабочему столу, ни к средствам удалённого управления. К радости пользователей разработчики предусмотрели удобный вариант для headless-установки. Инструмент Raspberry Pi Imager получил возможность предварительной настройки учётной записи пользователя ещё до записи образа на SD-карту.

Злой компилятор

Слышали ли вы об «атаке Томпсона на компилятор» от которой нет защиты? Удивительно, но один из создателей Unix, Кен Томас, рассказал о ней ещё в 1984 году. Суть в следующем — мы не можем со 100% вероятностью быть уверены в честности компилятора, поскольку его тоже приходится собирать с помощью компилятора. Звучит на первый взгляд бредово, но если задуматься, то глубина проблемы ужасает.

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

Вы можете сказать, что дизассемблирование может показать наличие вредоноса, но ведь дизассемблер в свою очередь такое же скомпилированное приложение. Получается, что тут тоже нет доверия. Убрать проблему полностью не представляется возможным.

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

Обучение

Митапы