Автор | Куанг Даху, технический эксперт Alibaba
Управляемое чтение: Как решить проблему изоляции безопасности мультитенантных кластеров — это ключевой вопрос для предприятий, переходящих в облако.В этой статье в основном представлены основные концепции и распространенные формы приложений мультитенантных кластеров Kubernetes, а также бизнес-сценарий совместное использование кластеров внутри предприятий на основе Kubernetes Native и ACK. Существующие возможности управления безопасностью кластера позволяют быстро внедрять соответствующие решения для мультитенантных кластеров.
Что такое многопользовательский кластер?
Здесь давайте сначала представим «арендаторов».Понятие арендаторов не ограничивается пользователями кластера. Оно может включать набор рабочих нагрузок, состоящих из вычислительных, сетевых, хранилищ и других ресурсов. В мультитенантном кластере необходимо обеспечить максимальную изоляцию безопасности для разных арендаторов внутри кластера (возможно, мультикластера в будущем), чтобы максимально избежать атак злоумышленников на других арендаторов. ресурсы справедливо между ними.
С точки зрения безопасности изоляции мы можем разделить ее на два типа: Soft Multi-tenancy и Hard Multi-tenancy.
- Среди них мягкая изоляция больше подходит для требований мультиарендности внутри предприятия.В этой форме по умолчанию нет злонамеренных арендаторов.Целью изоляции является защита бизнеса между внутренними командами и защита от возможных атак безопасности;
- Жесткая изоляция предназначена больше для поставщиков услуг, которые предоставляют услуги внешнему миру.Поскольку фон безопасности бизнес-пользователей в разных арендаторах не может быть гарантирован в рамках этой бизнес-формы, по умолчанию существует взаимная атака между арендаторами и между арендаторами и системой K8s. возможно, поэтому здесь также требуется более строгая изоляция в качестве гарантии безопасности.
Различные сценарии применения мультитенантности будут более подробно описаны в следующем разделе.
Сценарии мультитенантных приложений
Далее представлены два типичных корпоративных мультитенантных сценария приложений и различные требования к изоляции.
Мультиарендность общих кластеров внутри предприятия
В этом сценарии все пользователи кластера находятся внутри предприятия, что также является текущим режимом использования многих клиентов кластера K8s.Из-за контролируемости личности пользователя службы риск безопасности этой бизнес-формы относительно контролируем. Ведь Начальник может напрямую увольнять сотрудников с плохими намерениями:) По сложности внутренней кадровой структуры предприятия мы можем логически изолировать ресурсы из разных отделов или команд через пространства имен, а бизнес-персонал определить со следующими ролями :
- Администратор кластера: имеет возможности управления кластером (расширение емкости, добавление узлов и т. д.), отвечает за создание и выделение пространств имен для администраторов арендаторов, отвечает за CRUD различных политик (RAM/RBAC/networkpolicy/quota...);
- Администратор арендатора: имеет как минимум доступ только для чтения к оперативной памяти кластера, управляет конфигурацией RBAC соответствующего персонала в арендаторе;
- Пользователи в арендаторе: используйте ресурсы K8s в рамках разрешений в соответствующем пространстве имен арендатора.
На основе установления контроля доступа на основе ролей пользователей нам также необходимо обеспечить сетевую изоляцию между пространствами имен и разрешать межклиентские запросы приложений только в рамках белого списка между различными пространствами имен.
Кроме того, для сценариев приложений с высокими требованиями к уровню безопасности бизнеса нам необходимо ограничить возможности ядра контейнеров приложений.Мы можем сотрудничать с seccomp/AppArmor/SELinux и другими инструментами политики, чтобы ограничить возможности среды выполнения контейнера.
Конечно, существующей одноуровневой логической изоляции пространства имен Kubernetes недостаточно для удовлетворения требований изоляции некоторых крупномасштабных корпоративных приложений для сложных бизнес-моделей.Virtual Cluster, который обеспечивает более точное управление несколькими арендаторами за счет абстрагирования модели ресурсов арендатора более высокого уровня, чтобы компенсировать отсутствие собственных возможностей пространства имен.
Мультиарендность по модели обслуживания SaaS и KaaS
В сценарии с несколькими арендаторами SaaS арендаторы в кластере Kubernetes соответствуют каждому экземпляру приложения-службы на платформе SaaS и плоскости управления SaaS.В этом сценарии каждый экземпляр приложения-службы на платформе может быть разделен на разные пространства имен. Конечные пользователи службы не могут взаимодействовать с компонентами плоскости управления Kubernetes. Эти конечные пользователи могут видеть и использовать консоль SaaS. Они используют службу или развертывают бизнес через настраиваемую плоскость управления SaaS верхнего уровня (как показано на рисунке слева). рисунок ниже). Показать).
Например, платформа для ведения блогов развертывается для работы в многопользовательском кластере. В этом сценарии арендатором является экземпляр блога каждого клиента и собственная плоскость управления платформы. Плоскость управления платформой и каждый размещенный блог будут работать в разных пространствах имен. Клиенты будут создавать и удалять блоги и обновлять версии программного обеспечения для блогов через интерфейс платформы, но не смогут понять, как работает кластер.
Сценарий мультиарендности KaaS распространен среди поставщиков облачных услуг. В этом сценарии службы бизнес-платформы напрямую доступны пользователям в разных арендаторах через плоскость управления Kubernetes. Конечный пользователь может использовать собственный API K8s или расширенный интерфейс. поставщиком услуг на основе CRD/контроллеров. Для самого основного требования к изоляции разным арендаторам также требуется логическая изоляция доступа через пространства имен, при этом обеспечивая изоляцию квот сети и ресурсов между разными арендаторами.
В отличие от общего кластера внутри предприятия, здесь все конечные пользователи из недоверенных доменов, и неизбежно присутствуют злоумышленники, выполняющие вредоносный код на сервисной платформе, поэтому для мультитенантных кластеров по сервисной модели SaaS/KaaS нам нужно Изоляция безопасности более высокого стандарта и существующих собственных возможностей Kubernetes недостаточно для удовлетворения требований безопасности.По этой причине нам нужна изоляция на уровне ядра, такая как безопасные контейнеры во время выполнения контейнеров, чтобы усилить безопасность арендатора в этой бизнес-форме.
Реализовать многопользовательскую архитектуру
При планировании и реализации мультиарендного кластера первое, чем мы можем воспользоваться, — это слой изоляции ресурсов самого Kubernetes, включая сам кластер, пространство имен, узлы, модули и контейнеры — модели изоляции ресурсов на разных уровнях. Когда приложение загружает разных арендаторов, которые могут совместно использовать одну и ту же модель ресурсов, между ними возникают риски безопасности. С этой целью нам необходимо контролировать домены ресурсов, к которым каждый арендатор может получить доступ при реализации мультиарендности, и на уровне планирования ресурсов сделать все возможное, чтобы контейнеры, обрабатывающие конфиденциальную информацию, работали в относительно независимых узлах ресурсов. , когда нагрузки от разных арендаторов используют один и тот же ресурсный домен, риск атак между арендаторами можно снизить с помощью политик управления безопасностью во время выполнения и планированием ресурсов.
Хотя существующих возможностей безопасности и планирования Kubernetes недостаточно для полной реализации мультиарендной изоляции, в сценариях приложений, таких как общие кластеры внутри предприятия, изоляция ресурсных доменов между арендаторами осуществляется через пространства имен и в то же время через RBAC. , PodSecurityPolicy, NetworkPolicy Модель политики, например та, которая управляет ограничениями арендатора на объем и возможности доступа к ресурсам, и сочетание существующих возможностей планирования ресурсов уже могут обеспечить значительные возможности изоляции безопасности. Для сервисных платформ, таких как SaaS и KaaS, мы можем использовать недавно запущенный сервис Alibaba Cloud Container.Контейнер-песочница безопасностиЧтобы достичь изоляции на уровне ядра контейнера, он может в наибольшей степени избегать межтенантных атак со стороны злонамеренных арендаторов с помощью методов обхода.
В этом разделе рассматриваются методы работы с несколькими арендаторами, основанные на встроенных возможностях безопасности Kubernetes.
Контроль доступа
AuthN & AuthZ & Admission
Авторизация кластера ACK разделена на два этапа: авторизация RAM и авторизация RBAC.Авторизация RAM действует на контроль доступа к интерфейсу управления кластером, включая разрешения CRUD для кластера (такие как видимость кластера, расширение и сжатие, добавление узлов и т. д.), а авторизация RBAC используется для управления доступом к модели ресурсов Kubernetes в кластере и может обеспечить улучшенную авторизацию указанных ресурсов с точностью до пространства имен.
Управление авторизацией ACK предоставляет различные уровни предустановленных шаблонов ролей для пользователей в арендаторе, поддерживает привязку нескольких определяемых пользователем ролей кластера и поддерживает авторизацию групповых пользователей. Для получения дополнительной информации об авторизации управления доступом, связанной с кластером, в ACK см.Связанные справочные документы.
NetworkPolicy
NetworkPolicy может управлять сетевым трафиком между модулями службы разных клиентов и может открывать ограничения доступа к службам между арендаторами с помощью белого списка.
Вы можете настроить NetworkPolicy в кластере службы контейнеров с помощью сетевого подключаемого модуля Terway,здесьДоступны некоторые примеры конфигураций политик.
PodSecurityPolicy
PSP — это собственная кластерная модель ресурсов K8, которая может проверять, удовлетворяет ли его поведение во время выполнения ограничениям соответствующей политики PSP на этапе допуска запроса на создание модуля в apiserver, например, проверяет, использует ли модуль сеть хоста, файловая система, указанный порт, пространство имен PID и т. д., в то же время он может ограничивать пользователей в арендаторе для открытия привилегированных контейнеров, ограничивать типы дисков и принудительно монтировать только для чтения; мало того, PSP также может добавлять соответствующий SecurityContext для модуля на основе политики привязки, включая различные параметры, такие как uid, gid и добавленные или удаленные возможности ядра среды выполнения контейнера.
Для получения информации о том, как включить использование приема PSP и связанные с ними политики и привязки разрешений, пожалуйста, обратитесь кздесь.
OPA
OPA (Open Policy Agent) — это мощный механизм политик, который поддерживает несвязанные решения политик, и у сообщества уже есть относительно зрелый подход к Kubernetes.Комплексное решение. Когда существующая изоляция RBAC с детализацией пространства имен не может удовлетворить сложные требования безопасности корпоративных приложений, OPA может обеспечить детальное управление политикой доступа на уровне объектной модели.
В то же время OPA поддерживает семислойное определение политики NetworkPolicy и метки / метки, основанное на аннотационном пространстве, который может использоваться в качестве эффективного улучшения к родной сети K8S.
Связанные с управлением ресурсами
Resource Quotas & Limit Range
В сценарии с несколькими арендаторами разные команды или отделы совместно используют ресурсы кластера, и неизбежно возникает конкуренция за ресурсы, поэтому нам необходимо ограничить квоту использования ресурсов для каждого арендатора. Среди них ResourceQuota используется для ограничения общего запроса ресурсов и ограничения, занимаемого всеми модулями в соответствующем пространстве имен арендатора, а LimitRange используется для установки запроса ресурсов по умолчанию и предельных значений развернутых модулей в соответствующем пространстве имен арендатора. Кроме того, мы также можем ограничить квоту ресурсов хранения арендатора и квоту количества объектов.
Подробное руководство по квотам ресурсов можно найти по адресуздесь.
Pod Priority/Preemption
Начиная с версии 1.14 приоритет и вытеснение модулей стали стабильными функциями из бета-версии, в которых приоритет модуля определяет приоритет модулей, ожидающих в очереди планирования в состоянии ожидания; и когда ресурсов узла недостаточно, модули с высоким приоритетом не могут быть запланированы. ., планировщик попытается вытеснить модули с низким приоритетом, чтобы обеспечить возможность планирования развертывания модулей с высоким приоритетом.
В сценарии с несколькими арендаторами можно использовать параметры приоритета и вытеснения, чтобы обеспечить доступность важных бизнес-приложений в арендаторе; в то же время приоритет пода можно использовать в сочетании с ResouceQuota, чтобы ограничить количество квот, которые арендатор имеет под заданный приоритет.
Dedicated Nodes
Примечание: злонамеренный арендатор может избежать политики пятен состоит из узлов и механизмов устойчивости. Следующее описание предназначено для внутренних доверенных кластерных арендаторов, или арендаторы не могут получить доступ к плоскости управления кластером Kubernetes напрямую.
Заражая определенные узлы в кластере, эти узлы могут быть назначены для монопольного использования несколькими арендаторами. Например, в мультитенантном сценарии узлы GPU в кластере могут быть зарезервированы для сервисных групп, которым необходимо использовать GPU в бизнес-приложениях через taints. Администраторы кластера могут запятнать узел меткой, такой как эффект: «NoSchedule», и только модули с соответствующими настройками допуска могут быть запланированы на узле.
Конечно, злоумышленники также могут получить доступ к узлу, добавив ту же конфигурацию допуска в свои собственные модули, поэтому только использование механизмов taint и допуска узла не может гарантировать эксклюзивность целевого узла в ненадежном многопользовательском кластере.
Чтобы узнать, как использовать механизм taint узла для управления планированием, см.здесь.
Защита конфиденциальной информации
secrets encryption at REST
В мультиндантном кластере хранилище ETCD различные арендаторы имеют один и тот же набор пользователей, конечные пользователи могут получить доступ к сцене Kubernetes под плоскодом управления, данные, которые нам необходимо для защиты секретов, избегая конфигурации политики контроля доступа. Неправильное раскрытие конфиденциальной информации при обстоятельствах. Отказ Для этой цели ссылочные секретные возможности шифрования K8S родные, см.здесь.
ACK также предоставляет решение с открытым исходным кодом для шифрования секретов на основе службы Alibaba Cloud KMS, см.здесь.
Суммировать
При реализации мультитенантной архитектуры в первую очередь необходимо определить соответствующие сценарии приложений, в том числе оценить степень надежности пользователей и загрузки приложений в арендаторе и соответствующую степень изоляции безопасности. Исходя из этого, следующие пункты являются основными требованиями к изоляции безопасности:
- Включите конфигурацию безопасности по умолчанию для кластера Kubernetes: включите аутентификацию RBAC и внедрите мягкую изоляцию на основе пространства имен, включите шифрование секретов для усиления защиты конфиденциальной информации, выполните соответствующую настройку безопасности на основе контрольных показателей CIS Kubernetes;
- Включите NodeRestriction, AlwaysPullImages, PodSecurityPolicy и другие связанные контроллеры допуска;
- Ограничить привилегированный режим развертывания пода через PSP, при этом контролируя его SecurityContext во время выполнения;
- Настроить сетевую политику;
- Используйте Resource Quota & Limit Range, чтобы ограничить квоту использования ресурсов арендатора;
- Следуйте принципу минимизации разрешений при работе приложения и максимально уменьшите системные разрешения контейнера в поде;
- Регистрируйте все;
- Подключитесь к системе мониторинга, чтобы реализовать мониторинг измерения приложения-контейнера.
Для моделей обслуживания, таких как SaaS и KaaS, или когда мы не можем гарантировать достоверность пользователей в арендаторе, нам необходимо использовать более надежные методы изоляции, такие как:
- Детализированный контроль доступа на уровне сети или объекта с использованием механизмов динамической политики, таких как OPA;
- Используйте безопасные контейнеры для обеспечения изоляции безопасности на уровне ядра во время выполнения контейнера;
- Полное многопользовательское изоляционное решение для таких служб, как мониторинг, ведение журналов и хранение.
Уведомление:Источник картинок в тексте.
"Облачная нативная платформа AlibabaСосредоточьтесь на микросервисах, бессерверных технологиях, контейнерах, Service Mesh и других технических областях, сосредоточьтесь на популярных тенденциях в облачных технологиях и практиках крупномасштабного внедрения облачных технологий, а также станьте техническим кругом, который лучше всего понимает разработчиков облачных технологий. "