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

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

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

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

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

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

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

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

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

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

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

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

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