Конфиденциальные контейнеры (предварительная версия) со службой 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).
• Анализ моделей машинного обучения и обучение моделей машинного обучения с использованием зашифрованного набора данных из надежного источника. Он расшифровывается только в конфиденциальной среде контейнера, чтобы сохранить конфиденциальность.
• Создание чистых комнат для обработки больших данных для идентификации в рамках многопользовательских вычислений в таких отраслях, как розничная торговля с цифровой рекламой.
• Создание зон размещения в облаке на основе нулевого доверия для конфиденциальных вычислений, чтобы обеспечить соблюдение правил конфиденциальности при миграции приложений в облако.

Considerations

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

• Увеличение времени запуска контейнеров pod по сравнению с контейнерами pod, работающими на runc, и контейнерами, изолированными на уровне ядра.
• Образы контейнеров версии 1 не поддерживаются.
• Временные контейнеры и другие методы устранения неполадок, такие как вход в контейнер exec, журнальные данные контейнеров, и stdio требуют изменения политики и повторного развертывания, чтобы включить ExecProcessRequest, ReadStreamRequest, WriteStreamRequest и CloseStdinRequest.
• Из-за измерений уровня образов контейнера, закодированных в политике безопасности, при указании контейнеров не рекомендуется использовать latest тег.
• Службы, Балансировщики нагрузки и EndpointSlices поддерживают только протокол TCP.
• Генератор политик поддерживает только podы, использующие IPv4-адреса.
• Переменные среды Pod, которые основаны на ConfigMaps и Secrets, нельзя изменить после развертывания Pod.
• Журналы завершения Pod не поддерживаются. Хотя pod записывают журналы завершения в /dev/termination-log или в заданное расположение, если так указано в манифесте pod, хост/кубелет не может считывать эти журналы. Изменения из модуля pod в этот файл не отражаются на узле.
• Конфиденциальные контейнеры в настоящее время поддерживают только Azure Linux.

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

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

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

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

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

Дальнейшие шаги

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