Confidential Containers меняют модель безопасности Kubernetes: защита данных в использовании (data in use) без доверия к платформе и администраторам.
Проблема проявляется не на уровне сетевой изоляции или RBAC. Она глубже — в доверии к самой среде выполнения. В классическом Kubernetes предполагается, что администраторы кластера и инфраструктура заслуживают доверия. Но при работе с чувствительными данными, особенно в AI workloads, это допущение ломается. Данные могут быть защищены “на диске” и “в транзите”, но остаются уязвимыми “в использовании” (data in use), то есть в памяти приложения. Это становится узким местом для сценариев с требованиями data sovereignty и zero trust.
Решение, которое формируется в индустрии, — confidential computing. В контексте Kubernetes это реализуется через Confidential Containers. Подход строится вокруг идеи: не доверять ни платформе, ни Kubernetes-администраторам, ни даже хосту. Вместо этого система проверяет целостность окружения через attestation перед тем, как предоставить доступ к секретам. Это компромисс между безопасностью и операционной сложностью. Мы получаем более строгую модель доверия, но платим усложнением стека: появляется зависимость от TEE (trusted execution environment), дополнительных сервисов и цепочки верификации.
Реализация в OpenShift показывает, как эта модель приземляется на практике. Архитектура разделяет роли и кластеры: есть “trusted” среда, где работает сервис Trustee, и “untrusted” кластер, где запускаются сами confidential workloads. Это разделение не случайно — оно снижает blast radius и фиксирует границы доверия. Установка начинается с операторов и конфигурации, при этом кластер намеренно разворачивается без предустановленных компонентов. Такой подход помогает явно увидеть зависимости и контрольные точки системы.
Дальше — самое интересное: поведение приложений. Базовый сценарий — “blackbox deployment”. Контейнер с AI workload (например, fraud detection) запускается без изменений, но получает дополнительный слой защиты — шифрование памяти. С точки зрения Kubernetes-ресурсов ничего не меняется. Это важный момент: Confidential Containers не требуют переписывания приложения. Они меняют среду исполнения.
Следующий уровень — работа с внешними данными. В традиционной модели pod загружает зашифрованный датасет и получает ключ дешифрования через init-контейнер или секреты кластера. Это означает, что доступ к ключу потенциально есть у администраторов. В модели confidential containers добавляется TEE-стек и сервис Trustee. Ключ выдается только после успешной attestation. Если среда скомпрометирована или не соответствует ожидаемому состоянию — ключ не будет передан. Это смещает контроль с Kubernetes на криптографически проверяемую цепочку доверия.
Еще один сценарий — sealed secrets. В обычном Kubernetes секреты доступны через API и могут быть извлечены при наличии прав. В confidential containers используется механизм, при котором секрет фактически не хранится в кластере в открытом виде. Он подставляется во время старта контейнера после проверки окружения через Trustee. Этот процесс инициируется компонентами внутри гостевой Linux-среды контейнера. В результате секрет существует только внутри доверенной execution boundary.
Что в итоге меняется? Уровень изоляции становится ближе к виртуальным машинам, но сохраняется модель контейнеров. Это компромиссное решение между безопасностью и удобством orchestration. Метрики производительности или latency в исходном материале не приводятся, поэтому оценить накладные расходы невозможно. Но архитектурно очевидно: добавление TEE и attestation увеличивает сложность и потенциально влияет на startup time и throughput.
Практическая ценность подхода — в снижении доверия к инфраструктуре. Это особенно актуально для hybrid cloud и edge-сценариев, где контроль над средой ограничен. При этом tooling, такой как Red Hat Demo Platform, снижает барьер входа: готовая инфраструктура позволяет изучить поведение системы без сборки кластера с нуля. Это делает технологию более доступной, но не убирает её фундаментальную сложность.
Confidential Containers — это не “просто еще один runtime”. Это сдвиг в модели доверия Kubernetes. И как любой сдвиг, он требует пересмотра привычных предположений о том, где именно заканчивается контроль и начинается риск.