Editar

Compartir a través de


Preguntas más frecuentes sobre los nodos de computación confidencial en Azure Kubernetes Service (AKS)

En este artículo se abordan las preguntas más frecuentes sobre los nodos de computación confidencial basados en Intel SGX en Azure Kubernetes Service (AKS). Si tiene más preguntas, puede enviar un correo electrónico a acconaks@microsoft.com.

Producto

¿Los nodos de computación confidencial de AKS están disponibles para su uso en producción?

Sí, para los nodos de enclave de Intel SGX.

¿Puedo habilitar las redes aceleradas con los clústeres de AKS de computación confidencial de Azure?

Sí, los nodos de máquina virtual DCSv3 admiten redes aceleradas. Las máquinas virtuales DCSv2, no.

¿Qué versión del controlador de Intel SGX se encuentra en la imagen de AKS para los nodos confidenciales?

Actualmente, las máquinas virtuales DCSv2/DCSv3 de computación confidencial de Azure tienen instalado Intel SGX DCAP 1.33.2

¿Puedo insertar scripts posteriores a la instalación o controladores personalizados en los nodos aprovisionados por AKS?

No. Los nodos de computación confidencial basados en el motor de AKS admiten nodos de computación confidencial que permiten instalaciones personalizadas y tienen control total sobre el plano de control de Kubernetes.

¿Puedo ejecutar nodos de ACC con otras SKU de AKS estándar (es decir, crear un clúster de grupos de nodos heterogéneos)?

Sí, puede ejecutar grupos de nodos diferentes en el mismo clúster de AKS, incluidos los nodos de ACC. Para establecer como destino las aplicaciones de enclave de un grupo de nodos específico, puede agregar selectores de nodo o aplicar límites de EPC. Consulte más detalles sobre el inicio rápido en los nodos confidenciales aquí.

¿Puedo ejecutar nodos de Windows y contenedores de Windows con ACC?

De momento, no. Póngase en contacto con el equipo del producto en acconaks@microsoft.com si necesita contenedores o nodos de Windows.

¿Puedo seguir programando y ejecutando contenedores que no sean de enclave en nodos de computación confidencial?

Sí. Las máquinas virtuales también tienen una memoria normal que puede ejecutar cargas de trabajo de contenedor estándar. Antes de decidir los modelos de implementación, tenga en cuenta el modelo de seguridad y amenazas de las aplicaciones.

¿Qué SKU de máquina virtual debería elegir para los nodos de computación confidencial?

SKU de DCSv2/DCsv3. Las SKU de DCSv2 y DCSv3 están disponibles en las regiones admitidas.

¿Puedo aprovisionar AKS con grupos de nodos DCSv2 mediante Azure Portal?

Sí. Como alternativa, también se puede usar la CLI de Azure, tal como se documenta aquí.

¿Qué versión de Ubuntu y generación de máquinas virtuales se admite?

18.04 en Gen 2.

¿Cuáles son las limitaciones actuales conocidas del producto?

  • Solo admite nodos de máquina virtual de la generación 2 de Ubuntu 18.04.
  • No se admiten nodos de Windows ni contenedores de Windows.
  • No se admite la escalabilidad automática horizontal de pods basado en memoria EPC. Se admite el escalado basado en CPU y en memoria normal.
  • Actualmente no se admite Dev Spaces en AKS para aplicaciones confidenciales.

¿Puedo aprovisionar AKS con grupos de nodos DCSv2/DCSv3 mediante Azure Portal?

Sí. Como alternativa, también se puede usar la CLI de Azure, tal como se documenta aquí.

Desarrollo e implementación

¿Puedo traer las aplicaciones en contenedores que tengo y ejecutarlas en AKS con la computación confidencial de Azure (ACC)?

Sí, va a usar un software de contenedor SGX para ejecutarlo en un enclave. Revise la página Contenedores confidenciales para más detalles sobre los habilitadores de plataforma.

¿Debo usar una imagen base de Docker para empezar a trabajar con las aplicaciones de enclave?

Diversos habilitadores (ISV y proyectos de OSS) proporcionan métodos para habilitar contenedores confidenciales. Revise la página de contenedores confidenciales para obtener más detalles y referencias individuales a las implementaciones.

Conceptos de contenedores confidenciales

¿Qué es la atestación y cómo se puede realizar la atestación de aplicaciones que se ejecutan en enclaves?

