Блокировка доступа pod к конечной точке службы метаданных экземпляра Azure (IMDS) (предварительная версия)

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

Внимание

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

Сведения об ограничении IMDS для кластеров AKS

Azure IMDS — это REST API, предоставляющий сведения о текущих экземплярах виртуальных машин. Сюда входят сведения о номере SKU, хранилище, конфигурации сети и ближайших мероприятиях по обслуживанию.

REST API IMDS доступен по известному нераутируемому IP-адресу (169.254.169.254), который по умолчанию доступен из всех pod, работающих в кластере AKS. Этот доступ по умолчанию представляет определенные риски безопасности для кластера AKS:

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

Теперь вы можете ограничить доступ к конечной точке IMDS для подов, не принадлежащих к сети хоста, работающих в вашем кластере. Контейнеры, подключенные к сети и не являющиеся узловыми, имеют hostNetwork значение false в своих спецификациях. Если ограничение IMDS включено, pods, не относящиеся к хост-сети, не могут получить доступ к конечной точке IMDS или получить токены OAuth 2.0 для авторизации управляемой идентичностью. Модули сети, не являющиеся хостами, должны полагаться на Идентификатор рабочей нагрузки Microsoft Entra после включения ограничения доступа к IMDS.

Сетевые модули pod узла имеют hostNetwork значение true в своих спецификациях. После включения ограничений IMDS сетевые pod узлы могут продолжать получать доступ к конечной точке IMDS, так как они совместно используют одно и то же сетевое пространство имен с процессами узлов. Локальные процессы в узлах могут использовать конечную точку IMDS для получения метаданных экземпляра, поэтому они могут получить доступ к конечной точке после включения ограничения IMDS.

Прежде чем начать

  1. Убедитесь, что установлен Azure CLI версии 2.61.0 или более поздней. Чтобы узнать версию, выполните команду az --version. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.

  2. aks-preview Установите расширение Azure CLI версии 7.0.0b2 или более поздней версии.

    • Если у вас еще нет aks-preview расширения, установите его с помощью az extension add команды.

      az extension add --name aks-preview
      
    • Если у вас уже есть aks-preview расширение, обновите его, чтобы убедиться, что у вас установлена последняя версия с помощью az extension update команды.

      az extension update --name aks-preview
      
  3. IMDSRestrictionPreview Зарегистрируйте флаг компонента с помощью команды az feature register.

    az feature register --namespace Microsoft.ContainerService --name IMDSRestrictionPreview
    

    Проверьте состояние регистрации с помощью команды az feature show . Для отображения статуса зарегистрирован потребуется несколько минут.

    az feature show --namespace Microsoft.ContainerService --name IMDSRestrictionPreview
    

    Когда состояние отражает "Зарегистрировано", обновите регистрацию поставщика ресурсов Microsoft.ContainerService с помощью команды az provider register:

    az provider register --namespace Microsoft.ContainerService
    
  4. Включите издателя OIDC в кластере AKS. Сведения о создании кластера или обновлении существующего кластера см. в статье "Настройка кластера AKS с помощью издателя OIDC".

Ограничения

Некоторые дополнения, которым требуется доступ к конечной точке IMDS, не поддерживаются с ограничением IMDS. Если в кластере установлены эти надстройки, вы не можете включить ограничение IMDS. И наоборот, если включено ограничение IMDS, вы не можете установить эти надстройки. К неподдерживаемым дополнениям относятся:

  • Контроллер входящего трафика шлюза приложений
  • Azure Monitor для контейнеров (аналитика для контейнеров)
  • Виртуальные узлы
  • Политика Azure
  • Расширения кластера: Flux (GitOps), Dapr, Конфигурация приложений Azure, Машинное обучение Azure, хранилище контейнеров Azure, Azure Backup
  • Оператор цепочки инструментов ИИ (предварительная версия)
  • Маршрутизация приложений
  • Маршрутизация приложений HTTP
  • Маршрутизация веб-приложений
  • Анализ затрат Azure

Поставщик Azure Key Vault для драйвера Secrets Store CSI теперь поддерживает режим аутентификации с идентификацией рабочих нагрузок и, следовательно, может работать с включенным ограничением IMDS.

