Контейнеры считаются стандартным способом развертывания этих микросервисов в облаке. Контейнеры лучше виртуальных машин почти во всех отношениях, кроме безопасности, которая может быть главным препятствием для их широкого внедрения.
Эта статья обеспечит лучшее понимание безопасности контейнеров и доступных методов их обеспечения.
Контейнер Linux может быть определен как процесс или набор процессов, запущенных в пользовательском пространстве, которые изолированы от остальной части системы различными инструментами ядра.
Контейнеры – отличная альтернатива виртуальным машинам. Несмотря на то, что контейнеры и виртуальные машины обеспечивают одни и те же преимущества изоляции, они отличаются тем, что контейнеры обеспечивают виртуализацию операционной системы вместо аппаратного обеспечения. Это делает их легкими, более быстрыми для запуска и потребляет меньше памяти.
Поскольку несколько контейнеров используют одно и то же ядро, решение менее безопасно, чем виртуальные машины, где у них есть свои копии ОС, библиотек, выделенных ресурсов и приложений. Это делает виртуальные машины превосходно защищенными, но из-за их высокого размера хранилища и сниженной производительности это создает ограничение на общее количество виртуальных машин, которые могут быть запущены одновременно на сервере. Дальнейшие виртуальные машины занимают много времени для загрузки.
Внедрение микросервисной архитектуры изменило способ разработки программного обеспечения. Микросервисы позволяют разрабатывать программное обеспечение в небольших автономных независимых сервисах. Это облегчает масштабирование приложения и обеспечивает гибкость.
Если часть программного обеспечения необходимо переписать, это можно легко сделать, изменив только эту часть кода, не прерывая никакой другой службы, что было невозможно с монолитным ядром.
1) Особенности ядра Linux
a. Пространства имен
Пространства имен обеспечивают изоляцию ресурсов для процессов, запущенных в контейнере, от ресурсов других процессов. Они разделяют ресурсы ядра на разные процессы. Один набор процессов в отдельном пространстве имен будет видеть один набор ресурсов, в то время как другой набор процессов будет видеть другой. Процессы в разных см. различные идентификаторы процессов, имена хостов, идентификаторы пользователей, имена файлов, имена для доступа к сети и некоторые межпроцессные связи. Следовательно, каждое пространство имен файловой системы имеет свою личную таблицу монтирования и корневой каталог.
Эта изоляция может быть распространена на дочерний процесс, работающий в контейнере. Например, если процессу в контейнере назначен PID 1, тот же PID 1 также может быть назначен любому другому дочернему процессу, использующему пространство имен PID.
Аналогично, другие пространства имен, такие как network, mount, PID, User, UTS, IPC и time, могут применяться для изоляции различных ресурсов в контейнере.
Однако одним из ограничений пространств имен является то, что некоторые ресурсы все еще не знают пространства имен. Например, устройства.
b. Контрольные группы (CGroups)
Они ограничивают и изолируют использование ресурсов, таких как время выполнения процессора, память, дисковый ввод-вывод и сеть, среди определенных пользователем групп процессов, запущенных в системе.
В отличие от пространств имен, cgroups ограничивают количество ресурсов, которые можно использовать, в то время как пространства имен контролируют, какие ресурсы может видеть контейнер.
c. Возможности
Реализации Linux различают две категории процессов: привилегированные процессы (суперпользователь или root) и непривилегированные процессы. Привилегированные процессы обходят все проверки разрешений ядра, в то время как непривилегированные процессы подвергаются полной проверке разрешений на основе учетных данных процесса.
Но в случае контейнеров эти бинарные опционы могут быть проблематичными, потому что предоставление всему контейнеру полной привилегии root может быть опасным.
Возможности превращают эту дихотомию в мелкозернистый контроль доступа. Контейнеру может быть назначен набор возможностей, которые могут уменьшить угрозы корневой операционной системы контейнера.
d. Безопасный режим вычислений (Seccomp)
Seccomp можно использовать для ограничения действий, доступных внутри контейнера. Он ограничивает процесс выполнением определенных предопределенных системных вызовов из пользовательского пространства в пространство ядра. Если процесс пытается выполнить какие-либо другие системные вызовы, он завершается ядром. Большое количество системных вызовов доступно каждому процессу пользовательского пространства, причем многие из них не требуются. Ограничение их уменьшает общую поверхность ядра, подверженную воздействию приложения.
seccomp-bpf – это расширение seccomp, которое позволяет фильтровать системные вызовы с помощью настраиваемой политики. Комбинация ограниченных и разрешенных вызовов организована в профилях, и разные профили могут быть переданы в разные контейнеры. Он обеспечивает более мелкозернистый контроль, чем возможности, предоставляя злоумышленнику ограниченное количество системных вызовов из контейнера во время компрометации безопасности.
2) Модули безопасности Linux (LSMS)
Чтобы понять работу LSMS, давайте посмотрим на объекты ядра.
Объекты ядра
Каждый объект ядра – это просто блок памяти, выделенный ядром. Он хранит информацию об объектах в структуре данных, доступ к которой может получить только ядро. Система создает и манипулирует несколькими типами объектов ядра, включая объекты маркеров доступа, объекты событий, файловые объекты, объекты сопоставления файлов, объекты портов завершения ввода-вывода, объекты заданий, объекты mailslot, объекты мьютекса, объекты канала, объекты процесса, объекты семафора, объекты потока и объекты ожидаемого таймера.
Архитектура LSM Hook
LSMs
Интерфейс LSM опосредует доступ к внутренним объектам ядра, помещая крючки в ядро непосредственно перед их доступом. Он принципиально отвечает на вопрос: “Может ли выполнить для “, например: “Может ли веб-сервер получить доступ к файлам в домашних каталогах пользователей?”. Типы защищаемых объектов включают файлы, индексы, структуры задач, учетные данные и объекты межпроцессной связи. Манипулирование этими объектами представляет собой основной способ взаимодействия процессов со своей средой, и, тщательно определяя допустимые взаимодействия, администратор безопасности может затруднить злоумышленнику использование недостатка в одной программе для перехода к другим областям системы.
Linux Security Module (LSM) предоставляет средства управления на базе MAC с минимальными изменениями в самом ядре. LSM позволяет модулям опосредовать доступ к объектам ядра, помещая хуки в код ядра непосредственно перед доступом. Платформа LSM предоставляет механизм для различных проверок безопасности, которые будут подключены новыми расширениями ядра. Имя “module” является немного неправильным, поскольку эти расширения не являются загружаемыми модулями ядра, а выбираются во время сборки.
Некоторые часто используемые LSM:
SELinux (Security Enhanced Linux) – это реализация MAC по умолчанию в дистрибутивах Linux на базе RedHat. Он известен своей мощью и сложностью. SELinux основан на атрибутах, что означает, что идентификаторы безопасности для файлов хранятся в расширенных атрибутах файлов в файловой системе. SELinux определяет элементы управления доступом для приложений, процессов и файлов в системе. Он использует политики безопасности, которые представляют собой набор правил, которые сообщают SELinux, к чему можно или нельзя получить доступ, для обеспечения доступа, разрешенного политикой.
AppArmor – он реализует политику, ориентированную на задачи, при этом “профили” задач создаются и загружаются из пользовательского пространства. Профили могут разрешать такие возможности, как доступ к сети и доступ к необработанным сокетам. Политики безопасности AppArmor полностью определяют, к каким системным ресурсам могут обращаться отдельные приложения и с какими привилегиями. Задачи в системе, для которых не определен профиль, выполняются в неограниченном состоянии, эквивалентном стандартным разрешениям ЦАП Linux.
Существуют аппаратные механизмы защиты контейнеров, которые защищают контейнеры от других контейнеров и вредоносного или скомпрометированного хоста. Эта статья была посвящена аспекту безопасности контейнеров на основе программного обеспечения.
Это было краткое введение в контейнерную безопасность, и в основном оно было связано с контейнерами Linux. Если вы хотите получить более подробный обзор, перейдите по ссылкам в справочном разделе.
