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

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

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

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

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

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

Обеспечение безопасности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AKS выпустила поддержку двух новых оптимизированных параметров ОС Linux. Azure Linux OS Guard (предварительная версия) создается корпорацией Майкрософт и оптимизирована для Azure. OS Guard создается на основе Azure Linux с специализированной конфигурацией для поддержки контейнерных рабочих нагрузок с оптимизацией безопасности. Flatcar Container Linux для AKS (предварительная версия) — это нейтральная к производителю операционная система на основе CNCF, оптимизированная для контейнеров и подходящая для работы в многооблачных и локальных средах. Эти параметры ОС обеспечивают повышенную безопасность по сравнению с другими параметрами ОС Linux, такими как:

• В Azure Linux OS Guard и Flatcar Container Linux для AKS есть неизменяемая операционная система, которую нельзя изменить в процессе выполнения. Все двоичные файлы ОС, библиотеки и статическая конфигурация доступны только для чтения, а целостность битов для битов часто защищена криптографически. Эти специальные операционные системы поставляются как автономные образы и не могут управлять пакетами или другими традиционными средствами изменения ОС. Рабочие нагрузки пользователей выполняются в изолированных средах, таких как контейнеры, изолированные от ОС.
• В Azure Linux OS Guard и Flatcar Container Linux для AKS используется SELinux для обязательного контроля доступа.
• Azure Linux OS Guard обеспечивает включение FIPS и доверенного запуска , обеспечивая улучшенную совместимость и защиту от расширенных и постоянных атак путем объединения безопасной загрузки и виртуализированной версии доверенного платформенного модуля (vTPM).

При выборе используемых параметров ОС, оптимизированных для контейнеров, AKS рекомендует следующее:

• Используйте Flatcar Container Linux для AKS (предварительная версия), если вы ищете неизменяемую ОС, независимую от поставщика, с поддержкой на различных облачных платформах.
• Используйте Azure Linux OS Guard (предварительная версия), если вы ищете неизменяемую ОС, готовую для предприятия, рекомендуемую корпорацией Майкрософт.
• Используйте Ubuntu, если вы ищете универсальную операционную систему, не привязанную к конкретным поставщикам, с поддержкой различных облачных платформ.
• Используйте Azure Linux , если вы ищете операционную систему общего назначения корпоративной подготовки, рекомендуемую корпорацией Майкрософт.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так же, как вы должны предоставлять пользователям или группам минимально необходимые привилегии, следует ограничивать контейнеры только необходимыми действиями и процессами. Чтобы уменьшить риск атаки, избегайте настройки приложений и контейнеров, требующих повышенных привилегий или доступа к 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 только конкретному поду.

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

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

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

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

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

• Кластеры и нагрузки Kubernetes / AKS
• Идентификация Kubernetes / AKS
• Виртуальные сети Kubernetes и AKS
• Хранилище Kubernetes и AKS
• Масштабирование Kubernetes / AKS