Политика безопасности для конфиденциальных контейнеров в Служба Azure Kubernetes
Как описано консорциумом конфиденциальных вычислений (CCC), "Конфиденциальные вычисления — это защита используемых данных путем выполнения вычислений в аппаратной среде доверенного выполнения (TEE). Конфиденциальные контейнеры AKS предназначены для защиты данных pod Kubernetes, используемых из-за пределов этих модулей. Каждый модуль pod выполняется в конфиденциальной виртуальной машине (CVM), защищенной TEE AMD SEV-SNP путем шифрования данных в использовании и предотвращения доступа к данным операционной системой узла (ОС). Инженеры Майкрософт сотрудничали с конфиденциальными контейнерами (CoCo) и сообществами с открытым исходным кодом Kata Containers по проектированию и реализации конфиденциальных контейнеров.
Общие сведения о политике безопасности
Одним из основных компонентов архитектуры системы Kata Containers является агент Kata. При использовании контейнеров Kata для реализации конфиденциальных контейнеров агент выполняется внутри аппаратной среды TEE и поэтому является частью доверенной вычислительной базы pod (TCB). Как показано на следующей схеме, агент Kata предоставляет набор API ttrpc , позволяющий системным компонентам за пределами TEE создавать модули Kubernetes на основе CVM и управлять ими. Эти другие компоненты (например, Kata Shim) не являются частью TCB pod. Поэтому агент должен защитить себя от потенциально ошибок или вредоносных вызовов API.
В конфиденциальных контейнерах AKS API агента Kata реализуется с помощью политики безопасности (также известной как политика агента Kata), указанной владельцами конфиденциальных модулей pod. Документ политики содержит правила и данные, соответствующие каждому модулем pod, используя стандартный язык политики Rego в отрасли. Принудительное применение политики внутри CVM реализуется с помощью агента Open Policy (OPA) — выпускника проекта Cloud Native Computing Foundation (CNCF).
Содержимое политики
Политика безопасности описывает все вызовы API ttrpc агента (и параметры этих вызовов API), ожидаемые для создания и управления конфиденциальным модулем pod. Документ политики каждого модуля pod — это текстовый файл с помощью языка Rego. В документе политики есть три высокоуровневых раздела.
Data
Данные политики зависят от каждого модуля pod. Он содержит, например:
- Список контейнеров, которые должны быть созданы в модуле pod.
- Список API-интерфейсов, заблокированных политикой по умолчанию (по соображениям конфиденциальности).
Примеры данных, включенных в документ политики для каждого контейнера в модуле pod:
- Сведения о целостности изображения.
- Команды, выполняемые в контейнере.
- служба хранилища тома и подключения.
- Контекст безопасности выполнения. Например, является ли корневая файловая система доступной только для чтения?
- Разрешен ли процесс получить новые привилегии?
- среды.
- Другие поля из конфигурации среды выполнения контейнера Open Container Initiative (OCI).
Правила
Правила политики, указанные в формате Rego, выполняются OPA для каждого вызова API агента Kata за пределами CVM. Агент предоставляет все входные данные API для OPA, а OPA использует правила для проверка если входные данные соответствуют данным политики. Если правила политики и данные не допускают входные данные API, агент отклоняет вызов API, возвращая сообщение об ошибке "заблокировано политикой". Ниже приведены некоторые примеры правил:
- Каждый слой контейнера предоставляется как устройство, доступное только для чтения virtio, для CVM. Целостность этих блочных устройств защищена с помощью технологии dm-verity ядра Linux. Ожидаемое корневое значение дерева хэша dm-verity включается в данные политики и проверяется во время выполнения правилами политики.
- Правила отклоняют создание контейнера при обнаружении неожиданной командной строки, подключения хранилища, контекста безопасности выполнения или переменной среды.
По умолчанию правила политики являются общими для всех модулей pod. Средство genpolicy создает данные политики и зависит от каждого модуля pod.
Значения по умолчанию
При оценке правил Rego с помощью данных политики и входных данных API в качестве параметров OPA пытается найти по крайней мере один набор правил, возвращающий true значение на основе входных данных. Если правила не возвращаются true, OPA возвращает агенту значение по умолчанию для этого API. Примеры значений по умолчанию из политики:
default CreateContainerRequest := false— означает, что любой вызов API CreateContainer отклоняется, если набор правил политики явно не разрешает этот вызов.default GuestDetailsRequest := true— означает, что вызовы извне TEE к API GuestDetails всегда разрешены, так как данные, возвращаемые этим API, не учитывает конфиденциальность рабочих нагрузок клиента.
Отправка политики агенту Kata
Все конфиденциальные контейнеры AKS запускают с помощью универсальной политики по умолчанию, включенной в корневую файловую систему CVMs. Таким образом, политика, соответствующая фактической рабочей нагрузке клиента, должна быть предоставлена агенту во время выполнения. Текст политики внедрен в файл манифеста YAML, как описано ранее, и предоставляется таким образом агенту рано во время инициализации CVM. Заметка политики проходит через компоненты kubelet, контейнеры и компоненты Kata shim в системе конфиденциальных контейнеров AKS. Затем агент, работающий вместе с OPA, применяет политику для всех вызовов собственных API.
Политика предоставляется с помощью компонентов, которые не являются частью TCB, поэтому изначально эта политика не является доверенной. Надежность политики должна быть создана с помощью удаленной аттестации, как описано в следующем разделе.
Установка доверия к документу политики
Перед созданием pod CVM ката вычисляет хэш SHA256 документа политики и присоединяет это хэш-значение к TEE. Это действие создает сильную привязку между содержимым политики и CVM. Это поле TEE не изменяется позже программным обеспечением, выполняемым внутри CVM, или вне него.
После получения политики агент проверяет хэш политики в неизменяемом поле TEE. Агент отклоняет входящую политику, если обнаруживает хэш-несоответствие.
Перед обработкой конфиденциальной информации рабочие нагрузки должны выполнить шаги удаленной аттестации, чтобы доказать любой проверяющей стороне, что рабочая нагрузка выполняется с помощью ожидаемых версий TEE, ОС, агента, OPA и корневой файловой системы. Аттестация реализована в контейнере, работающем внутри CVM, который получает подписанные доказательства аттестации от оборудования AMD SEV-SNP. Одним из полей подтверждения аттестации является поле teE политики, описанное ранее. Поэтому служба аттестации может проверить целостность политики, сравнивая значение этого поля с ожидаемым хэшом политики pod.
Применение политики
Агент Ката несет ответственность за применение политики. Корпорация Майкрософт внесла свой вклад в сообщество Kata и CoCo код агента, отвечающий за проверка политику для каждого вызова API ttrpc агента. Перед выполнением действий, соответствующих API, агент использует REST API OPA для проверка, если правила политики и данные разрешают или блокируют вызов.