Поделиться через

Безопасность для AKS

  • Статья

В этой статье рассматриваются аспекты управления безопасностью Служба Azure Kubernetes (AKS), которые необходимо рассмотреть перед реализацией любого решения.

В статье описывается, как реализовать решения с помощью Azure и программного обеспечения с открытым кодом. Решения, которые вы принимаете при создании целевой зоны корпоративного масштаба, могут частично предопределить управление. Сведения о принципах управления см. в статье "Управление безопасностью и соответствие требованиям корпоративного масштаба".

Направления атак

При создании стратегии безопасности для кластеров Kubernetes рассмотрите следующие пять направлений атак:

  • Сборка
  • Реестр
  • Кластер
  • Узел
  • Приложение

Для каждой категории мы обсудим основные риски для рассмотрения и противодействия этим рискам.

Безопасность сборки

Обеспечение безопасности сборки заключается в правильном использовании принципа DevSecOps с образами контейнеров.

Основные риски

Плохая конфигурация образа может привести к уязвимостям безопасности по конвейеру. Например, у вас могут быть контейнеры, работающие с большими привилегиями, чем они нужны. Контейнеры также могут разрешать определенный сетевой доступ, что может поставить систему под угрозу. Ограничение разрешенных системных вызовов на эти вызовы, необходимые для безопасной работы контейнеров, может повысить риск от скомпрометированного контейнера.

Другая уязвимость может позволить контейнеру получить доступ к конфиденциальному каталогу узла или разрешить контейнерам изменять расположения, управляющие базовой функцией узла.

Контейнеры-изгои являются незапланированными контейнерами в среде. Они могут быть результатом тестирования кода разработчиками в тестовых средах. Эти контейнеры, возможно, не прошли строгую проверку уязвимостей или правильно настроены. Такие уязвимости могут дать злоумышленникам точку входа.

Использование базовых образов, которые не являются доверенными источниками или не актуальны для обновлений системы безопасности, также могут привести к уязвимостям в контейнерах, которые они используют для сборки.

Счетчики рисков

Для обеспечения безопасности сборки необходимо реализовать принцип DevSecOps, а именно переместить средства безопасности в начало жизненного процесса разработки, чтобы устранять большинство проблем, прежде чем они начнут двигаться по конвейеру. Это означает не то, что вся ответственность ложится на разработчиков, а то, что им предоставляется определенный контроль над операциями. Разработчики могут просматривать и устранять уязвимости, а также проблемы соответствия, которые они могут решить.

Вы можете создать конвейер, который сканирует и завершает работу сборок, если в них есть 1 или 10 критических уязвимостей. Лучше всего взглянуть на следующий слой вниз. Вы можете начать сегментирование точки ответственности на основе статуса поставщика.

Задайте пороговое значение на уровне состояния уязвимости. Все, что имеет состояние Open, Не исправляется или отложенный продолжает передаваться по конвейеру, где SecOps может получить доступ к риску, так как они делают сегодня. Уязвимость с состоянием исправлений поставщика — это то, что разработчик может устранить. Использование льготных периодов позволяет разработчикам устранять уязвимости.

Наряду с оценкой уязвимостей является оценка соответствия требованиям. Например, разрешение на запуск образа от имени корня или предоставление SSH нарушает состояние соответствия большинства предприятий. Устранить эту проблему во время сборки, а не во время развертывания.

Как правило, вы сканируете изображения на основе теста Docker CIS. При использовании этих типов потоков вы не нарушаете процесс разработки, представляя исправление системы безопасности, но можете улучшить общие встроенные функции безопасности предприятия.

Применение средства, которое реализует эти возможности, очень важно для эффективной реализации правильной стратегии для вашего предприятия. Традиционные инструменты часто не могут обнаруживать уязвимости в контейнерах, что может привести к ложному чувству безопасности. Средства, которые принимают подход к сборке на основе конвейера и неизменяемый и декларативный характер технологий контейнеров, необходимы для правильной защиты экосистемы контейнеров.

