Plug-in de computação confidencial para máquinas virtuais confidenciais
O AKS (Serviço de Kubernetes do Azure) fornece um plug-in para VMs (máquinas virtuais) de computação confidencial do Azure. O plug-in confcom é um conjunto de daemon. O plug-in é executado somente para VMs confidenciais de SGX (Software Guard Extensions) em um cluster AKS. Este plug-in está registrado no nível de cluster AKS. Você pode usar o plug-in para gerenciar nós confidenciais facilmente. Habilite o plug-in no seu cluster AKs antes de começar.
Plug-in de dispositivo do Intel SGX para AKS
O plug-in de dispositivo SGX implementa a interface de plug-in de dispositivo do Kubernetes para a memória EPC (Enclave Page Cache). Esse plug-in transforma a memória EPC em um outro tipo de recurso no Kubernetes. Os usuários podem especificar limites na EPC, assim como outros recursos. Além da função de agendamento, o plug-in do dispositivo ajuda a atribuir permissões do driver do dispositivo SGX aos contêineres de carga de trabalho confidenciais. Um exemplo de implementação da implantação baseada em memória EPC (kubernetes.azure.com/sgx_epc_mem_in_MiB) está disponível.
PSW com assistente de cotação SGX
Os aplicativos de enclave que executam o atestado remoto precisam gerar uma cotação. A cotação fornece uma prova criptográfica da identidade e do estado do aplicativo, bem como o ambiente no qual o enclave está sendo hospedado. A geração da cotação depende de determinados componentes de software confiáveis da Intel, que fazem parte dos Componentes de software da plataforma SGX (PSW/DCAP). Esse PSW é empacotado como um DaemonSet que é executado por nó. Você pode usar o PSW ao solicitar uma cotação de atestado dos aplicativos de enclave. O uso do serviço fornecido pelo AKS ajuda a manter melhor a compatibilidade entre o PSW e os outros componentes de SW no host. Leia os detalhes do recurso abaixo.
Os aplicativos de enclave que fazem o atestado remoto exigem uma cotação gerada. Essa cotação fornece uma prova criptográfica da identidade, do estado e do ambiente de execução do aplicativo. A geração requer componentes de software confiáveis que fazem parte do PSW da Intel.
Visão geral
Observação
Esse recurso só é necessário para VMs DCsv2/DCsv3 que usam hardware Intel SGX especializado.
A Intel dá suporte a dois modos de atestado para executar a geração de cotação. Para saber escolher qual tipo, confira as [diferenças de tipo de atestado] (#attestation-type-differences).
in-proc: hospeda os componentes de software confiáveis no processo do aplicativo de enclave. Esse método é útil quando você está executando o atestado local (entre 2 aplicativos de enclave em um único nó de VM)
out-of-proc: hospeda os componentes de software confiáveis fora do aplicativo de enclave. Esse é um método preferencial ao executar o atestado remoto.
Aplicativos SGX criados usando o SDK do Open Enclave, que usa por padrão o modo de atestado em processo. Os aplicativos baseados em SGX permitem o processamento out-of-proc (fora do processo) e exigem hospedagem adicional. Esses aplicativos expõem os componentes necessários, como Architectural Service Manager (AESM), externos ao aplicativo.
É altamente recomendável usar esse recurso. Esse recurso aprimora o tempo de atividade dos seus aplicativos de enclave durante as atualizações da plataforma Intel ou atualizações do driver DCAP.
Diferenças de tipos de atestado
Nenhuma atualização é necessária para componentes de geração de cotação do PSW para cada aplicativo conteinerizado.
Com out-of-proc, os proprietários do contêiner não precisam gerenciar atualizações no respectivo contêiner. Em vez disso, eles contam com a interface fornecida que invoca o serviço centralizado fora do contêiner.
Para casos fora do processo, não há preocupação de falhas devido a componentes de PSW desatualizados. A geração de cotação envolve os componentes de SW confiáveis – QE (enclave de cotação) e PCE (enclave de certificado de provisionamento), que fazem parte da TCB (base de computação confiável). Esses componentes de SW devem estar atualizados para manter os requisitos de atestado. O provedor gerencia as atualizações desses componentes. Os clientes nunca precisam lidar com falhas de atestado devido a componentes de SW confiáveis desatualizados dentro de seu contêiner.
Para fora do processo a memória EPC e melhor usada. No modo de atestado in-proc (no processo), cada aplicativo de enclave precisa criar uma instância da cópia de QE e PCE para atestado remoto. Com a opção out-of-proc (fora do processo), o contêiner não hospeda esses enclaves e não consome memória de enclave da cota do contêiner.
Também há proteções contra a imposição de kernel. Quando o driver de SGX é transmitido para o kernel do Linux, um enclave tem um privilégio maior. Esse privilégio permite que o enclave invoque o PCE, que interrompe o aplicativo de enclave em execução no modo in-proc. Por padrão, o enclaves não obtêm essa permissão. Conceder esse privilégio a um aplicativo de enclave requer alterações ao processo de instalação do aplicativo. O provedor do serviço que lida com solicitações out-of-proc garante que o serviço esteja instalado com esse privilégio.
Não é necessário verificar a compatibilidade com versões anteriores do PSW e do DCAP. O provedor valida as atualizações para os componentes de geração de cotação de PSW para compatibilidade com versões anteriores. Essa etapa lida com problemas de compatibilidade com antecedência e a solucioná-los antes de implantar atualizações a cargas de trabalho confidenciais.
Atestado out-of-proc (fora do processo) para cargas de trabalho confidenciais
O modelo de atestado out-of-proc funciona para cargas de trabalho confidenciais. O solicitante da cotação e a geração da cotação são executados separadamente, mas no mesmo computador físico. A geração da cotação acontece de maneira centralizada e atenderá a solicitações de COTAÇÕES de todas as entidades. Defina corretamente a interface e torne a interface detectável para que qualquer entidade solicite cotações.
O modelo abstrato se aplica a cenários de carga de trabalho confidenciais. Este modelo usa o serviço AESM já disponível. O AESM é conteinerizado e implantado como um conjunto daemon no cluster do Kubernetes. O Kubernetes garante que uma instância individual de um contêiner de serviço do AESM, encapsulada em um pod, será implantada em cada nó do agente. O novo conjunto daemon da Cotação SGX tem uma dependência no conjunto daemon sgx-device-plugin, pois o contêiner de serviço do AESM solicitaria a memória EPC do sgx-device-plugin para iniciar enclaves do QE e do PCE.
Cada contêiner precisa aceitar participar para usar a geração de cotação out-of-proc definindo a variável de ambiente SGX_AESM_ADDR=1 durante a criação. O contêiner também deve incluir o pacote libsgx-quote-ex, que direciona a solicitação para o soquete de domínio UNIX padrão
Um aplicativo ainda pode usar o atestado in-proc como antes. No entanto, você não pode usar simultaneamente tanto in-proc quanto out-of-proc em um aplicativo. A infraestrutura out-of-proc está disponível por padrão e consome recursos.
Observação
Se você estiver usando um software wrapper Intel SGX (OSS/ISV) para executar seus contêineres não modificados, a interação de atestado com o hardware normalmente é manipulada para seus aplicativos de nível superior. Consulte a implementação de atestado por provedor.
Exemplo de implementação
Por padrão, esse serviço não está habilitado para o Cluster do AKS com o complemento "confcom". Atualize o complemento com o comando abaixo
az aks addon update --addon confcom --name " YourAKSClusterName " --resource-group "YourResourceGroup " --enable-sgxquotehelper
Depois que o serviço estiver em atividade, use o exemplo do Docker abaixo para um aplicativo baseado em Open Enclave a fim de validar o fluxo. Defina a variável de ambiente SGX_AESM_ADDR=1 no arquivo do Docker. Ou defina a variável no arquivo de implantação. Siga o exemplo abaixo para obter detalhes do arquivo do Docker e YAML de implantação.
Observação
O pacote libsgx-quote-ex da Intel precisa ser empacotado no contêiner do aplicativo para que o atestado out-of-proc funcione corretamente. As instruções abaixo têm os detalhes.
# 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
Em vez disso, defina o modo de atestado out-of-proc no arquivo YAML de implantação da seguinte maneira:
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
A implantação deve ter êxito e permitir que seus aplicativos executem o atestado remoto usando o serviço Auxiliar de Cotação do SGX.