Эдера спонсировал этот пост.
Пространства имен Kubernetes — один из наиболее знакомых инструментов в наборе инструментов инженера платформы. В статье, опубликованной на сайте The New Stack, пространства имен были представлены как пошаговое руководство по достижению изоляции контейнеров — перспектива, отражающая то, сколько команд используют их сегодня.
Однако термин «изоляция» в этом контексте выполняет большую тяжелую работу. Пространства имен обеспечивают логическое разделение, но они не обеспечивают жестких границ, которые мешают рабочим нагрузкам мешать друг другу во время выполнения.
Это различие не просто семантическое — оно архитектурное. А в современном мире мультитенантных кластеров, рабочих нагрузок, управляемых искусственным интеллектом, и совместного использования графических процессоров именно это различие определяет, сможет ли ваш кластер выдержать взлом или рухнуть, как карточный домик.
Разделение пространств имен, они не изолируются
Пространства имен предоставляют разработчикам и операторам элегантную абстракцию: они позволяют нескольким командам или арендаторам совместно использовать кластер, не затрагивая ресурсы друг друга. Они обеспечивают соблюдение квот, включают управление доступом на основе ролей (RBAC) и позволяют более четко определять область действия политик. Это неоценимо для уменьшения административного хаоса.
Но пространства имен не меняют того фундаментального факта, что все контейнеры, работающие на одном узле, используют одно и то же ядро. Скомпрометированный контейнер в одном пространстве имен по-прежнему может атаковать ядро, использовать общие устройства или перехватывать память графического процессора, поскольку само ядро является общей поверхностью.
Статья Эмбер Вульф о границах пространства имен подчеркивает этот момент на примерах из реальной жизни. Когда администратору клиента предоставляется полный контроль над пространством имен, он часто сохраняет возможности влиять на весь кластер. Опыт красной команды показывает, что границы пространства имен не выдерживают давления. Это политические конструкции, а не барьеры безопасности.
Это различие важно, поскольку мы часто говорим о пространствах имен и изоляции так, как будто они взаимозаменяемы. Это не так. Пространства имен обеспечивают секционирование. Изоляция заключается в настолько жестком ограничении рабочих нагрузок, что даже если одна из них будет скомпрометирована, она не сможет выйти за границы.
Одних пространств имен недостаточно для многопользовательской безопасности
Ограничения пространств имен ярко проявляются в современных схемах атак. Экранирование контейнеров и уязвимости на уровне ядра иллюстрируют проблему:
- Графический процессор уходит: Wiz задокументировал уязвимости NVIDIA, которые позволяют злоумышленникам обходить границы контейнера, используя перехваты и обработку переменных среды. Пространства имен не смогли остановить это, поскольку атака была осуществлена против общего состояния ядра.
- Повышение привилегий: Попав внутрь ядра, злоумышленники могут повысить привилегии, скомпрометировать соседние рабочие нагрузки и перемещаться по узлам.
- Радиус взрыва: В модели, использующей только пространство имен, один скомпрометированный модуль может вызвать каскадные сбои, которые влияют на каждую рабочую нагрузку на узле. В регулируемых отраслях или мультиарендности SaaS это неприемлемо.
Модели безопасности, рассматривающие пространства имен как жесткие границы, опираются на опасное заблуждение: логическое разделение равносильно изоляции во время выполнения. В тот момент, когда контейнер проникает в ядро, все ставки отменяются.
Историческая параллель: виртуальные машины против контейнеров
Стоит помнить, что виртуализация решила эту проблему несколько десятилетий назад. Виртуальные машины (ВМ) устанавливают жесткие границы, предоставляя каждой рабочей нагрузке собственное ядро. Одна виртуальная машина не могла тривиально мешать работе другой. Контейнеры поменяли это на скорость, плотность и маневренность — и в то время эти компромиссы были рациональными.
Но времена изменились. Упрощенная виртуализация и среды выполнения на базе гипервизора устранили разрыв в производительности, который когда-то делал виртуальные машины менее привлекательными. Гипервизоры паравиртуализации и типа 1 теперь предлагают производительность, близкую к исходной, восстанавливая при этом свойства сильной изоляции, которых нет в пространствах имен.
Apple недавно подтвердила этот подход в своей новой Container Framework, которая запускает контейнеры внутри границ, поддерживаемых виртуальными машинами. Такие проекты, как Kata Containers, Firecracker и новые защищенные среды выполнения, такие как Edera, привносят тот же принцип в Kubernetes. Урок ясен: нам больше не придется выбирать между скоростью и безопасностью.
Почему пространства имен не могут служить границами безопасности
Чтобы понять, почему пространства имен не тождественны изоляции, нам нужно углубиться в само ядро Linux.
- Пространства имен скрыть ресурсы, такие как идентификаторы процессов, файловые системы и сетевые интерфейсы. Они меняют то, что видит контейнер.
- Cгруппы контролировать, сколько процессора или памяти может потреблять контейнер. Они регулируют объем использования контейнера.
- Seccomp и AppArmor ограничивать системные вызовы или применять профили, но они по-прежнему работают внутри общего ядра.
Ни один из этих механизмов не предотвращает атаку одного скомпрометированного контейнера на ядро или использование уязвимостей для воздействия на других арендаторов. В лучшем случае они ограничивают видимость и использование ресурсов. Они не предоставляют криптографических или аппаратных гарантий, которые требуются современным рабочим нагрузкам.
Сравните это с изоляцией на уровне гипервизора:
- Каждый контейнер (или модуль) работает на облегченной виртуальной машине с собственным ядром.
- Отсутствие общего состояния ядра означает, что эксплойт в одной виртуальной машине не раскрывает хост или других арендаторов.
- Доступ к графическому процессору и устройствам можно виртуализировать, устраняя утечку по побочным каналам между рабочими нагрузками.
В этом разница между разделением и защитой.
Практический пример: CVE-2025-23266.
Рассмотрим CVE-2025-23266, трехстрочный выход из контейнера NVIDIA, который позволил злоумышленникам достичь компрометации на уровне хоста. Эксплойт сработал, поскольку привилегированные перехватчики выполнялись внутри общего контекста ядра. Вредоносный контейнер может внедрить библиотеку через LD_PRELOAD и мгновенно уйти.
Используя только пространства имен, эта атака увенчалась успехом. При изоляции на уровне гипервизора его можно было бы сдержать. Вредоносная библиотека никогда не затронет ядро хоста — она повлияет только на изолированного гостя. Этот единственный пример показывает, почему пространства имен не могут быть последней линией защиты.
Рост усиленных сред выполнения
Здесь на помощь приходят усиленные среды выполнения. Усиленные среды выполнения переворачивают модель следующим образом:
В результате целые категории атак — повышение привилегий, горизонтальное перемещение, выход из ядра — структурно невозможны, а не просто труднее обнаружить.
Почему это важно для рабочих нагрузок искусственного интеллекта и графических процессоров
ИИ сделал решение этой проблемы более актуальным. Агенты ИИ не просто анализируют данные, они выполняют код, хранят учетные данные и взаимодействуют с внутренними системами. В то же время графические процессоры используются несколькими арендаторами и рабочими нагрузками, часто с открытыми драйверами и интерфейсами памяти. Утечка по боковым каналам здесь не является теоретической; это уже было продемонстрировано на практике.
Когда пространства имен являются единственным средством контроля, рабочие нагрузки ИИ остаются уязвимыми для того же класса экранирований и эскалаций, которые преследуют традиционные контейнерные среды. Усиленная среда выполнения с истинными границами изоляции — единственный способ защититься от этих рисков в большом масштабе.
Более ясный разговор об изоляции
Так что же это нам дает? Пространства имен имеют важное значение: они организуют кластеры, обеспечивают соблюдение политик и обеспечивают управляемость многогрупповых операций. Но их не следует путать с изоляцией. Если Kubernetes — это контракт между разработчиками, инженерами инфраструктуры и группами безопасности, то пространства имен — это административные пункты. Однако настоящая изоляция обеспечивается во время выполнения.
Нам, как отрасли, необходимо перестать смешивать эти два понятия. Логическое разделение — это не то же самое, что защита во время выполнения. Первый уменьшает беспорядок; последнее предотвращает нарушения.
Хорошая новость в том, что нам не нужно отказываться от Kubernetes или контейнеров, чтобы добиться этого. Упрощенная виртуализация, усиленные среды выполнения и контейнеры на базе гипервизора уже существуют, и они легко интегрируются с API Kubernetes. Технология здесь. Что необходимо, так это ясность и желание изменить наше представление об изоляции.
Разделение против защиты
Чтобы построить безопасную и отказоустойчивую инфраструктуру, нам необходимо перезагрузить диалог. Пространства имен ценны, но они не изолируют. Настоящая изоляция требует архитектурных границ, которые действуют во время выполнения, а не только на плоскости управления.
В следующий раз, когда кто-то скажет, что пространства имен обеспечивают изоляцию, помните следующее: секционирование не является защитой. Если ваши рабочие нагрузки имеют значение — если на кону стоят соответствие требованиям, многопользовательская среда или безопасность ИИ — то одних пространств имен недостаточно.
Отрасль должна выйти за рамки иллюзии изоляции и использовать среду выполнения, которая обеспечивает ее по-настоящему.
Edera переосмысливает среду выполнения контейнеров, обеспечивая оптимизацию ресурсов для рабочих нагрузок, не нарушая рабочие процессы разработчиков. Мы перепроектировали базовую архитектуру: решение проблемы начинается с аппаратного обеспечения, а не программного обеспечения. Наш подход устраняет разрыв между тем, как доставляются контейнеры, и тем, как они должны работать. Узнайте больше Последние новости от Edera ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Льюис Денэм-Пэрри — инженер по кадровым решениям в Edera. Льюис Денэм-Пэрри проводит дни, управляя контейнерами, а ночи проверяя их безопасность. В Edera он сосредоточен на обеспечении безопасности и изоляции, в которых мы всегда нуждались, но часто нам не хватало. Его работа… Подробнее от Льюиса Денэма-Пэрри
