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

Основные понятия безопасности для приложений и кластеров в Службе Azure Kubernetes (AKS)

  • Статья

Служба безопасности контейнеров защищает конвейер на всех этапах от сборки до рабочих нагрузок приложений, работающих в службе Службы Azure Kubernetes (AKS).

Сквозная система безопасности охватывает среду сборки и реестр.

В состав Kubernetes входят компоненты системы безопасности, такие как стандарты безопасности модулей pod и секреты. Azure включает такие компоненты, как Active Directory, Microsoft Defender для контейнеров, Политика Azure, Azure Key Vault, группы безопасности сети и управляемые обновления кластера. AKS объединяет эти компоненты безопасности, чтобы:

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

В этой статье представлены основные понятия, которые защищают приложения в AKS.

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

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

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

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

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

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

По умолчанию сервер API Kubernetes использует общедоступный IP-адрес и полное доменное имя (FQDN). Вы можете ограничить доступ к конечной точке сервера API, используя диапазоны разрешенных IP-адресов. Кроме того, можно создать полностью частный кластер, чтобы ограничить доступ сервера API к виртуальной сети.

Вы можете управлять доступом к серверу API с помощью управления доступом на основе ролей Kubernetes (Kubernetes RBAC) и Azure RBAC. Дополнительные сведения см. в статье об интеграции Microsoft Entra с AKS.

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

Узлы AKS — это виртуальные машины Azure, которыми вы управляете и которые вы обслуживаете.

  • Узлы Linux выполняют оптимизированные версии Ubuntu или Azure Linux.
  • Узлы Windows Server запускают оптимизированный выпуск Windows Server 2022 с помощью containerd среды выполнения контейнера.

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

Примечание.

Кластеры AKS выполняются:

  • Kubernetes версии 1.19 и выше — пулы узлов Linux используются containerd в качестве среды выполнения контейнера. Пулы узлов Windows Server 2019 и Windows Server 2022 используются containerd в качестве среды выполнения контейнера. Дополнительные сведения см. в разделе "Добавление пула узлов Windows Server с containerdпомощью ".
  • Kubernetes версии 1.19 и более ранних версий — пулы узлов Linux используют Docker в качестве среды выполнения контейнера.

Дополнительные сведения о процессе обновления безопасности для рабочих узлов Linux и Windows см. в разделе "Узлы исправления безопасности".

Кластеры AKS под управлением виртуальных машин Поколения 2 Azure включают поддержку доверенного запуска, которая защищает от расширенных и постоянных атак путем объединения технологий, которые можно независимо включить, например безопасную загрузку и виртуализированную версию доверенного платформенного модуля (vTPM). Администраторы могут развертывать рабочие узлы AKS с проверенными и подписанными загрузчиками, ядрами ОС и драйверами, чтобы обеспечить целостность всей цепочки загрузки базовой виртуальной машины.

Авторизация узла

Авторизация узла — это режим авторизации специального назначения, который специально разрешает запросы API kubelet для защиты от атак "Восток-Запад". Авторизация узла по умолчанию включена в кластерах AKS 1.24 и более поздних версий.

Развертывание узла

Узлы развертываются в подсети частной виртуальной сети без назначенных общедоступных IP-адресов. Для устранения неполадок и управления протокол SSH включен по умолчанию и доступен только по внутреннему IP-адресу. Отключение SSH во время создания кластера и пула узлов или существующего кластера или пула узлов находится в предварительной версии. Дополнительные сведения см. в статье "Управление доступом по протоколу SSH".

Хранилище узла

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

Враждебные мультитенантные рабочие нагрузки

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

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

