Эдера спонсировала этот пост.
Если бы вы спросили нас несколько лет назад, что такое безопасность контейнеров, мы бы сосредоточились на рисках цепочки поставок программного обеспечения. Мы бы говорили о злонамеренных изображениях, уязвимых зависимостях и скомпрометированных реестрах. Эти угрозы реальны, но с тех пор мы поняли, что они представляют собой лишь небольшую часть общей картины.
Более глубокая проблема является архитектурной. Речь идет не только о том, что находится внутри контейнера, но и о границе, которая его окружает. Однажды мы полагали, что пространства имен, CGROUPS и SECCOMP обеспечивают сильную изоляцию. Мы поняли, что это убеждение основывалось на опасном недопонимании. Ядро Linux, которое лежит в основе контейнеров, является общей поверхностью, и доверяя ему обеспечить изоляцию между арендаторами, создало серьезные слепые безопасности.
В этой статье исследуется то, что мы узнали, трудный способ изоляции контейнеров. Мы хотим поделиться, почему это понимание имеет значение, потому что в тот момент, когда вы перестаете предполагать, что граница безопасна, — это момент, когда вы начинаете проектировать системы, которые действительно есть.
Unix Roots of Linux Security
Unix был разработан с учетом элегантности. Это дало нам основополагающие идеи, такие как «Все есть файл» и «Fail Fast». Но это не было создано для многопоточных рабочих нагрузок. И он, конечно, не был создан для работы с враждебным кодом из неизвестных источников.
Linux унаследовал эту линию. Он начался как рабочая система настольного компьютера и превратился в основу современного облака. И все же это все еще отражает свои корни. Ядро разрешает по умолчанию. Он никогда не предназначался для того, чтобы служить закаленной границей между взаимно нерешенными рабочими нагрузками. Его модель безопасности была модифицирована с течением времени, а не разработана с изоляцией в качестве первого принципа.
Сегодня ядро Linux охватывает более 40 миллионов строк кода. Каждый контейнер разделяет его. Каждый пространство имен, CGROUP и модуль безопасности в конечном итоге проходят через этот же монолитный слой. Это много доверия, чтобы поместить в стареющий фонд.
Контейнеры: абстракция, которая протекает
Контейнеры стали популярными, потому что они облегчили упаковку, развертывание и масштабирование приложений. Системы оркестровки, такие как Kubernetes, создали целую экосистему вокруг этой абстракции. Но эта абстракция тонкая. Контейнеры не являются отдельным временем выполнения; Это просто процессы.
Каждый контейнер отображает идентификатор процесса в Linux. Иллюзия разделения создается с использованием пространств имен ядра. Эти пространства имен скрывают ресурсы, такие как файловые системы, сетевые интерфейсы и обработки деревьев. Но ядро остается разделенным. Это общее ядро становится поверхностью атаки. И в случае побега контейнера эта поверхность атаки становится ответственностью.
Общие векторы атаки включают в себя эксплуатацию маунтов файловой системы, злоупотребление символическими ссылками или использование неправильных привилегий. Эти эксплойты часто нацелены на самого хоста. Оказавшись внутри ядра, злоумышленник может повлиять на другие контейнеры или инфраструктуру, которая их поддерживает. Это не просто теоретический. Контейнер сбегает, и когда они это делают, все на этом узле становится подозрительным.
Почему пространства имен не изолируют
Существует критическая разница между ограничением того, что процесс может видеть и обеспечение соблюдения того, что может сделать процесс. Пространства имен делают первые; Истинная изоляция делает последнее.
В Linux пространства имен, CGROUPS и SECCOMP -фильтры работают вместе, чтобы создать внешний вид сдерживания. Но все они бегут на вершине одного ядра. Если это ядро скомпрометировано, эти границы разрушаются. Там нет криптографической гарантии или оборудования, усиленного оборудованием.
Это приводит к нескольким очень реальным последствиям:
- Один скомпрометированный контейнер может повлиять на все остальное на хосте.
- Устранение нарушений часто означает разрушение целых кластеров.
- Многие команды работают под ложным чувством безопасности.
Как гласит все более популярная поговорка: контейнеры не содержат.
Переосмысление границы: чему нас научили виртуальные машины
Перед контейнерами мы использовали виртуальные машины для изоляции рабочих нагрузок. У каждой виртуальной машины была собственная ядро. Гипервизоры создали сильные границы между рабочими нагрузками, не позволяя одному арендатору повлиять на другого.
Виртуальные машины выпали из -за накладных расходов на производительность и медленного времени запуска. Но многие из этих недостатков с тех пор были рассмотрены. Например, проекты, использующие паравиртуализацию, теперь предлагают производительность, сравнимую с контейнерами, одновременно восстанавливая сильную изоляцию рабочей нагрузки.
Паравиртуализация изменяет гостевую ОС для эффективного взаимодействия с гипервизором. Это устраняет необходимость эмуляции оборудования, сокращения задержки и улучшения использования ресурсов. Несколько проектов с открытым исходным кодом изучили это пространство, демонстрируя, что можно запускать контейнеры в легких виртуальных машинах. Эти системы сохраняют совместимость с Kubernetes и требуют минимальных изменений в рабочих процессах приложений.
По сути, они позволяют вам запускать каждый контейнер — или даже каждый стручок — в своей собственной закаленной зоне. Эти зоны устраняют общее состояние ядра и уменьшают радиус взрыва любого эксплойта. Хотя есть некоторые накладные расходы, это минимально. Во многих случаях время запуска увеличивается менее чем на секунду. Это небольшая цена, чтобы заплатить за истинную изоляцию.
Изоляционные слои: EBPF, наблюдение и песочница
Изоляция — это не только запуск рабочих нагрузок в отдельных средах. Речь также о том, чтобы знать, что они делают, и о том, чтобы контролировать свое поведение.
Именно здесь появляются такие технологии, как EBPF. EBPF позволяет безопасным программам с песочницей работать внутри ядра Linux. Эти программы могут наблюдать системные вызовы, обеспечить соблюдение политик безопасности и выделять журналы, не требуя потребительских агентов.
Инструменты, основанные на EBPF, такие как расширенная наблюдаемая и платформы выполнения, позволяют командам контролировать и реагировать на поведение в режиме реального времени. Они не мешают злоумышленнику войти в систему. Но они резко сокращают время, необходимое для обнаружения и ответа.
Другие методы изоляции включают песочницу Syscall, стробирование файловых систем и минимальное правоприменение. Некоторые проекты предлагают закаленное время выполнения контейнеров, которые интегрируют эти методы, что затрудняет злоумышленника избежать или эскалации привилегий.
Вместе эти усилия изменяют идею о том, что на самом деле означает безопасность контейнеров. Это больше не просто изображения и уязвимости; Речь идет о контроле, видимости и границах доверия.
Что будет дальше
Мы вступаем в новую фазу облачной безопасности. Основное внимание переносится с обнаружения к профилактике, от мониторинга к правоприменению. Вот некоторые из больших тенденций появляются:
- Безопасные время забега становятся более практичными. Они предлагают закаленные границы, не требуя, чтобы разработчики изменили способ создания приложений.
- Инфраструктура становится более композитной. Наблюдаемость, сеть и безопасность объединяются в один политический уровень.
- Рабочие процессы Gitops расширяются, чтобы включить осадку безопасности. Безопасность становится частью версий, проверенных инфраструктурных определений.
Ядро больше не является последней границей. Теперь это один компонент в слоистой программируемой модели безопасности.
Изоляция — самая важная проблема, которую вы не решаете
Мы построили облако на скорости и масштабе. Теперь мы понимаем, что скорость без безопасности — это риск, который мы не можем себе позволить. Контейнеры изменили то, как мы думаем о развертывании, но они не решали изоляцию. Во многих отношениях они скрывали проблему.
Мы хотели бы знать, что безопасность не начинается и не заканчивается кодом внутри контейнера. Это начинается с окружающей среды, в которой он работает — и насколько хорошо эта среда удерживает все остальное.
Реальная работа по безопасности контейнеров не просто исправляет CVES или Scanning Registries. Это переосмысливает, что значит быть изолированным.
И вот большой вопрос: в мире быстрожирующих рабочих нагрузок, общей инфраструктуры и постоянно развивающихся угроз изолировать новую масштабируемость? Это может быть самым важным примитивом в распределенных вычислениях, которые мы до сих пор не получили права.
Edera Reimagines Container Container, обеспечивая оптимизацию ресурсов для рабочих нагрузок без нарушения рабочих процессов разработчика. Мы перепроектировали основную архитектуру: решение с аппаратного обеспечения, а не программное обеспечение. Наш подход соединяет разрыв между тем, как контейнеры отправляются и как они должны работать. Узнайте больше последних из Edera Trending Stories youtube.com/thenewstack Tech Moving быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Даффи Кули — полевой техник в Изоваленте. Подробнее от Duffie Cooley Jed Salazar — Field CTO в Edera. Узнайте больше от Jed Salazar