Эти инструменты должны обладать следующими свойствами:

  • Интеграция со всем временем существования образов с начала процесса сборки до реестра до среды выполнения.
  • визуализацией уязвимостей на всех уровнях образа, включая базовый уровень образа, платформы приложений и пользовательское программное обеспечение;
  • Принудительное применение на основе политик с правильным уровнем детализации, которое позволяет вашей организации создавать шлюзы качества на каждом этапе процессов сборки и развертывания.

Безопасность реестра

Безопасность реестра решает следующие задачи:

  • Элемент управления "Смещение" из сборки.
  • Предотвращение отправки и извлечения загрязненных изображений.
  • Подпись изображения.

Основные риски

Изображения часто содержат конфиденциальную информацию, включая исходный код организации. Если подключения к реестрам не защищены соответствующим образом, содержимое изображения может представлять угрозу конфиденциальности как серьезную, так как любая другая форма данных, передаваемых в организации. Устаревшие образы с уязвимыми устаревшими версиями в реестре могут увеличить риски безопасности, если они случайно развернуты.

Другая уязвимость безопасности может включать недостаточные ограничения проверки подлинности и авторизации для реестров контейнеров. Эти реестры могут размещать конфиденциальные конфиденциальные активы на изображениях.

При построении и развертывании содержимого распространение этого содержимого является одним из многих векторов атак. Как убедиться, что содержимое, размещенное для распространения, совпадает с контентом, доставленным в предназначенную конечную точку?

Счетчики рисков

Настройте процессы развертывания, чтобы обеспечить подключение средств разработки, сетей и сред выполнения контейнеров к реестрам только через зашифрованные каналы. Кроме того, убедитесь, что содержимое поступает из надежного источника. Чтобы снизить риски использования устаревших изображений:

  • Удалите небезопасные, уязвимые образы, которые больше не должны использоваться из реестров контейнеров.
  • Принудительное применение доступа к изображениям с помощью неизменяемых имен, которые указывают определенные версии изображений, которые будут использоваться. Эту конфигурацию можно реализовать с помощью последнего тега или определенной версии образов. Тег не гарантирует актуальность. По этой причине поместите процесс, чтобы убедиться, что оркестратор Kubernetes использует самые последние уникальные номера или что последний тег представляет самые актуальные версии.

Доступ к реестрам, содержащим конфиденциальные образы, должен требовать проверки подлинности и авторизации. Любые запросы на запись также должны проходить проверку подлинности. Например, политика может позволить разработчикам отправлять только образы в определенные репозитории, за которые они отвечают.

Доступ к этим реестрам должен быть федеративн и использовать политики доступа на уровне бизнес-линии. Например, конвейер CI/CD можно настроить для отправки образов в репозитории только после передачи тестов проверки уязвимостей и контроля качества.

Теперь реестры контейнеров, которые считаются реестрами артефактов, становятся основными средствами для развертывания любого типа контента, а не только образов контейнеров. Каждое облако предоставляет реестр с проектами с открытым исходным кодом и продуктами поставщика, доступными для локального или частного размещения в облачных поставщиках. Содержимое передается по реестрам и между ними от начальной сборки до развертывания в рабочей среде.

Как обеспечить целостность содержимого, который вошел в реестр, совпадает с тем контентом, который выходит из реестра? Внедрение решения подписывания образов гарантирует, что развертывания приходят только из доверенных реестров и развертывают доверенное содержимое.

Безопасность кластера

Безопасность кластера решает следующие задачи:

  • Проверка подлинности и авторизация.
  • Безопасность сети.
  • Управление уязвимостями и соответствием требованиям.

Основные риски

Иногда один кластер Kubernetes может использоваться для запуска различных приложений, управляемых различными командами с различными требованиями уровня доступа. Если доступ предоставляется отдельным пользователям без ограничений или только в соответствии с их потребностями, злоумышленник или неавторизованный пользователь может скомпрометировать рабочие нагрузки, к которым у них есть доступ, и другие ресурсы в кластере.

Другая уязвимость безопасности может возникать, когда собственный каталог пользователя кластера управляет авторизацией и проверкой подлинности. Каталог проверки подлинности организации часто более строго контролируется. Так как эти учетные записи имеют высокий уровень привилегий и чаще всего являются потерянными, вероятность скомпрометированной учетной записи увеличивается.

