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

  • Статья
  • Чтение занимает 7 мин

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Узлы Linux работают под управлением оптимизированных версий Ubuntu или Mariner.
  • Узлы Windows Server используют оптимизированный выпуск Windows Server 2019, а также среду выполнения контейнеров Docker или containerd.

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

Примечание

Кластеры AKS используют:

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

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

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

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

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

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

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

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

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

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

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

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

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

Выберите один из размеров изолированных виртуальных машин в качестве размера узла при создании кластера AKS или добавлении пула узлов.

Обновления кластера

Azure предоставляет средства оркестрации для обновления кластера и компонентов AKS, обеспечения безопасности и соответствия требованиям, а также доступа к новейшим функциям. Эта оркестрация охватывает главные компоненты и компоненты агента Kubernetes.

Чтобы начать обновление, следует указать одну из перечисленных доступных версий Kubernetes. Затем Azure безопасно заблокирует и остановит каждый узел AKS и выполнит обновление.

Блокировка и остановка

При обновлении узлы AKS в кластере по отдельности блокируются, чтобы на них не планировался запуск новых pod. Затем узлы останавливаются и обновляются, как показано ниже.

  1. В пуле узлов развертывается новый узел.
    • В этом узле выполняется последняя версия образа ОС и его исправления.
  2. Один из существующих узлов выбирается для обновления.
  3. Работа pod на этом узле корректно завершается и планируется в других узлах пула.
  4. Этот пустой узел затем удаляется из кластера AKS.
  5. Шаги 1–4 повторяются до тех пор, пока все узлы не будут успешно заменены в рамках процесса обновления.

Дополнительные сведения см. в статье Обновление кластера службы Azure Kubernetes (AKS).

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

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

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

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

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

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

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

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

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

Секреты Kubernetes

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

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

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

Примечание

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

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

Дальнейшие действия

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

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

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