Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Azure Kubernetes Service (AKS) предоставляет управляемую среду Kubernetes для развертывания и развертывания контейнерных приложений. Microsoft управляет плоскостью управления Kubernetes, а вы отвечаете за защиту рабочих нагрузок, конфигурации узлов, сети, удостоверений и данных в кластерах. При развертывании AKS важно следовать рекомендациям по обеспечению безопасности для защиты этой общей поверхности в жизненном цикле кластера.
В этой статье приведены рекомендации по безопасности, помогающие защитить развертывание AKS. Многие из этих элементов управления предварительно настроены в AKS Automatic, которая запускает кластеры из защищенного базового плана и доступна для включения и управления в AKS Standard. Основные понятия, лежащие в основе этих элементов управления, в том числе принципов безопасности AKS в конвейере сборки и среды выполнения, см. в разделе "Основные понятия безопасности для приложений и кластеров в AKS".
Рекомендации по безопасности в этой статье реализуют принципы нулевого доверия: "Проверить явно", "Использовать минимальный доступ к привилегиям" и "Предположить нарушение". Подробные рекомендации по нулю доверия см. в центре рекомендаций по нулю доверия.
Безопасность для конкретной службы
AKS объединяет примитивы безопасности Kubernetes с элементами управления Azure платформы. Ниже приведены рекомендации по устранению проблем, связанных с обеспечением защиты, уникальными для запуска управляемого кластера Kubernetes, включая целостность узлов, происхождение образа и изоляцию рабочей нагрузки.
Усиление защиты кластера и узлов
- Сохраняйте кластеры в поддерживаемой версии Kubernetes с автоматическими обновлениями кластера: регистрация кластеров в канале автоматического обновления, чтобы пулы элементов управления и пулы узлов получали исправления Kubernetes, которые устраняют известные уязвимости без вмешательства вручную. Дополнительные сведения см. в статье Автоматическое обновление кластера AKS.
- Автоматическая установка обновлений безопасности ОС узла: настройте канал автоматического обновления ОС узла, чтобы узлы получали исправления безопасности ОС Linux и Windows с заданной периодичностью. Дополнительные сведения см. в статье Автоматическое обновление образов операционной системы узла кластера AKS.
- Обеспечьте соблюдение стандартов допуска Pod Security: применяйте стандарты Pod Security уровня Baseline или Restricted на уровне пространства имён, чтобы предотвратить использование привилегированных Pod, совместное использование пространств имён хоста и небезопасное монтирование томов. Дополнительные сведения см. в статье "Защита модулей pod в AKS".
- Развертывание пулов узлов с поддержкой FIPS для регулируемых рабочих нагрузок. Включите пулы узлов с поддержкой FIPS, которые используют проверенные модули шифрования FIPS 140-3, когда рабочие нагрузки должны соответствовать таким требованиям, как соответствие FedRAMP. Дополнительные сведения см. в статье Включение Федерального стандарта обработки информации (FIPS) для пулов узлов AKS.
- Не выполняйте враждебные мультитенантные рабочие нагрузки в общем кластере: стандартный кластер Kubernetes не является жесткой границей безопасности между ненадежными клиентами, так как домен безопасности — это весь кластер, а не отдельный узел. Для рабочих нагрузок, требующих строгой изоляции, используйте физически изолированные кластеры, изолированные типоразмеры узлов виртуальных машин или изоляцию pod’ов. Дополнительные сведения см. в статье Рекомендации по оптимальной организации изоляции кластеров в AKS.
Безопасность образа контейнера и цепочки поставок
- Ограничьте развертывания доверенными реестрами контейнеров: используйте надстройку Политика Azure, чтобы обеспечить получение подами образов только из разрешенных реестров, например из вашего частного Реестр контейнеров Azure, чтобы недоверенные общедоступные образы не могли запускаться в кластере. Дополнительные сведения см. в статье Защита ваших кластеров AKS с помощью Политика Azure.
- Удалите неиспользуемые уязвимые образы с помощью Image Cleaner: включите средство Очистки изображений для автоматического удаления устаревших образов с узлов и уменьшения области атаки, оставленной уязвимыми изображениями. Дополнительные сведения см. в разделе "Очистка изображений" для очистки уязвимых изображений в AKS.
- Сканируйте реестры и выполняйте рабочие нагрузки с помощью Microsoft Defender для контейнеров: обнаружение уязвимых образов и неправильной настройки в реестре и кластерах до и после развертывания. Дополнительные сведения см. в разделе "Обзор Microsoft Defender для контейнеров".
Сетевая безопасность
По умолчанию сервер API AKS доступен через общедоступную конечную точку, а исходящий трафик кластера является неограниченным. Ограничение как входящего доступа к плоскости управления, так и исходящего трафика рабочих нагрузок — одно из самых эффективных изменений, которые вы можете внести, чтобы сократить поверхность сетевых атак кластера.
-
Разверните частный кластер, чтобы удалить конечную точку сервера общедоступного API: создайте частный кластер, чтобы сервер API Kubernetes доступен только из виртуальной сети через частную конечную точку. Дополнительные сведения см. в разделе "Создание частного Azure Kubernetes Service (AKS) кластера".
- Если вы не можете использовать полностью частный кластер, ограничьте конечную точку сервера общедоступного API известным адресам с авторизованными диапазонами IP-адресов. Дополнительные сведения см. в разделе "Безопасный доступ к серверу API" с помощью авторизованных диапазонов IP-адресов.
- Интеграция сервера API с виртуальной сетью: используйте интеграцию виртуальной сети сервера API, чтобы трафик плоскости управления оставался в частной подсети без необходимости туннелирования компонентов. Дополнительные сведения см. в статье "Создание кластера AKS с интеграцией виртуальной сети сервера API".
- Применяйте сетевые политики для управления трафиком между pod’ами: применяйте сетевые политики Kubernetes, чтобы ограничить внутрикластерный трафик между pod’ами только тем, который необходим вашим рабочим нагрузкам. Для получения более подробной информации см. "Защита трафика между подами с помощью сетевых политик в AKS".
- Ограничьте исходящий трафик кластера: настройте пользовательский тип исходящего трафика и направьте исходящий трафик через Брандмауэр Azure, чтобы фильтровать и проверять конечные точки, к которым могут обращаться ваши рабочие нагрузки. Дополнительные сведения см. в разделе "Управление исходящим трафиком" для узлов кластера в AKS.
- Фильтрация исходящего трафика по полному доменному имени. Используйте фильтрацию на основе FQDN в расширенных сетевых службах контейнеров, чтобы разрешить исходящий трафик только утвержденным доменам. Дополнительные сведения см. в разделе Фильтрация по полному доменному имени (FQDN) для Advanced Container Networking Services.
Управление идентификацией и доступом
AKS проверяет подлинность удостоверений кластера и рабочей нагрузки через Microsoft Entra ID и разрешает доступ через Azure RBAC и Kubernetes RBAC. Используйте управляемые удостоверения и авторизацию на основе Microsoft Entra вместо статических учетных данных или отдельных учетных записей Kubernetes.
- Используйте управляемое удостоверение для кластера: настройте кластер так, чтобы AKS получал доступ к ресурсам Azure без статических учетных данных субъекта-службы, которые необходимо регулярно менять. Дополнительные сведения см. в разделе "Использование управляемого удостоверения в Azure Kubernetes Service (AKS)".
- Используйте идентификатор рабочей нагрузки для доступа модулей к ресурсам Azure: свяжите учетные записи служб Kubernetes с идентификаторами рабочей нагрузки Microsoft Entra, чтобы модули получали токены для доступа к ресурсам Azure без хранения секретов. Дополнительные сведения см. в статье "Использование Идентификация рабочей нагрузки Microsoft Entra с AKS".
- Интеграция проверки подлинности кластера с Microsoft Entra ID. Включите интеграцию Microsoft Entra, чтобы пользователи и группы прошли проверку подлинности в кластере с удостоверениями Entra вместо общих сертификатов. Для получения дополнительной информации см. статью о интеграции Microsoft Entra, управляемой AKS.
- Управление доступом к API Kubernetes с помощью Azure RBAC: используйте Azure RBAC для авторизации в Kubernetes и назначайте встроенные роли AKS (Служба Azure Kubernetes RBAC Reader, Служба Azure Kubernetes RBAC Writer, Служба Azure Kubernetes RBAC Admin и Служба Azure Kubernetes RBAC Cluster Admin) на уровне кластера или пространства имен, чтобы предоставить доступ с минимально необходимыми привилегиями. Дополнительные сведения см. в разделе "Основные понятия авторизации кластера".
- Отключите локальные учетные записи Kubernetes: отключите локальные учетные записи, чтобы весь доступ к кластеру осуществлялся через Microsoft Entra ID и не мог обходить авторизацию, обеспечиваемую Entra, с помощью статических учетных данных администратора кластера. Дополнительные сведения см. в статье "Управление локальными учетными записями с помощью интеграции Microsoft Entra AKS".
- Обеспечьте применение условного доступа для администраторов кластеров: применяйте политики условного доступа, требующие многофакторной аутентификации и соответствующих требованиям устройств для удостоверений Entra ID, которые могут создавать, обновлять или удалять кластеры AKS, а также управлять их пулами узлов, сетевыми параметрами и назначениями ролей. Для получения дополнительной информации см. раздел «Требуется MFA для управления Azure».
Защита данных
AKS по умолчанию шифрует данные в состоянии покоя на управляемых дисках. Настройте следующие средства управления, чтобы защитить секреты Kubernetes и использовать собственные ключи, если этого требуют ваши требования соответствия.
- Шифровать секреты Kubernetes в etcd с помощью службы управления ключами: Включите шифрование данных с помощью KMS, чтобы объекты Secret в Kubernetes шифровались на уровне приложения перед записью в etcd с использованием ключей, управляемых платформой, или собственных ключей, управляемых клиентом, в Azure Key Vault. Дополнительные сведения см. в статье Основные понятия о шифровании неактивных данных для AKS.
- Храните секреты приложений в Azure Key Vault: используйте поставщик Azure Key Vault для Secrets Store CSI Driver, чтобы монтировать секреты, ключи и сертификаты из Azure Key Vault вместо их хранения в виде секретов Kubernetes в открытом виде. Дополнительные сведения см. в статье Использование поставщика Azure Key Vault для Secrets Store CSI Driver в AKS.
- Используйте управляемые клиентом ключи для дисков узлов и данных: шифрование дисков ОС и данных с помощью собственных ключей в Key Vault, если вам нужен контроль над жизненным циклом ключа шифрования. Дополнительные сведения см. в разделе Использование собственных ключей (BYOK) для дисков Azure в AKS.
- Включить шифрование на уровне узла: включите шифрование на уровне узла, чтобы временные диски и кэши дисков ОС и данных на виртуальной машине узла шифровались в состоянии покоя на узле. Дополнительные сведения см. в разделе "Шифрование на основе узла" в AKS.
Ведение журналов и мониторинг
Соберите данные телеметрии кластера, уровня управления и рабочей нагрузки, чтобы обнаруживать и исследовать угрозы в кластерах AKS.
- Отслеживайте кластеры с помощью аналитики контейнеров: включите аналитику контейнеров для сбора метрик узлов и контейнеров и журналов для кластеров в рабочую область Log Analytics. Дополнительные сведения см. в разделе "Мониторинг Azure Kubernetes Service (AKS)".
-
Сбор журналов аудита уровня управления с параметрами диагностики: настройка параметров диагностики для отправки сервера API Kubernetes и категорий журналов аудита (
kube-audit,kube-audit-adminиguard) в Log Analytics для исследования безопасности. Дополнительные сведения см. в справочнике по данным мониторинга AKS. - Включите обнаружение угроз с помощью Microsoft Defender для контейнеров: включите Defender для контейнеров для получения оповещений об обнаружении угроз среды выполнения для узлов кластера, рабочих нагрузок и плоскости управления Kubernetes. Дополнительные сведения см. в разделе "Обзор Microsoft Defender для контейнеров".
Соответствие требованиям и управление
Используйте Политика Azure для согласованного применения конфигураций безопасности в кластерах AKS и предотвращения развертывания несоответствующих рабочих нагрузок.
- Обеспечьте применение конфигурации кластера и рабочих нагрузок с помощью Политика Azure для AKS: включите надстройку Политика Azure и назначьте встроенную инициативу политик AKS для аудита и применения таких мер контроля, как разрешённые реестры, ограничения ресурсов и запрет привилегированных контейнеров. Дополнительные сведения см. в статье Защита ваших кластеров AKS с помощью Политика Azure.
- Применение защитных механизмов развертывания в соответствии с рекомендациями Kubernetes: Включите защитные механизмы развертывания для проверки ресурсов кластера на соответствие рекомендациям AKS в режиме предупреждений или принудительного применения. Дополнительные сведения см. в статье "Использование мер защиты при развертывании для применения рекомендаций в AKS".
- Назначение встроенных определений политик AKS для применения конкретных элементов управления: назначение встроенных определений Политика Azure для AKS для применения отдельных элементов управления, таких как требование авторизованных диапазонов IP-адресов или частных кластеров, отключение привилегированных контейнеров и применение внутренних подсистем балансировки нагрузки. Дополнительные сведения см. в статье Встроенные определения Политика Azure для AKS.
Резервное копирование и восстановление
Защитите состояние кластера и данные приложения, чтобы можно было восстановиться после случайного удаления, повреждения или сбоя обновления.
- Резервное копирование состояния кластера и постоянных томов с помощью Резервного копирования AKS: используйте Резервное копирование AKS с хранилищем резервных копий, чтобы планировать резервное копирование ресурсов кластера и постоянных томов, размещенных на Azure Disk и Файлы Azure (SMB), а также восстанавливать пространство имен или весь кластер. Дополнительные сведения см. в статье "Что такое резервное копирование Azure Kubernetes Service (AKS)?".
- Предоставьте доступ к резервному копированию с доверенным доступом вместо широких разрешений: включите доверенный доступ, чтобы хранилище резервных копий достигло кластера с разрешениями с ограниченной областью, а не требуя постоянного административного доступа. Дополнительные сведения см. в разделе Включение ресурсов Azure для получения доступа к кластерам AKS с помощью доверенного доступа.