Кроме того, пулы узлов Windows в настоящее время не поддерживаются с ограничением IMDS.

Внимание

Включение ограничений IMDS для кластера, использующего неподдерживаемые надстройки, приводит к ошибке.

Важные замечания

Если ограничение IMDS включено, AKS управляет правилами iptables на узле. Имейте в виду следующие моменты, чтобы предотвратить случайное удаление или изменение правил iptables:

  • Правила iptables можно изменить с помощью SSH или node-shell, поэтому рекомендуется отключить SSH или использовать политику для отключения привилегированных подов.
  • Правила iptables, ограничивающие доступ к IMDS, восстанавливаются при повторном переименовыи или перезапуске узла.

Включение ограничения IMDS для нового кластера

Чтобы включить ограничение IMDS для нового кластера и заблокировать весь трафик от pod'ов, не использующих сеть узла, к точке доступа IMDS, выполните az aks create команду с параметром --enable-imds-restriction.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --enable-imds-restriction

Включение ограничения IMDS для существующего кластера

Чтобы включить ограничение IMDS в существующем кластере и заблокировать весь трафик от подов, не относящихся к узловой сети, к конечной точке IMDS, выполните команду az aks update с параметром --enable-imds-restriction.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --enable-imds-restriction

После обновления кластера необходимо перепрошить узлы в кластере с помощью az aks upgrade --node-image-only, чтобы начать блокировать трафик к pod кластера.

Проверка трафика в кластере с включенным ограничением IMDS

Чтобы убедиться, что ограничение IMDS действует, проверьте трафик как для pods вне узла, так и для pods сети узла.

Проверка трафика в модуле pod сети, отличной от узла

  1. Создайте модуль pod с hostNetwork: false. Если у вас нет тестового контейнера hostNetwork: false, можно выполнить следующую команду, чтобы создать его.

    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    kind: Pod
    metadata:
         name: non-host-nw
    spec:
      hostNetwork: false
      containers:
      - name: non-host-nw
        image: mcr.microsoft.com/azurelinux/base/nginx:1
        command: ["sleep", "infinity"]
    EOF
    
  2. Подключитесь к оболочке в модуле pod с помощью kubectl exec.

    kubectl exec -it non-host-nw -- /bin/bash
    
  3. Проверьте трафик от pod до конечной точки IMDS.

    curl -s -H Metadata:true --connect-timeout 10 --noproxy "*" "http://169.254.169.254/metadata/instance?api-version=2023-11-15" 
    

Подождите около 10 секунд и обратите внимание, что команда не возвращает ничего, что означает, что время ожидания подключения истекло, и модуль pod не может получить доступ к конечной точке IMDS.

После этого очистите модуль pod с помощью kubectl delete pod non-host-nw.

Проверьте трафик на поде сети узла

  1. Создайте модуль pod с hostNetwork: true. Если у вас нет тестового контейнера hostNetwork: true, можно выполнить следующую команду, чтобы создать его.

    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    kind: Pod
    metadata:
      name: host-nw
    spec:
      hostNetwork: true
      containers:
      - name: host-nw
        image: mcr.microsoft.com/azurelinux/base/nginx:1
        command: ["sleep", "infinity"]
    EOF
    
  2. Подключитесь к оболочке в модуле pod с помощью kubectl exec.

    kubectl exec -it host-nw -- /bin/bash
    
  3. Тестирование трафика от пода к конечной точке IMDS

    curl -s -H Metadata:true --noproxy "*" "http://169.254.169.254/metadata/instance?api-version=2023-11-15" 
    

Обратите внимание, что команда возвращает результаты, что означает, что модуль pod может получить доступ к конечным точкам IMDS, как ожидалось.

После этого очистите модуль pod с помощью kubectl delete pod host-nw.

Отключение ограничения IMDS для кластера

Чтобы отключить ограничение IMDS в существующем кластере и разрешить весь трафик от любых pods к конечной точке IMDS, выполните команду az aks update с параметром --disable-imds-restriction.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --disable-imds-restriction

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

См. также

Служба метаданных экземпляра Azure для виртуальных машин