Этот сценарий может привести к уязвимостям кластера или даже по всей системе. Данные, хранящиеся томами контейнеров, управляются оркестраторами, которые должны иметь доступ к данным независимо от узла, на котором он размещен.

Традиционные сетевые фильтры могут иметь слепоту безопасности из-за наложения сети, предназначенной для шифрования данных во время передачи. Эта конструкция затрудняет мониторинг трафика в кластере, поэтому для мониторинга кластеров Kubernetes могут потребоваться специальные положения.

Трафик из разных приложений, использующих один кластер, может иметь разные уровни конфиденциальности, такие как общедоступный веб-сайт и внутреннее приложение, выполняющее критически важные бизнес-процессы. Совместное использование одной виртуальной сети в кластере может привести к компрометации конфиденциальных данных. Например, злоумышленник может использовать общую сеть, доступную в Интернете, для атаки на внутренние приложения.

Защитите компоненты, поддерживающие работу кластера, от уязвимостей и проблем соответствия. Убедитесь, что вы работаете на последней возможной версии Kubernetes, чтобы воспользоваться преимуществами исправления.

Счетчики рисков

Доступ пользователей кластера Kubernetes должен использовать модель доступа с минимальными привилегиями. Предоставляйте пользователям доступ только для выполнения определенных действий с конкретными узлами, контейнерами и образами, необходимыми для их работы. Участники команды тестирования должны получить ограниченный доступ к контейнерам в рабочей среде. Учетные записи пользователей с доступом на уровне кластера должны жестко контролироваться и использоваться с разреженным образом.

Используйте методы строгой проверки подлинности, такие как многофакторная проверка подлинности для защиты доступа к этим учетным записям. Каталог пользователей организации должен использоваться для управления кластерами с помощью единого входа в отличие от учетных записей пользователей, относящихся к кластеру, которые могут не иметь одинаковый уровень политик и элементов управления.

Используйте методы шифрования, которые позволяют контейнерам правильно получать доступ к данным независимо от узла контейнеров. Эти средства шифрования должны предотвращать несанкционированный доступ к данным со стороны других контейнеров даже на том же узле, у которого не должно быть доступа к ним.

Настройте кластеры Kubernetes для разделения сетевого трафика на дискретные виртуальные сети или подсети по уровню конфиденциальности. Сегментация для каждого приложения также может быть возможной, но определение сетей по уровням конфиденциальности может быть достаточно. Например, виртуальные сети для клиентских приложений, отделенных от тех, кто обслуживает внутренние приложения с конфиденциальным трафиком, должны быть реализованы как минимум.

Для изоляции развертываний для определенных наборов узлов по уровням конфиденциальности можно использовать тоны и допустимые значения. Избегайте размещения высокочувствительных рабочих нагрузок в том же узле, что и рабочие нагрузки с более низким уровнем чувствительности. Использование отдельных управляемых кластеров — более безопасный вариант.

Сегментируйте контейнеры по назначению, конфиденциальности и постоям потока, чтобы обеспечить дополнительную защиту для конфиденциальных рабочих нагрузок. Сегментируя контейнеры таким образом, злоумышленнику сложнее получить доступ к одному сегменту, чтобы получить доступ к другим сегментам. Эта конфигурация обладает дополнительным преимуществом обеспечения того, чтобы остаточные данные, такие как кэши или подключения томов, изолированы на уровне конфиденциальности.

Кластеры Kubernetes необходимо настроить следующим образом.

  • Предоставьте безопасную среду для приложений, работающих на них.
  • Убедитесь, что узлы безопасно добавляются в кластер.
  • Наличие постоянных удостоверений для обеспечения безопасности на протяжении всего жизненного цикла.
  • Предоставляйте актуальную и точную информацию о состоянии кластера, в том числе о сетях и узлах в нем.

Скомпрометированный узел должно быть легко изолировать и удалять из кластера без влияния на производительность кластера. AKS упрощает эту задачу.

