Эксперты уже продолжительное время не могут сойтись во мнении, какая из этих двух технологий более защищенная, но ситуацию взялась прояснить IBM. Инженер исследовательского подразделения компании и разработчик ядра Linux Джеймс Боттомли в своем блоге написал, что вряд ли эти дискуссии можно назвать плодотворными, поскольку уровень безопасности контейнеров и виртуальных машин (ВМ) часто измерялся не средствами сравнительного анализа, а эмпирически (мол, «гипервизоры более безопасные, чем контейнеры, из-за реализации интерфейса»).
Задавшись целью провести сравнение обеих технологий с точки зрения их защищенности, Боттомли разработал профиль Horizontal Attack Profile (HAP). Проводя оценку, он обнаружил, что «контейнер Docker с хорошо продуманным профилем seccomp (который блокирует неожиданные системные вызовы) обеспечивает безопасность, примерно эквивалентную гипервизору». Свое описание он начинает с профиля вертикальной атаки Vertical Attack Profile (VAP), который включает код для обеспечения работоспособности службы, включая обновления базы данных. Как и код других программ, код VAP содержит уязвимости. Очевидно, что чем больше кода в программе, тем выше шансы, что в нем имеется какое-то количество ошибок.
Тем временем эксплойты, работающие по всему стеку ПО, — как на физических серверах, так и ВМ — это HAP. HAP — наихудший вид уязвимостей в системе безопасности, при которых брешь в одном из базовых слоев (например, в ядре Linux или гипервизоре) может привести к полной компрометации всей инфраструктуры и получению контроля за корневым окружением и всеми запущенными контейнерами. Уровень безопасности HAP зависит от объёма привилегированного кода, который вызывается в процессе работы той или иной системы контейнерной изоляции или виртуализации. Чем меньше привилегированного кода вовлечено в выполнение контейнера, тем выше безопасность всей системы, так как сокращается число потенциальных векторов для атак и уменьшается вероятность присутствия уязвимостей.
Боттомли называет HAP-уязвимости «потенциальными разрушителями бизнеса». Так как же оценить защищенность системы для противостояния HAP? Боттомли объясняет: «Для этого мы берем плотность ошибок кода ядра Linux и умножаем его на количество уникального кода, с которым система работала с момента достижения состояния устойчивости (то есть, когда она перестала взаимодействовать с ядром). Количественный подход предполагает, что плотность ошибок равномерная и, следовательно, HAP аппроксимируется количеством кода, проходимого системой в стационарном состоянии. Для аппроксимации числа строк пройденного кода на работающей системе в распоряжении ядра имеется механизм ftrace, который может применяться для отслеживания всех процессов, которые запущены в пользовательском пространстве».
По его словам, количественный анализ строк кода дает приблизительную оценку уровня безопасности HAP, потому что измеряется общее количество строк, тогда как внутренний поток кода не учитывается ввиду того, что в ftrace отсутствует его детализация. Кроме того, лучше всего эта методология подходит для контейнеров, управление которыми производится группой процессов при помощи системных вызовов, и меньше для гипервизоров, поскольку в этом случае для отслеживания о кода необходимо подключать прямой интерфейс гипервызовов (hypercall API) и отслеживать число обращений к бэкендам (к примеру, запросы к подсистемама Linux-ядра vhost для KVM и dom0 для XEN). Другими словами, нужно вычислить количество строк кода, требующегося для запуска конкретного приложения в ВМ, контейнере или на «голом» железе (bare metal) — чем больше кода оно потребляет, тем больше вероятность наличия уязвимостей в безопасности на уровне HAP.
Помимо подсчета кода эксперт провел несколько стандартных тестов — redis-bench-set, redis-bench-get, python-torornado и node-express, причем последние два также запускались на веб-серверах при помощи обычных внешних тонких клиентов. В качестве подопытных выступили Docker, изолированная среда для контейнеров Google gVisor, контейнерная песочница KVM gVisor-kvm, встроенный гипервизор VM в Linux; легкая ВМ с открытым исходным кодом Kata Containers, недавно представленная IBM контейнерная система Nabla, нацеленная на минимизацию выполняемых в основном ядре системных вызовов. Боттомли обнаружил, что на уровне HAP среда выполнения Nabla лучше защищена, чем гипервизор, работающий на базе технологии Kata. «Это означает, что мы разработали контейнерную систему с лучшим HAP (т. е. более безопасную), чем гипервизоры», — сказал он. Он также добавил, что Docker также научился подавлять непредвиденные системные вызовы на уровне ВМ.
Тестирование Gvisor выявило ряд недостатков. В одних ситуациях он показывал сходные с Docker результаты, но был момент, когда он значительно уступил ему. Боттомли предполагает, что это произошло из-за того, что gVisor переписывал интерфейс системного вызова Linux в Go с целью усилить слой изоляции, однако это вызвало рост количества системных вызовов из среды выполнения Go и, соответственно, повлекло падение производительности gVisor. Дополнительные системные процессы влияют на безопасность гипервизора и, как считает Боттомли, Google следует его доработать.
Эксперт считает, что пора прекратить споры о том, какая из технологий более безопасна — контейнерная или ВМ — и та, и другая имеют одинаковую степень защиты перед наиболее опасными уязвимостями. «Наш следующий шаг — в полной мере устранить воздействие вредоносных приложений, и для этого нужно перейти к фаззинговому тестированию», — считает он. Эта техника тестирования заключается в передаче приложению на вход неправильных, неожиданных или случайных данных. Предметом интереса являются падения и зависания, нарушения внутренней логики и проверок в коде приложения, утечки памяти, вызванные такими данными на входе.
