Рекомендации по защите групп pod в Службе контейнеров Azure (AKS)

В процессе разработки и выполнения приложений в службе контейнеров Azure (AKS) важно не забывать о безопасности групп pod. Необходимо разработать приложения за принципом минимального количества требуемых привилегий. Защита личных данных играет важнейшую роль для клиентов. Вы вряд ли захотите, чтобы учетные данные, например строки подключения к базам данных, ключи, секреты и сертификаты свободно предоставлялись внешнему миру, где злоумышленники могут использовать их в злонамеренных целях. Не добавляйте учетные данные в код и не внедряйте в образы контейнеров. Такой подход создает риск компрометации и снижает возможность замены учетных данных, так как для этого придется перестраивать образы контейнеров.

Это статья с рекомендациями посвящена защите групп pod в среде AKS. Узнайте следующие темы:

• использование контекста безопасности групп pod для ограничения доступа к процессам и службам или повышения привилегий;
• Проверка подлинности с помощью других ресурсов Azure с помощью Идентификация рабочей нагрузки Microsoft Entra
• запрос и получение учетных данных из цифрового хранилища, например Azure Key Vault.

Вы также можете изучить рекомендации по безопасности кластера и управлению образами контейнеров.

Защита доступа групп pod к ресурсам

Наилучший вариант. Определите параметры безопасности групп pod, чтобы выполнять их от имени другого пользователя (или группы) и ограничить доступ к процессам и службам базового узла. Назначайте минимальное число требуемых привилегий.

Чтобы приложения работали правильно, группы pod следует выполнять от имени определенного пользователя или группы, но не от имени привилегированного пользователя. securityContext для группы pod или контейнера позволяет определить такие параметры, как runAsUser или fsGroup, чтобы предоставить соответствующие разрешения. Назначайте только необходимые разрешения для пользователя или группы и не используйте контекст безопасности для предоставления дополнительных разрешений. runAsUser, повышение привилегий и другие параметры Linux доступны только на узлах Linux и в группах pod.

При выполнении от имени непривилегированного пользователя нельзя привязать контейнеры к привилегированным портам (с номерами менее 1024). В таком сценарии можно скрыть порт, на котором работает приложение, с помощью Службы контейнеров.

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

• allowPrivilegeEscalation определяет, может ли группа pod принимать привилегии привилегированного пользователя. Приложения следует разрабатывать так, чтобы этот параметр всегда имел значение false.
• Возможности Linux разрешают группам pod обращаться к процессам базового узла. Соблюдайте осторожность при назначении таких возможностей. Назначайте минимальное число требуемых привилегий. См. дополнительные сведения о возможностях Linux.
• Метки SELinux — это модуль безопасности ядра Linux, который позволяет задать политики доступа для служб, процессов и файловой системы. Как и прежде, назначайте минимальное число требуемых привилегий. Дополнительные сведения см. в описании параметров SELinux в Kubernetes.

Следующий пример манифеста YAML для групп pod настраивает следующие параметры контекста безопасности:

• группа pod выполняется как идентификатор пользователя 1000 и относится к группе с идентификатором 2000;
• повысить привилегии для использования root нельзя;
• разрешаются возможности Linux для доступа к сетевым интерфейсам и аппаратным часам реального времени на узле.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    fsGroup: 2000
  containers:
    - name: security-context-demo
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      securityContext:
        runAsUser: 1000
        allowPrivilegeEscalation: false
        capabilities:
          add: ["NET_ADMIN", "SYS_TIME"]

Согласуйте с оператором кластера, какие параметры контекста безопасности вам необходимы. Старайтесь спроектировать приложения так, чтобы свести к минимуму требования группы pod к дополнительным разрешениям и правам доступа. Есть несколько дополнительных функций, позволяющих ограничить доступ с помощью AppArmor и seccomp (безопасные вычисления), которые может реализовать оператор кластера. Дополнительные сведения см. в руководстве по защите доступа контейнера к ресурсам.

Ограничение уязвимости учетных данных

Наилучший вариант. Не определяйте учетные данные в коде приложения. Используйте управляемые удостоверения ресурсов Azure, чтобы позволить группе pod запрашивать доступ к другим ресурсам. Кроме того, для хранения и извлечения цифровых ключей и учетных данных следует применить цифровое хранилище, например Azure Key Vault. Управляемые pod удостоверения предназначены только для использования с модулями pod Linux и образами контейнеров.

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

Использование Идентификация рабочей нагрузки Microsoft Entra

Удостоверение рабочей нагрузки — это удостоверение, используемое приложением, работающим в модуле pod, которое может пройти проверку подлинности в других службах Azure, которые поддерживают его, например хранилище или SQL. Он интегрируется с возможностями, собственными для Kubernetes, для федерации с внешними поставщиками удостоверений. В этой модели безопасности кластер AKS выступает в качестве издателя токенов, идентификатор Microsoft Entra использует OpenID Connect для обнаружения открытых ключей подписывания и проверки подлинности маркера учетной записи службы перед обменом его на токен Microsoft Entra. Рабочая нагрузка может обмениваться маркером учетной записи службы, проецируемым на его том, для маркера Microsoft Entra с помощью клиентской библиотеки удостоверений Azure с помощью пакета SDK Azure или библиотеки проверки подлинности Майкрософт (MSAL).

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

Использование Azure Key Vault с драйвером Secrets Store CSI

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

Когда приложениям требуются учетные данные, они обращаются в цифровое хранилище и получают последнюю версию секретных данных, а затем подключаются к нужной службе. В качестве цифрового хранилища можно использовать Azure Key Vault. На следующей схеме показан упрощенный рабочий процесс извлечения учетных данных из Azure Key Vault с использованием управляемых удостоверений группы pod:

Key Vault позволяет хранить и регулярно менять секреты, в том числе учетные данные, ключи учетной записи хранения или сертификаты. Вы можете интегрировать Azure Key Vault в кластер AKS при помощи поставщика услуг Azure Key Vault для драйвера Secrets Store CSI. Драйвер Secrets Store CSI позволяет кластеру AKS собственными средствами получать секретные данные из Key Vault и безопасно предоставлять их только запрашивающей группе pod. Обратитесь к оператору кластера, чтобы развернуть драйвер Secrets Store CSI на рабочих узлах AKS. Вы можете использовать Идентификация рабочей нагрузки Microsoft Entra для запроса доступа к Key Vault и получения содержимого секрета, необходимого с помощью драйвера CSI хранилища секретов.

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

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

• Использование Идентификация рабочей нагрузки Microsoft Entra для ресурсов Azure с AKS
• Интеграция Azure Key Vault с AKS