Рекомендации по защите podов в Службе Kubernetes Azure (АКС)

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

Эта статья с лучшими практиками посвящена защите подов в среде AKS. Вы узнаете, как:

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

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

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

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

При выполнении от имени непривилегированного пользователя нельзя привязать контейнеры к привилегированным портам (с номерами менее 1024). В этом сценарии службы Kubernetes могут быть использованы для скрытия того факта, что приложение работает на определённом порту.

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

• allowPrivilegeEscalation определяет, может ли группа pod принимать привилегии привилегированного пользователя. Приложения следует разрабатывать так, чтобы этот параметр всегда имел значение false.
• Возможности Linux позволяют подам получать доступ к процессам узла. Соблюдайте осторожность при назначении таких возможностей. Назначайте минимальное число требуемых привилегий. См. дополнительные сведения о возможностях 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 и образами контейнеров.

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

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

Удостоверение рабочей нагрузки — это удостоверение, используемое приложением, работающим в поде, которое может пройти проверку подлинности в других службах Azure, поддерживающих его, например, таких как "Хранилище" или SQL. Он интегрируется с возможностями Kubernetes в целях интеграции с внешними поставщиками удостоверений. В этой модели безопасности кластер AKS выступает в качестве издателя токенов, Microsoft Entra ID использует OpenID Connect для обнаружения открытых ключей подписывания и проверки подлинности токена учетной записи службы перед его обменом на токен Microsoft Entra. Рабочая нагрузка может обменять токен учетной записи службы, проецируемый на его том, на токен Microsoft Entra с помощью клиентской библиотеки Azure Identity, используя Azure SDK или библиотеку Microsoft Authentication Library (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 драйвер хранилища секретов.

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

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

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