Изоляция вычислительных ресурсов

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

  • Изолированные контейнеры ядра для использования в качестве узлов агента в кластере AKS. Эти контейнеры полностью изолированы от определенного типа оборудования и изолированы от структуры узла Azure, операционной системы узла и гипервизора. Они предназначены для одного клиента. Выберите один из размеров изолированных виртуальных машин в качестве размера узла при создании кластера AKS или добавлении пула узлов.
  • Конфиденциальные контейнеры (предварительная версия), также основанные на конфиденциальных контейнерах Kata, шифрует память контейнера и запрещает данные в памяти во время вычислений в виде ясного текста, удобочитаемого формата и изменения. Это помогает изолировать контейнеры от других групп контейнеров или модулей pod, а также ядра ОС узла виртуальной машины. Конфиденциальные контейнеры (предварительная версия) используют шифрование памяти на основе оборудования (SEV-SNP).
  • Песочница Pod (предварительная версия) предоставляет границу изоляции между приложением контейнера и общим ядром и вычислительными ресурсами (ЦП, памятью и сетью) узла контейнера.

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

Для подключения к локальным сетям и обеспечения безопасности можно развернуть кластер AKS в имеющейся подсети виртуальной сети Azure. Эти виртуальные сети могут использовать VPN-подключение Azure типа "сеть —сеть" или подключение ExpressRoute к локальной сети. Определите контроллеры входящего трафика Kubernetes с частными внутренними IP-адресами, чтобы ограничить доступ служб к внутреннему сетевому подключению.

Группы безопасности сети Azure

Чтобы фильтровать поток трафика в виртуальных сетях, Azure использует правила групп безопасности сети. Эти правила определяют диапазоны IP-адресов источника и назначения, порты и протоколы, использование которых разрешено или запрещено для доступа к ресурсам. Чтобы разрешить трафик TLS для сервера API Kubernetes, создаются правила по умолчанию. Вы создаете службы с подсистемами балансировки нагрузки, сопоставлениями портов или входящими маршрутами. AKS автоматически изменяет группу безопасности сети для потока трафика.

Если вы предоставляете собственную подсеть для кластера AKS (с Azure CNI или Kubenet), не изменяйте управляемую AKS группу безопасности сети на уровне подсети. Вместо этого создайте дополнительные группы безопасности сети на уровне подсети, чтобы изменить поток трафика. Убедитесь, что они не вмешиваются в необходимый трафик, управляющий кластером, например доступ к подсистеме балансировки нагрузки, обмен данными с плоскости управления или исходящий трафик.

Политика сети Kubernetes

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

Application Security

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

Обеспечение безопасного доступа контейнера к ресурсам

Подобно предоставлению пользователям или группам наименьшего количества требуемых привилегий, контейнеры должны быть ограничены только необходимыми действиями и процессами. Чтобы свести к минимуму риск атак, избегайте настройки приложений и контейнеров, которые требуют повышенных привилегий или корневого доступа. Встроенные функции безопасности Linux, такие как AppArmor и seccomp , рекомендуется в качестве рекомендаций по [безопасному доступу к контейнерам к ресурсам][secure-container-access].

Секреты Kubernetes

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

  1. Создайте секрет с помощью API Kubernetes.
  2. Определите ваш pod или ваше развертывание, затем запросите конкретный секрет.
    • Секреты предоставляются только узлам с pod с запланированным выполнением, которые их требуют.
    • Секрет хранится в tmpfs, а не записывается на диск.
  3. При удалении последнего модуля pod на узле, требующего секрета, секрет удаляется из tmpfs узла.
    • Секреты хранятся в заданном пространстве имен и доступны только из модулей pod в одном пространстве имен.

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

Примечание.

Необработанные файлы манифеста секрета содержат секретные данные в формате base64. Дополнительные сведения см. в официальной документации. Рассматривайте эти файлы как конфиденциальные и никогда не фиксируйте их в системе управления версиями.

Секреты Kubernetes хранятся в и т. д., распределенном хранилище ключей-значение. AKS полностью управляет хранилищем etcd и данные шифруются неактивных данных на платформе Azure.

Следующие шаги

Чтобы приступить к защите кластеров AKS, ознакомьтесь со статьей об обновлении кластера AKS.

См. соответствующие рекомендации по обеспечению безопасности и обновлению кластера в AKS и обеспечению безопасности модулей pod в AKS.

Дополнительные сведения о ключевых понятиях Kubernetes и AKS см. в следующих статьях: