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

Безопасность контейнеров защищает весь сквозной конвейер от сборки до рабочих нагрузок приложений, выполняемых в Azure Kubernetes Service (AKS).

Безопасная цепочка поставок включает среду сборки и реестр.

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

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

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

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

Это важно

Начиная с 30 ноября 2025 Azure Kubernetes Service (AKS) больше не поддерживает или не предоставляет обновления системы безопасности для Azure Linux 2.0. Образ узла Azure Linux 2.0 заморожен в выпуске 202512.06.0. Начиная с 31 марта 2026 г. образы узлов будут удалены, и вы не сможете масштабировать пулы узлов. Миграция на поддерживаемую версию Azure Linux путем обновления пулов узлов до поддерживаемой версии Kubernetes или путем перехода на osSku AzureLinux3. Дополнительные сведения см. в проблеме на GitHub о выходе из эксплуатации и в объявлении о прекращении обновлений Azure. Чтобы оставаться в курсе объявлений и обновлений, следуйте заметкам о выпуске AKS.

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

Безопасность процесса сборки — это отправная точка вашей защищённой цепочки поставок. Перед продвижением образов в среды развертывания выполните в CI статический анализ, а также оценку уязвимостей и соответствия требованиям.

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

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

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

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

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

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

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

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

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

Для AKS Automatic интеграция виртуальной сети сервера API предварительно настроена как часть состояния безопасности по умолчанию. В AKS Standard эта же возможность доступна и может быть включена в зависимости от требований к сетевой архитектуре и безопасности.

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

Параметры автоматической безопасности AKS по умолчанию

AKS Automatic включает усиленную базовую конфигурацию с предварительно настроенными по умолчанию мерами безопасности, в том числе:

  • Azure RBAC для авторизации Kubernetes
  • Интеграция виртуальной сети сервера API
  • Идентификация рабочей нагрузки и эмитент OIDC
  • Защита развертывания и базовые стандарты безопасности Pod в режиме принудительного применения
  • Очистка образа для удаления неиспользуемых уязвимых образов
  • Ограничения безопасности пула управляемых узлов системы, которые сохраняют границы между рабочими нагрузками клиентов и инфраструктурой, управляемой AKS

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

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

Узлы AKS — это виртуальные машины Azure (VM). В AKS Standard вы управляете параметрами конфигурации пула узлов и жизненным циклом. В AKS Automatic AKS управляет пулами системных узлов и основными компонентами системы от вашего имени, включая масштабирование и обновление, с ограничениями безопасности для управляемой системы инфраструктуры.

Узлы Linux выполняют оптимизированные версии Ubuntu или Azure Linux. Windows Server узлы запускают оптимизированный выпуск Windows Server с помощью среды выполнения контейнера 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 с проверенными и подписанными загрузчиками, ядрами ОС и драйверами, чтобы обеспечить целостность всей цепочки загрузки виртуальной машины.

Параметры ОС, оптимизированной для контейнеров и безопасности

Azure Контейнер Linux (ACL) — это неизменяемая, оптимизированная для контейнеров ОС для AKS. ACL создан на основе проекта Flatcar Container Linux и развивает проверенную, неизменяемую архитектуру Flatcar, ориентированную прежде всего на контейнеры, добавляя пакеты Azure Linux, обновления и сопровождение, а также интеграцию с платформой. Это позволяет ACL оставаться тесно согласованной с разработкой Flatcar в upstream, одновременно отвечая эксплуатационным требованиям Azure, а также требованиям безопасности и нормативного соответствия. Дополнительные сведения о Flatcar Container Linux см. в документации по Flatcar.

ACL общедоступен (GA) в качестве параметра ОС в AKS, начиная с AKS версии 1.34. Пулы узлов ACL можно развернуть в новом кластере AKS, добавить пулы узлов ACL в существующие кластеры и перенести существующие пулы узлов Linux в ACL.

Дополнительные сведения об ACL см. в статье Обзор Azure Container Linux (ACL) для AKS.

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

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

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

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

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

Для предоставления хранилища узлы используют Azure Managed Disks. Для большинства размеров узлов виртуальной машины Azure Managed Disks — это премиум-диски на основе высокопроизводительных SSD. Данные, хранящиеся на управляемых дисках, автоматически шифруются в состоянии покоя на платформе Azure. Чтобы повысить избыточность, Azure Managed Disks безопасно реплицируются в центре обработки данных Azure.

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

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

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

Изоляция вычислений

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

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

Сетевая безопасность

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

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

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

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

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

Сетевая политика Kubernetes

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

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

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

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

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

Так же, как вы должны предоставлять пользователям или группам минимально необходимые привилегии, следует ограничивать контейнеры только необходимыми действиями и процессами. Чтобы уменьшить риск атаки, избегайте настройки приложений и контейнеров, требующих повышенных привилегий или доступа к root. Встроенные функции безопасности Linux, такие как AppArmor и seccomp, рекомендуются в качестве лучших практик для обеспечения безопасности доступа контейнеров к ресурсам.

Секреты Kubernetes

С помощью Kubernetes Secret вы можете вводить конфиденциальные данные в поды, такие как учетные данные доступа или ключи.

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

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

Заметка

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

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

Связанный контент

Чтобы начать защищать ваши кластеры AKS, см. Обновление кластера AKS.

Если вы оцениваете значения по умолчанию для конкретных режимов и обязанности по эксплуатации, см. статью Что такое Azure Kubernetes Service (AKS) Automatic?

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

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

  • Last updated on