Определите стандарты конфигурации среды выполнения контейнера для автоматического обеспечения соответствия требованиям. В Azure существует множество политик, которые упрощают этот процесс, и пользователи также могут создавать собственные политики. Используйте функции безопасности Azure, чтобы постоянно оценивать параметры конфигурации в среде и активно применять их.

Автоматически убедитесь, что устранены уязвимости компонентов Kubernetes. Используйте отдельные среды для разработки, тестирования и рабочей среды, каждый из которых имеет собственные элементы управления и управление доступом на основе ролей (RBAC) для управления контейнерами. Свяжите все создание контейнера с отдельными удостоверениями пользователей, и оно должно быть зарегистрировано для аудита. Эта конфигурация помогает снизить риск изгоев контейнеров.

Безопасность узлов

Безопасность узла решает следующие задачи:

  • Защита среды выполнения.
  • Управление уязвимостями и соответствием требованиям.

Основные риски

Рабочий узел имеет привилегированный доступ ко всем компонентам на узле. Злоумышленники могут использовать любую сетевую службу в качестве точки входа, поэтому предоставление доступа к узлу из нескольких точек может серьезно увеличить ее область атаки. Чем больше область атаки, тем больше шансов злоумышленнику получить доступ к узлу и его операционной системе.

Кроме того, у операционных систем, связанных с контейнерами, такими как используемые на узлах AKS, меньше направлений атак, так как они не содержат библиотеки, которые позволяют обычным операционным системам запускать базы данных и веб-серверы напрямую. Использование общего ядра приводит к более крупной атаке для контейнеров, работающих в той же среде, чем контейнеры в отдельных виртуальных машинах. Это происходит даже в том случае, если используются операционные системы, относящиеся к контейнерам, работающим на узлах AKS.

Операционные системы виртуальных машин предоставляют базовые компоненты системы, в которых могут быть уязвимости и которые могут создавать риски несоответствия. Так как они являются компонентами низкого уровня, их уязвимости и конфигурация могут повлиять на размещение всех контейнеров. AKS защищает пользователей, гарантируя, что эти уязвимости обрабатываются с помощью регулярных обновлений ОС на узлах, работающих в AKS, и сохраняется состояние соответствия рабочего узла.

Неправильные права доступа пользователей также могут привести к рискам безопасности при входе пользователей непосредственно на узлы для управления контейнерами в отличие от плоскости управления AKS. Прямой вход в систему может позволить пользователям вносить изменения в приложения за пределами тех приложений, к которым у них должен быть доступ.

Кроме того, вредоносные контейнеры могут привести к несанкционированному изменению файловой системы на узле. Например, если контейнер может подключить конфиденциальный каталог в ос узла, этот контейнер может внести изменения в файлы. Изменения могут повлиять на безопасность других контейнеров, работающих на узле.

Счетчики рисков

Ограничьте доступ к узлу, отключив доступ по протоколу SSH.

Использование операционной системы для конкретного контейнера в узлах AKS обычно уменьшает количество атак, так как другие службы и функциональные возможности отключены. Они также имеют файловые системы только для чтения и используют другие методики защиты кластера по умолчанию.

Каждую ночь платформа Azure автоматически применяет исправления системы безопасности операционной системы к узлам Linux и Windows. Если для установки обновления системы безопасности для операционной системы Linux требуется перезагрузка узла, она не будет выполнена автоматически. AKS предоставляет механизмы для перезагрузки, чтобы применить эти исправления.

Microsoft Defender для серверов не применяется для узлов AKS Linux и Windows, так как корпорация Майкрософт управляет операционной системой. Если другие виртуальные машины не находятся в подписке, в которой развернут AKS, можно безопасно отключить Microsoft Defender для серверов.

Если среда развернута, включая рекомендуемую целевую зону корпоративного масштаба, можно настроить исключение для назначения политики в группе управления, которая автоматически позволяет Microsoft Defender для серверов избежать ненужных затрат.

Безопасность приложений

Безопасность приложений направлена на решение следующих задач:

  • Защита среды выполнения.
  • Управление уязвимостями и соответствием требованиям.

Основные риски

Образы — это файлы, содержащие все компоненты, необходимые для запуска приложения. Когда последние версии этих компонентов используются для создания образов, они могут быть свободны от известных уязвимостей в то время, но они могут быстро измениться.

Эти файлы должны обновляться с последними версиями, так как разработчики пакетов регулярно выявляют уязвимости безопасности. Перенесите обновления контейнера дальше по потоку, обновляя образы, используемые для создания контейнеров, в отличие от традиционных приложений, которые обычно обновляются на узле.

Вредоносные файлы также могут быть внедрены в образ, который затем можно использовать для атаки на другие контейнеры или компоненты системы. Сторонние контейнеры могут быть возможным вектором атаки. Конкретные сведения могут быть неизвестными о них, и они могут утечки данных. Может быть, контейнеры не были обновлены с необходимыми обновлениями безопасности.

Другой вектор атаки — использование секретов внедрения, таких как пароли и строка подключения непосредственно в файловой системе образа. Эта практика может вызвать риск безопасности, так как любой пользователь с доступом к изображению может получить доступ к секретам.

В самих приложениях могут возникнуть изъяны, например приложения могут быть уязвимы для межсайтовых сценариев или внедрения SQL. При наличии недостатков уязвимость может быть использована для несанкционированного доступа к конфиденциальным данным в других контейнерах или даже в ОС узла.

Среда выполнения контейнера AKS упрощает мониторинг уязвимостей с помощью различных средств безопасности, доступных в Azure. Дополнительные сведения см. в разделе "Общие сведения о Microsoft Defender для Kubernetes".

Вы также должны контролировать исходящий сетевой трафик, отправленный в контейнеры, чтобы контейнеры не могли отправлять трафик через сети различных уровней конфиденциальности, таких как среды, в которых размещаются безопасные данные или в Интернет. Azure упрощает этот элемент управления простым с помощью различных функций безопасности сети и AKS.

По умолчанию планировщики Kubernetes сосредоточены на масштабировании и повышении плотности рабочих нагрузок, выполняющихся на узлах. Они могут размещать модули pod разных уровней конфиденциальности в одном узле только потому, что этот узел имеет самые доступные ресурсы. Этот сценарий может привести к инцидентам безопасности, когда злоумышленники используют доступ к общедоступным рабочим нагрузкам для атак контейнеров, выполняющих более конфиденциальные процессы на одном узле. Скомпрометированный контейнер также может использоваться для поиска в сети других уязвимостей, которыми может воспользоваться злоумышленник.

Счетчики рисков

Никогда не храните секреты в коде приложения или файловых системах. Секреты должны размещаться в хранилищах ключей и предоставляться контейнерам во время выполнения по мере необходимости. AKS может гарантировать, что только контейнеры, которым необходим доступ к определенным ключам, получают доступ к ним и что эти секреты не сохраняются на диске. Например, Azure Key Vault может безопасно хранить эти секреты и предоставлять их в кластере AKS по мере необходимости. Также можно убедиться, что эти секреты шифруются как при хранении, так и при передаче.

Избегайте использования ненадежных образов и реестров и убедитесь, что только образы из доверенных наборов разрешены для запуска в своих кластерах. Для многоуровневого подхода:

  • централизованный контроль над тем, какие именно образы и реестры являются доверенными;
  • идентификацию каждого образа по криптографической подписи;
  • применение политик, гарантирующих, что все узлы запускают только образы из утвержденного набора;
  • проверку подписей перед выполнением;
  • отслеживание и обновление образов и реестров по мере изменения уязвимостей и требований к конфигурации.

Профили безопасных вычислений должны использоваться для ограничения контейнеров и выделения во время выполнения. Пользовательские профили можно создавать и передавать в среды выполнения контейнеров, чтобы дополнительно ограничить их возможности. Как минимум убедитесь, что контейнеры выполняются с профилями по умолчанию. Рекомендуется использовать пользовательские, более ограниченные профили для контейнеров, работающих с высоким уровнем риска.