La atestación es el proceso por el que se demuestra y se confirma que se ha creado correctamente una instancia de un fragmento de software en la plataforma de hardware específica. Este proceso también asegura que su evidencia es comprobable, para proporcionar garantías de que se está ejecutando en una plataforma segura y no se ha alterado. Lea más sobre cómo se realiza la atestación en las aplicaciones de enclave.

¿Qué ocurre si el tamaño del contenedor es mayor que la memoria EPC disponible?

La memoria EPC se aplica a la parte de la aplicación que está programada para ejecutarse en el enclave. Por tanto, no tiene sentido comparar el tamaño total del contenedor con la cantidad máxima de memoria EPC disponible. De hecho, las máquinas DCSv2 con SGX admiten una cantidad máxima de memoria de la máquina virtual de 32 GB, donde se usaría la parte que no es de confianza de la aplicación. Sin embargo, si el contenedor consume más memoria EPC de la que tiene disponible, el rendimiento de la parte del programa que se ejecuta en el enclave podría verse afectado.

Para administrar mejor la memoria EPC en los nodos de trabajo, puede administrar los límites basados en memoria EPC mediante Kubernetes. Siga el ejemplo siguiente como referencia.

Nota:

En el ejemplo siguiente se extrae una imagen de contenedor público de Docker Hub. Se recomienda configurar un secreto de extracción para autenticarse mediante una cuenta de Docker Hub en lugar de realizar una solicitud de extracción anónima. Para mejorar la confiabilidad al trabajar con contenido público, importe y administre la imagen en un registro de contenedor privado de Azure. Más información sobre cómo trabajar con imágenes públicas.

apiVersion: batch/v1
kind: Job
metadata:
  name: sgx-test
  labels:
    app: sgx-test
spec:
  template:
    metadata:
      labels:
        app: sgx-test
    spec:
      containers:
      - name: sgxtest
        image: oeciteam/sgx-test: 1.0
        resources:
          limits:
            sgx.intel.com/sgx_epc_mem_in_MiB: 10 # This limit will automatically place the job into confidential computing node. Alternatively, you can target deployment to node pools
      restartPolicy: Never
  backoffLimit: 0

¿Qué ocurre si mi enclave consume más memoria EPC que la cantidad máxima disponible?

La memoria EPC total disponible se comparte entre las aplicaciones del enclave de las mismas máquinas virtuales o nodos de trabajo. Si la aplicación usa más cantidad de memoria EPC de la que hay disponible, el rendimiento de la aplicación podría verse afectado. Por esta razón, se recomienda establecer valores toleration por aplicación en el archivo YAML de implementación para administrar mejor la memoria EPC disponible por nodos de trabajo, tal como se ha mostrado en los ejemplos anteriores. Como alternativa, siempre puede optar por aumentar los tamaños de máquina virtual del grupo de nodos de trabajo o agregar más nodos.

¿Por qué no puedo usar bifurcaciones y exec para ejecutar varios procesos en mi aplicación de enclave?

Actualmente, las máquinas virtuales de la SKU de DCsv2 de computación confidencial de Azure solo admiten un espacio de direcciones para el programa que se ejecuta en un enclave. Para garantizar un alto nivel de seguridad, se ha impuesto la limitación de un único proceso. Sin embargo, los habilitadores de contenedores confidenciales pueden tener implementaciones alternativas para superar esta limitación.

¿Tengo que montar los volúmenes de controladores en el archivo yaml de la implementación?

No. El producto proporciona el complemento ACC que incluye (confcom) y le ayudará con esto. Más información sobre los detalles de implementación aquí.

¿Se puede cambiar la versión actual de controlador de Intel SGX DCAP en AKS?

No. Para realizar cualquier instalación personalizada, se recomienda elegir implementaciones de nodos de trabajo de computación confidencial de motor de AKS.

¿Solo se cargarán imágenes firmadas y de confianza en el enclave para la computación confidencial?

No se puede validar de forma nativa durante la inicialización del enclave, pero sí a través de la firma del proceso de atestación. Aquí encontrará más referencia.

¿Es posible la firma de contenedores para proteger la integridad del código en contenedores confidenciales?

Los contenedores confidenciales le permiten firmar el código del enclave, pero no el propio contenedor de Docker. Con la firma del código de enclave (que suele ser el código principal de la aplicación en Java, Python, etc.), puede comprobar mediante la atestación los detalles de MRSIGNER del código del enclave antes de poder confiar en el código y el entorno de ejecución mediante el flujo de atestación.

Pasos siguientes

Consulte la página Contenedores confidenciales para más detalles sobre los contenedores confidenciales.