Complemento de computación confidencial para máquinas virtuales confidenciales
Azure Kubernetes Service (AKS) proporciona un complemento para máquinas virtuales (VM) de computación confidencial de Azure. El complemento, confcom, es un conjunto de demonios. El complemento solo se ejecuta para máquinas virtuales confidenciales de Intel Software Guard Extensions (SGX) en un clúster de AKS. Este complemento se registra en el nivel de clúster de AKS. Puede usar el complemento para administrar nodos confidenciales fácilmente. Habilite el complemento en el clúster de AKS antes de empezar.
Complemento de dispositivo Intel SGX para AKS
El complemento de dispositivo SGX implementa la interfaz del complemento de dispositivos Kubernetes para la memoria de Enclave Page Cache (EPC). De hecho, este complemento convierte la memoria EPC en otro tipo de recurso en Kubernetes. Los usuarios pueden especificar límites en EPC igual que en otros recursos. Además de la función de programación, el complemento del dispositivo ayuda a asignar los permisos del controlador de dispositivos de SGX a los contenedores de cargas de trabajo confidenciales. Hay disponible una implementación de muestra de la implementación basada en memoria de EPC (kubernetes.azure.com/sgx_epc_mem_in_MiB).
PSM con el asistente de citas SGX
Las aplicaciones de enclave que realizan la atestación remota necesitan generar una oferta. La cita proporciona una prueba criptográfica de la identidad y del estado de la aplicación junto con el entorno en que se hospeda el enclave. La generación de una cita utiliza determinados componentes de software de confianza de Intel, que forman parte de los componentes de software de plataforma (PSW/DCAP) de SGX. Este PSW se empaqueta como un DaemonSet que se ejecuta por nodo. Puede utilizar PSW al solicitar la cita de atestación de las aplicaciones de enclave. El uso del servicio proporcionado por AKS ayuda a mantener mejor la compatibilidad entre el PSW y otros componentes de software del host. Lea los detalles de la característica a continuación.
Las aplicaciones de enclave que realizan la atestación remota requieren que se genere una cita. Esta cita proporciona una prueba criptográfica de la identidad, el estado y el entorno de ejecución de la aplicación. La generación requiere componentes de software de confianza que formen parte del PSW de Intel.
Información general
Nota:
Esta característica solo es necesaria para las máquinas virtuales DCsv2/DCsv3 que usan hardware Intel SGX especializado.
Intel admite dos modos de atestación para ejecutar la generación de citas. Para saber cómo elegir qué tipo, consulte las [attestation type differences] (#attestation-type-differences).
En proceso: hospeda los componentes de software de confianza dentro del proceso de la aplicación de enclave. Este método es útil cuando se realiza la atestación local (entre dos aplicaciones de enclave en un único nodo de máquina virtual)
Fuera del proceso: hospeda los componentes de software de confianza que están fuera del proceso de la aplicación de enclave. Este es un método preferido al realizar la atestación remota.
Las aplicaciones de SGX se crean con el SDK Open Enclave usan de manera predeterminada el modo de atestación en proceso. Las aplicaciones basadas en SGX permiten el modo "Fuera de proceso" y requieren hospedaje adicional. Estas aplicaciones exponen los componentes necesarios, como Architectural Enclave Service Manager (AESM), externos a la aplicación.
Se recomienda encarecidamente usar esta característica. El uso de esta característica mejora el tiempo de actividad de las aplicaciones de enclave durante las actualizaciones de la plataforma Intel o de los controladores de DCAP.
Diferencias del tipo de atestación
No se requieren actualizaciones de los componentes de generación de citas de PSW para cada aplicación contenedorizada.
Con el modo fuera del proceso, los propietarios de los contenedores no necesitan administrar las actualizaciones de su contenedor. En su lugar, los propietarios de los contenedores confían en la interfaz proporcionada, que invoca el servicio centralizado fuera del contenedor.
En el caso del modo "Fuera de proceso", no hay ningún problema de errores debido a los componentes de PSW no actualizados. La generación de citas implica a los componentes de software de confianza, Quoting Enclave (QE) y Provisioning Certificate Enclave (PCE), que forman parte de la base de la computación de confianza (TCB). Estos componentes de software deben estar actualizados para mantener los requisitos de atestación. El proveedor administra las actualizaciones de estos componentes. Los clientes nunca tienen que tratar con errores de atestación debido a componentes de SW de confianza no actualizados dentro de su contenedor.
El modo "Fuera de proceso" usa mejor la memoria EPC. En el modo de atestación "En proceso", cada aplicación de enclave crea una instancia de la copia de QE y PCE para la atestación remota. Con el modo "Fuera de proceso", el contenedor no hospeda esos enclaves, por lo que no consume memoria de enclave de la cuota del contenedor.
También hay medidas de seguridad contra la aplicación del kernel. Cuando el controlador SGX se transmite al kernel de Linux, un enclave tiene más privilegios. Este privilegio permite que el enclave invoque a PCE, lo que interrumpe la aplicación de enclave que se ejecuta en el modo en proceso. De forma predeterminada, los enclaves no obtienen este permiso. La concesión de este privilegio a una aplicación de enclave requiere cambios en el proceso de instalación de la misma. El proveedor del servicio que controla las solicitudes fuera de proceso se asegura de que el servicio está instalado con este privilegio.
No es preciso comprobar la compatibilidad con versiones anteriores de PSW y DCAP. El proveedor valida las actualizaciones de los componentes de generación de citas de PSW para la compatibilidad con versiones anteriores. En este paso se controlan los problemas de compatibilidad por adelantado y se abordan antes de implementar las actualizaciones en las cargas de trabajo confidenciales.
Atestación fuera de proceso para cargas de trabajo confidenciales
El modelo de atestación fuera de proceso funciona para cargas de trabajo confidenciales. El solicitante de la cita y la generación de la cita se ejecutan por separado, pero en la misma máquina física. La generación de la cita ocurre de forma centralizada y atiende solicitudes de citas de todas las entidades. Defina correctamente la interfaz y haga que sea reconocible para que cualquier entidad solicite citas.
El modelo abstracto se aplica a escenarios de cargas de trabajo confidenciales. Este modelo usa el servicio AESM ya disponible. AESM se encuentra en un contenedor y se implementa como un conjunto de demonios en el clúster de Kubernetes. Kubernetes garantiza que, en cada nodo de agente, se implementará una única instancia de un contenedor de servicios AESM, encapsulada en un pod. El nuevo conjunto de demonios de citas de SGX tiene una dependencia del conjunto de demonios sgx-device-plugin, ya que el contenedor del servicio AESM solicitará memoria EPC de sgx-device-plugin para iniciar los enclaves QE y PCE.
Todos los contenedores deben participar para usar la generación de citas fuera del proceso. Para ello, es preciso establecer la variable de entorno SGX_AESM_ADDR=1 durante la creación. El contenedor también debe incluir el paquete libsgx-quote-ex, que dirige la solicitud al socket de dominio de Unix predeterminado
Una aplicación todavía puede usar la atestación en proceso como antes. Sin embargo, no puede usar simultáneamente tanto el modo "En proceso" como "Fuera de proceso" dentro de una aplicación. La infraestructura del modo fuera del proceso está disponible de forma predeterminada y consume recursos.
Nota:
Si usa un software contenedor Intel SGX (OSS/ISV) para ejecutar los contenedores sin modificar, la interacción de atestación con el hardware normalmente se controla para las aplicaciones de nivel superior. Consulte la implementación de atestación por proveedor.
Ejemplo de implementación
De forma predeterminada, este servicio no está habilitado para el clúster de AKS con el complemento "confcom". Actualice el complemento con el siguiente comando
az aks addon update --addon confcom --name " YourAKSClusterName " --resource-group "YourResourceGroup " --enable-sgxquotehelper
Una vez que el servicio está activa, use el ejemplo de docker siguiente para una aplicación basada en Open Enclave para validar el flujo. Establezca la variable de entorno SGX_AESM_ADDR=1 en el archivo de Docker. O bien, establezca la variable en el archivo de implementación. Para más información sobre el archivo de Docker y sobre el archivo YAML de la implementación, siga esta muestra.
Nota:
Para que el modo fuera del proceso funcione correctamente, es necesario que el paquete libsgx-quote-ex de Intel se empaquete en el contenedor de la aplicación. Las instrucciones siguientes tienen los detalles.
# Refer to Intel_SGX_Installation_Guide_Linux for detail
FROM ubuntu:18.04 as sgx_base
RUN apt-get update && apt-get install -y \
wget \
gnupg
# Add the repository to sources, and add the key to the list of
# trusted keys used by the apt to authenticate packages
RUN echo "deb [arch=amd64] https://download.01.org/intel-sgx/sgx_repo/ubuntu bionic main" | tee /etc/apt/sources.list.d/intel-sgx.list \
&& wget -qO - https://download.01.org/intel-sgx/sgx_repo/ubuntu/intel-sgx-deb.key | apt-key add -
# Add Microsoft repo for az-dcap-client
RUN echo "deb [arch=amd64] https://packages.microsoft.com/ubuntu/18.04/prod bionic main" | tee /etc/apt/sources.list.d/msprod.list \
&& wget -qO - https://packages.microsoft.com/keys/microsoft.asc | apt-key add -
FROM sgx_base as sgx_sample
RUN apt-get update && apt-get install -y \
clang-7 \
libssl-dev \
gdb \
libprotobuf10 \
libsgx-dcap-ql \
libsgx-quote-ex \
az-dcap-client \
open-enclave
WORKDIR /opt/openenclave/share/openenclave/samples/attestation
RUN . /opt/openenclave/share/openenclave/openenclaverc \
&& make build
# this sets the flag for out of proc attestation mode, alternatively you can set this flag on the deployment files
ENV SGX_AESM_ADDR=1
CMD make run
En su lugar, establezca el modo de atestación "Fuera de proceso" en el archivo YAML de implementación como se muestra a continuación:
apiVersion: batch/v1
kind: Job
metadata:
name: sgx-test
spec:
template:
spec:
containers:
- name: sgxtest
image: <registry>/<repository>:<version>
env:
- name: SGX_AESM_ADDR
value: 1
resources:
limits:
kubernetes.azure.com/sgx_epc_mem_in_MiB: 10
volumeMounts:
- name: var-run-aesmd
mountPath: /var/run/aesmd
restartPolicy: "Never"
volumes:
- name: var-run-aesmd
hostPath:
path: /var/run/aesmd
La implementación debe realizarse correctamente y permitir que las aplicaciones realicen la atestación remota mediante el servicio auxiliar sgX Quote.