Средства могут автоматически профилировать приложения с помощью обучения поведения и обнаружения аномалий. Сторонние решения можно использовать для обнаружения аномалий во время выполнения. Аномалии могут включать такие события, как:

  • Недопустимый или непредвиденный процесс выполнения или системные вызовы.
  • Изменения защищенных файлов конфигурации и двоичных файлов.
  • Записывает данные в непредвиденные расположения и типы файлов.
  • Создание неожиданных прослушивателей сети.
  • Трафик, отправляемый в непредвиденные сетевые назначения.
  • Хранилище вредоносных программ и выполнение.

В настоящее время эти задачи решает Microsoft Defender для Kubernetes.

Контейнеры должны работать с их корневая файловая система в режиме только для чтения, чтобы изолировать записи в определенные каталоги, которые эти средства могут легко отслеживать. Эта конфигурация делает контейнеры более устойчивыми к компрометации, так как вы изолируете изменения в этих конкретных расположениях. Их можно легко отделять от остальной части приложения.

Рекомендации по проектированию

AKS имеет несколько интерфейсов для других служб Azure, таких как Идентификатор Microsoft Entra, служба хранилища Azure и Azure виртуальная сеть. Использование этих служб требует особого внимания на этапе планирования. AKS также добавляет дополнительную сложность, требуя применения тех же механизмов управления безопасностью и соответствия, что и для оставшейся инфраструктуры.

Ниже приведены некоторые другие рекомендации по проектированию для управления безопасностью AKS и обеспечения соответствия требованиям.

  • Если вы создаете кластер AKS в подписке, развернутой в соответствии с рекомендациями целевой зоны корпоративного масштаба, ознакомьтесь с политиками Azure, наследуемыми кластерами. Дополнительные сведения см. в политиках , включенных в эталонные реализации целевых зон Azure.
  • Определите, должен ли уровень управления кластера быть доступен через Интернет (мы рекомендуем ограничения IP-адресов), который является стандартным или только из частной сети в Azure или локальном кластере в качестве частного кластера. Если ваша организация выполняет рекомендации по масштабированию целевой зоны корпоративного масштаба, Corp группа управления имеет Политика Azure связана с тем, что кластеры должны быть частными. Дополнительные сведения см. в политиках , включенных в эталонные реализации целевых зон Azure.
  • Оцените использование встроенного модуля безопасности AppArmor в Linux, чтобы ограничить действия, которые могут выполнять контейнеры, такие как чтение, запись и выполнение, или системные функции, например монтирование файловых систем. Например, все подписки имеют политики Azure, которые препятствуют созданию привилегированных контейнеров pod во всех кластерах AKS. Дополнительные сведения см. в политиках , включенных в эталонные реализации целевых зон Azure.
  • Оцените использование seccomp (безопасных вычислений) на уровне процесса, чтобы ограничить количество вызовов процессов, которые могут выполнять контейнеры. Например, Политика Azure, применяемая в рамках универсальной реализации целевой зоны корпоративного уровня в группе управления целевыми зонами, позволяет предотвратить повышение привилегий контейнера до root, использует seccomp в рамках политик Azure для Kubernetes.
  • Определите, доступен ли реестр контейнеров через Интернет или только в определенной виртуальной сети. Отключение доступа к Интернету в реестре контейнеров может негативно повлиять на другие системы, которые полагаются на общедоступное подключение для доступа к нему. Примерами являются конвейеры непрерывной интеграции или Microsoft Defender для сканирования изображений. Дополнительные сведения см. в разделе "Приватное подключение к реестру контейнеров" с помощью Приватный канал Azure.
  • Определите, является ли частный реестр контейнеров общим для нескольких целевых зон или развертывается выделенный реестр контейнеров в каждой подписке целевой зоны.
  • Рассмотрите возможность использования решения по безопасности, например Microsoft Defender для Kubernetes, для обнаружения угроз.
  • Рассмотрите возможность сканирования уязвимостей в образах контейнеров.
  • Рекомендуется отключить Microsoft Defender для серверов в подписке AKS, если виртуальные машины, отличные от AKS, избежать ненужных затрат.

Рекомендации по проектированию

Внимание

Microsoft Defender для облака сканирование изображений несовместимо с конечными точками реестра контейнеров. Дополнительные сведения см. в разделе "Приватное подключение к реестру контейнеров" с помощью Приватный канал.