Directiva de seguridad para contenedores confidenciales en Azure Kubernetes Service
Tal y como describe el Consorcio de Informática Confidencial (CCC), "La informática confidencial es la protección de los datos en uso mediante la realización de cálculos en un entorno de ejecución de confianza (TEE) certificado y basado en hardware". 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 de la utilidad (UVM) protegida por el AMD SEV-SNP TEE cifrando los datos en uso y evitando el acceso a los datos por parte del sistema operativo host (SO). Los ingenieros de Microsoft colaboraron con las comunidades de código abierto Confidential Containers (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 de Kata Containers es el agente Kata. Cuando se usan Kata Containers 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 las API ttrpc que permiten a los componentes del sistema fuera del TEE crear y administrar pods de Kubernetes basados en confidenciales. Estos otros componentes —por ejemplo, las correcciones de compatibilidad (shim) de Kata— no forman parte de la 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 de la máquina virtual de la utilidad (UVM) se implementa mediante Open Policy Agent (OPA) – un proyecto graduado de la Cloud Native Computing Foundation (CNCF).
Contenido de la directiva
La directiva de seguridad describe todas las llamadas a las API de 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 que usa 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:
- Una lista de los contenedores que se espera que se creen en el pod.
- Una 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 al proceso obtener nuevos privilegios?
- Variables de entorno.
- Otros campos de la configuración del entorno de ejecución del contenedor de 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 de la máquina virtual de la utilidad (UVM). 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 la 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 de "bloqueado por la directiva". Estos son algunos ejemplos de reglas:
- Cada capa de contenedor se expone como un bloque virtio de solo lectura dispositivo a la máquina virtual de la utilidad (UVM). 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, montaje de almacenamiento, contexto de seguridad de ejecución o variable de entorno inesperados.
De forma predeterminada, las reglas de directiva son comunes a todos los pods. La herramienta genpolicy genera los datos de directiva y es específica 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 devuelva un valor true 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 cualquier llamada a la API de CreateContainer se rechaza, 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 de GuestDetails siempre se permiten porque los datos devueltos por esta API no son confidenciales para las cargas de trabajo del cliente.
Envío de la directiva al agente Kata
Todas las máquinas virtuales de la utilidad de contenedor confidencial (UVM) de AKS empiezan a usar una directiva genérica predeterminada incluida en el sistema de archivos raíz de la máquina virtual de utilidad (UVM). 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 de YAML como se ha descrito anteriormente y se proporciona de esta manera al agente al principio durante la inicialización de la máquina virtual de la utilidad (UVM). La anotación de la directiva viaja por los componentes kubelet, contenedores y shim de 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 de la 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 la confianza en el documento de directiva
Antes de crear la máquina virtual de la utilidad (UVM), 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 la máquina virtual de la utilidad (UVM). Este campo TEE no es modificable más adelante por el software ejecutado dentro de la máquina virtual de la utilidad (UVM) o fuera de él.
Al recibir la directiva, el agente comprueba que 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 la carga de trabajo se ejecuta con las versiones esperadas del TEE, sistema operativo, agente, OPA y sistema de archivos raíz. La atestación se implementa en un contenedor que se ejecuta dentro de la máquina virtual de la utilidad (UVM) que obtiene la evidencia de atestación firmada del hardware AMD SEV-SNP. Uno de los campos de las pruebas de atestación es el campo TEE de 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.
Cumplimiento de directivas
El agente Kata es responsable de aplicar la directiva. Microsoft contribuyó a la comunidad Kata y CoCo con el código del agente responsable de comprobar la directiva de cada llamada API de ttrpc del agente. Antes de llevar a cabo las acciones correspondientes de la API, el agente usa la API de REST de OPA para comprobar si las reglas de directiva y los datos permiten o bloquean la llamada.