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

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

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

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

Поверхности атак

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

  • Строить
  • Реестр
  • Кластер
  • Узел
  • Заявление

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

Создание безопасности

Безопасность процесса сборки — это правильное использование DevSecOps с образами контейнеров.

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

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

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

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

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

Меры по снижению рисков

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

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

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

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

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

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

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

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

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

Безопасность реестра заключается в следующем:

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

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

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

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

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

Контрмеры против рисков

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

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

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

Доступ к этим реестрам должен быть федеративн и использовать политики доступа на уровне бизнес-линии. Например, вы можете настроить конвейер 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 для серверов.

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

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

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

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

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

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

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

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

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

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

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

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

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

Меры противодействия рискам

Никогда не хранить секреты в коде приложения или файловой системе. Секреты следует хранить в хранилищах ключей и передавать контейнерам во время выполнения по мере необходимости. 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 через политики Azure для Kubernetes.
  • Определите, доступен ли реестр контейнеров через Интернет или только в определенной виртуальной сети. Отключение доступа к Интернету в реестре контейнеров может негативно повлиять на другие системы, которые полагаются на общедоступное подключение для доступа к нему. Примерами являются конвейеры непрерывной интеграции или Microsoft Defender для сканирования изображений. Дополнительные сведения см. в статье "Приватное подключение к реестру контейнеров" с помощью Приватного канала Azure.
  • Определите, будет ли ваш частный реестр контейнеров использоваться совместно в нескольких посадочных зонах или вы развернете выделенный реестр контейнеров в каждой подписке посадочной зоны.
  • Рекомендуется использовать решение для обеспечения безопасности, например Microsoft Defender для Kubernetes для обнаружения угроз.
  • Рассмотрите возможность сканирования контейнерных образов на наличие уязвимостей.
  • Рекомендуется отключить Microsoft Defender для серверов в подписке AKS, если нет виртуальных машин, не относящихся к AKS, чтобы избежать ненужных затрат.

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

Это важно

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