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

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

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

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

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.

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í.

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

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.

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

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

18.04 en Gen 2.

• 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.

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

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.

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.

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.

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.

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

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.

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.

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í.

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

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.

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.