Конфиденциальные контейнеры (предварительная версия) с Служба Azure Kubernetes (AKS)

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

Конфиденциальные контейнеры создаются на основе конфиденциальных контейнеров Kata и аппаратного шифрования для шифрования памяти контейнера. Он устанавливает новый уровень конфиденциальности данных, предотвращая данные в памяти во время вычислений в виде четкого текста, доступного для чтения. Доверие зарабатывается в контейнере с помощью аппаратной аттестации, позволяя получить доступ к зашифрованным данным доверенных сущностей.

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

• Прозрачность: конфиденциальная среда контейнера, в которой предоставлен общий доступ к конфиденциальному приложению, вы можете увидеть и проверить, безопасно ли это. Все компоненты доверенной вычислительной базы (TCB) должны быть открытый код.
• Возможность аудита. У вас есть возможность проверить и узнать, какая версия пакета среды CoCo, включая гостевую ОС Linux, и все компоненты являются текущими. Корпорация Майкрософт подписывается на гостевую ОС и среду выполнения контейнера для проверки с помощью аттестации. Он также выпускает безопасный хэш-алгоритм (SHA) гостевой ОС сборки для создания строковой звуковой системы и истории управления.
• Полная аттестация: все, что является частью TEE, должно быть полностью измерено ЦП с возможностью удаленной проверки. Аппаратный отчет процессора AMD SEV-SNP должен отражать уровни контейнеров и хэш конфигурации среды выполнения контейнера через утверждения аттестации. Приложение может получить отчет оборудования локально, включая отчет, который отражает образ гостевой ОС и среду выполнения контейнера.
• Целостность кода. Принудительное применение среды выполнения всегда доступно с помощью определяемых клиентом политик для контейнеров и конфигурации контейнеров, таких как неизменяемые политики и подписывание контейнеров.
• Изоляция от оператора: проекты безопасности, предполагающие наименьшие привилегии и максимальную защиту изоляции от всех ненадежных сторон, включая администраторов клиента или клиента. Он включает обеспечение защиты существующего доступа к плоскости управления Kubernetes (kubelet) к конфиденциальным модулям pod.

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

В этой статье вы узнаете о функции конфиденциальных контейнеров, а также о том, как реализовать и настроить следующие компоненты:

• Развертывание или обновление кластера AKS с помощью Azure CLI
• Добавьте заметку в yamL pod, чтобы пометить модуль pod как выполняющийся в качестве конфиденциального контейнера
• Добавление политики безопасности в yamL pod
• Включение принудительного применения политики безопасности
• Развертывание приложения в конфиденциальных вычислениях

Поддерживаемые сценарии

Конфиденциальные контейнеры (предварительная версия) подходят для сценариев развертывания, включающих конфиденциальные данные. Например, личная информация (PII) или любые данные с строгой безопасностью, необходимой для соответствия нормативным требованиям. Ниже приведены некоторые распространенные сценарии с контейнерами:

• Запустите аналитику больших данных с помощью Apache Spark для распознавания шаблонов мошенничества в финансовом секторе.
• Запуск локальных GitHub runners для безопасного подписывания кода в рамках практики Непрерывной интеграции и непрерывного развертывания (CI/CD).
• Машинное обучение вывод и обучение моделей машинного обучения с использованием зашифрованного набора данных из надежного источника. Он расшифровывается только в конфиденциальной среде контейнера, чтобы сохранить конфиденциальность.
• Создание чистых помещений больших данных для сопоставления идентификаторов в рамках многопартийных вычислений в таких отраслях, как розничная торговля с цифровой рекламой.
• Создание целевых зон нулевого доверия конфиденциальных вычислений для соблюдения правил конфиденциальности для миграции приложений в облако.

Рекомендации

Ниже приведены рекомендации по использованию этой предварительной версии конфиденциальных контейнеров.

• Увеличение времени запуска pod по сравнению с модулями pod runc и изолированными ядрами pod.
• Образы контейнеров версии 1 не поддерживаются.
• Обновления секретов и ConfigMaps не отражаются в гостевом приложении.
• Временные контейнеры и другие методы устранения неполадок, такие как exec контейнер, выходные данные журналов из контейнеров и stdio (ReadStreamRequest и WriteStreamRequest) требуют изменения политики и повторного развертывания.
• Средство генератора политик не поддерживает типы развертывания cronjob.
• Из-за измерений уровня образов контейнера, закодированных в политике безопасности, при указании контейнеров не рекомендуется использовать latest тег.
• Службы, подсистемы балансировки нагрузки и конечные точки поддерживают только протокол TCP.
• Все контейнеры во всех модулях pod в кластерах должны быть настроены imagePullPolicy: Always.
• Генератор политик поддерживает только модули pod, использующие IPv4-адреса.
• Значения ConfigMap и секретов нельзя изменить, если параметр использует метод переменной среды после развертывания модуля pod. Политика безопасности предотвращает ее.
• Журналы завершения pod не поддерживаются. Хотя модули pod записывают журналы /dev/termination-log завершения в пользовательское расположение или в пользовательское расположение, если указано в манифесте pod, узел или kubelet не может считывать эти журналы. Изменения из гостевого файла в этот файл не отражаются на узле.

Общие сведения о выделении ресурсов

Важно понимать поведение выделения ресурсов памяти и процессора в этом выпуске.

• ЦП: схим назначает один виртуальный ЦП базовой ОС внутри модуля pod. Если ресурс limits не указан, рабочие нагрузки не имеют отдельных общих ресурсов ЦП, виртуальный ЦП затем будет совместно использоваться этой рабочей нагрузкой. Если указаны ограничения ЦП, общие ресурсы ЦП явно выделяются для рабочих нагрузок.
• Память. Обработчик Kata-CC использует 2 ГБ памяти для ОС UVM и X MB дополнительной памяти, где X является ресурсом limits , если указан в манифесте YAML (в результате 2 ГБ виртуальной машины не задано ограничение без неявной памяти для контейнеров). Обработчик Kata использует базовую память 256 МБ для ОС UVM и X MB, если ресурс limits указан в манифесте YAML. Если ограничения не определены, добавляется неявное ограничение в 1792 МБ, что приводит к 2 ГБ виртуальной машины и 1792 МБ неявной памяти для контейнеров.

В этом выпуске указание запросов ресурсов в манифестах pod не поддерживается. Контейнер Kata игнорирует запросы ресурсов из манифеста YAML pod, и в результате контейнер не передает запросы в оболочку. Используйте ресурс вместо ресурса limit requests , чтобы выделить ресурсы памяти или ЦП для рабочих нагрузок или контейнеров.

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

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

• Общие сведения о политике безопасности конфиденциальных контейнеров см. в статье о том, как рабочие нагрузки и их данные в модуле pod защищены.
• Развертывание конфиденциальных контейнеров в AKS с помощью политики безопасности по умолчанию.
• Дополнительные сведения о выделенных узлах Azure для узлов с кластером AKS для использования аппаратной изоляции и контроля за событиями обслуживания платформы Azure.