Directiva de seguridad para contenedores confidenciales en Azure Kubernetes Service
Tal y como se describe en Confidential Computing Consortium (CCC), "Confidential Computing es la protección de los datos en uso mediante el cálculo en un entorno de ejecución de confianza (TEE) basado en hardware y atestiguado". Los contenedores confidenciales de AKS están diseñados para proteger los datos de pods de Kubernetes en uso frente al acceso no autorizado desde fuera de estos pods. Cada pod se ejecuta en una máquina virtual confidencial (CVM) protegida por el TEE de AMD SEV-SNP mediante el cifrado de datos en uso e impedir el acceso a los datos por parte del sistema operativo host (OS). Los ingenieros de Microsoft colaboraron con las comunidades de código abierto Contenedores confidenciales (CoCo) y Kata Containers en el diseño e implementación de los contenedores confidenciales.
Introducción a las directivas de seguridad
Uno de los componentes principales de la arquitectura del sistema Kata Containers es el agente kata. Cuando se usan contenedores kata para implementar contenedores confidenciales, el agente se ejecuta dentro del TEE basado en hardware y, por tanto, forma parte de la base de computación segura (TCB) del pod. Como se muestra en el diagrama siguiente, el agente kata proporciona un conjunto de API de ttrpc que permiten a los componentes del sistema fuera del TEE crear y administrar pods de Kubernetes basados en CVM. Estos otros componentes (por ejemplo, la Shim kata) no forman parte del TCB del pod. Por lo tanto, el agente debe protegerse de llamadas API malintencionadas o potencialmente malintencionadas.
En los contenedores confidenciales de AKS, la autoprotección de la API del agente kata se implementa mediante una directiva de seguridad (también conocida como directiva de agente kata), especificada por los propietarios de los pods confidenciales. El documento de directiva contiene reglas y datos correspondientes a cada pod mediante el lenguaje de directiva Rego estándar del sector. La aplicación de la directiva dentro del CVM se implementa mediante open Policy Agent (OPA), un proyecto graduado de Cloud Native Computing Foundation (CNCF).
Contenido de la directiva
La directiva de seguridad describe todas las llamadas a las API ttrpc del agente (y los parámetros de estas llamadas API) que se esperan para crear y administrar el pod Confidencial. El documento de directiva de cada pod es un archivo de texto, mediante el idioma Rego. Hay tres secciones de alto nivel del documento de directiva.
Data
Los datos de directiva son específicos de cada pod. Contiene, por ejemplo:
- Se espera que se cree una lista de contenedores en el pod.
- Lista de API bloqueadas por la directiva de forma predeterminada (por motivos de confidencialidad).
Ejemplos de datos incluidos en el documento de directiva para cada uno de los contenedores de un pod:
- Información de integridad de la imagen.
- Comandos ejecutados en el contenedor.
- Volúmenes de almacenamiento y montajes.
- Contexto de seguridad de ejecución. Por ejemplo, ¿es el sistema de archivos raíz de solo lectura?
- ¿Se permite el proceso para obtener nuevos privilegios?
- Variables de entorno.
- Otros campos de la configuración del entorno de ejecución del contenedor Open Container Initiative (OCI).
Reglas
Las reglas de directiva, especificadas en formato Rego, se ejecutan mediante OPA para cada llamada api del agente kata desde fuera del CVM. El agente proporciona todas las entradas de API a OPA y OPA usa las reglas para comprobar si las entradas son coherentes con los datos de directiva. Si las reglas de directiva y los datos no permiten entradas de API, el agente rechaza la llamada API devolviendo un mensaje de error "bloqueado por directiva". Estos son algunos ejemplos de reglas:
- Cada capa de contenedor se expone como un dispositivo de bloque virtio de solo lectura al CVM. La integridad de esos dispositivos de bloque está protegida mediante la tecnología dm-verity del kernel de Linux. El valor raíz esperado del árbol hash dm-verity se incluye en los datos de la directiva y se comprueba en tiempo de ejecución mediante las reglas de directiva.
- Las reglas rechazan la creación de contenedores cuando se detecta una línea de comandos inesperada, un montaje de almacenamiento, un contexto de seguridad de ejecución o una variable de entorno.
De forma predeterminada, las reglas de directiva son comunes a todos los pods. La herramienta genpolicy genera los datos de directiva y es específico de cada pod.
Valores predeterminados
Al evaluar las reglas de Rego mediante los datos de directiva y las entradas de API como parámetros, OPA intenta encontrar al menos un conjunto de reglas que devuelve un true valor basado en los datos de entrada. Si las reglas no devuelven true, OPA devuelve al agente el valor predeterminado de esa API. Ejemplos de valores predeterminados de la directiva:
default CreateContainerRequest := false: significa que se rechaza cualquier llamada API de CreateContainer a menos que un conjunto de reglas de directiva permita explícitamente esa llamada.default GuestDetailsRequest := true: significa que las llamadas desde fuera del TEE a la API GuestDetails siempre se permiten porque los datos devueltos por esta API no son confidenciales para la confidencialidad de las cargas de trabajo del cliente.
Envío de la directiva al agente kata
Todos los CVM de contenedores confidenciales de AKS empiezan a usar una directiva genérica predeterminada incluida en el sistema de archivos raíz de LOS CVM. Por lo tanto, se debe proporcionar una directiva que coincida con la carga de trabajo del cliente real al agente en tiempo de ejecución. El texto de la directiva se inserta en el archivo de manifiesto YAML como se ha descrito anteriormente y se proporciona de esta manera al agente al principio durante la inicialización de CVM. La anotación de directiva viaja a través de los componentes kubelet, en contenedores y correcciones de compatibilidad kata del sistema de contenedores confidenciales de AKS. A continuación, el agente que trabaja junto con OPA aplica la directiva para todas las llamadas a sus propias API.
La directiva se proporciona mediante componentes que no forman parte del TCB, por lo que inicialmente esta directiva no es de confianza. La confiabilidad de la directiva debe establecerse a través de la atestación remota, como se describe en la sección siguiente.
Establecimiento de confianza en el documento de directiva
Antes de crear el CVM de pod, la corrección de compatibilidad kata calcula el hash SHA256 del documento de directiva y adjunta ese valor hash al TEE. Esa acción crea un enlace seguro entre el contenido de la directiva y el CVM. Este campo TEE no es modificable más adelante por el software ejecutado dentro del CVM o fuera de él.
Al recibir la directiva, el agente comprueba el hash de la directiva coincide con el campo TEE inmutable. El agente rechaza la directiva entrante si detecta un error de coincidencia de hash.
Antes de controlar la información confidencial, las cargas de trabajo deben realizar pasos de atestación remota para demostrar a cualquier usuario de confianza que se ejecute la carga de trabajo con las versiones esperadas del SISTEMA de archivos TEE, OS, agent, OPA y root file system. La atestación se implementa en un contenedor que se ejecuta dentro del CVM que obtiene evidencias de atestación firmadas del hardware AMD SEV-SNP. Uno de los campos de la evidencia de atestación es el campo TEE hash de directiva descrito anteriormente. Por lo tanto, el servicio de atestación puede comprobar la integridad de la directiva comparando el valor de este campo con el hash esperado de la directiva de pod.
Aplicación de directivas
El agente kata es responsable de aplicar la directiva. Microsoft contribuyó a la comunidad Kata y CoCo, el código del agente responsable de comprobar la directiva de cada llamada a la API de ttrpc del agente. Antes de llevar a cabo las acciones correspondientes a la API, el agente usa la API REST de OPA para comprobar si las reglas de directiva y los datos permiten o bloquean la llamada.