Partilhar via


Plug-in de computação confidencial para VMs confidenciais

O Serviço Kubernetes do Azure (AKS) fornece um plug-in para máquinas virtuais (VMs) de computação confidencial do Azure. O plugin, confcom, é um conjunto de daemon. O plug-in só é executado para VMs confidenciais do Intel Software Guard Extensions (SGX) em um cluster AKS. Este plugin está registado ao nível do cluster AKS. Você pode usar o plugin para gerenciar nós confidenciais facilmente. Habilite o plugin no seu cluster AKS antes de começar.

Plug-in de dispositivo Intel SGX para AKS

O plug-in de dispositivo SGX implementa a interface de plug-in de dispositivo Kubernetes para memória EPC (Enclave Page Cache). Com efeito, este plugin torna a memória EPC outro tipo de recurso no Kubernetes. Os usuários podem especificar limites no EPC assim como outros recursos. Além da função de agendamento, o plug-in do dispositivo ajuda a atribuir permissões de driver de dispositivo SGX a 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 auxiliar de cotação SGX

Os aplicativos de enclave que fazem atestado remoto precisam gerar uma cotação. A citação fornece prova criptográfica da identidade e do estado do aplicativo, juntamente com o ambiente host do enclave. A geração de cotações depende de certos componentes de software confiáveis da Intel, que fazem parte dos componentes de software da plataforma SGX (PSW/DCAP). Este PSW é empacotado como um conjunto de daemon que é executado por nó. Você pode usar PSW ao solicitar cotação de atestado de aplicativos de enclave. Usar o serviço fornecido pelo AKS ajuda a manter melhor a compatibilidade entre o PSW e outros componentes de SW no host. Leia os detalhes do recurso abaixo.

Os aplicativos de enclave que fazem atestado remoto exigem uma cotação gerada. Esta citação fornece 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.

Descrição geral

Nota

Esse recurso só é necessário para VMs DCsv2/DCsv3 que usam hardware Intel SGX especializado.

A Intel suporta dois modos de atestado para executar a geração de cotações. Para saber como escolher qual tipo, consulte [attestation type differences] (#attestation-type-differences).

  • in-proc: hospeda os componentes de software confiáveis dentro do processo de aplicação do 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 Enclave. Este é um método preferido ao executar o atestado remoto.

Os aplicativos SGX são criados usando o Open Enclave SDK por padrão, use o modo de atestado in-proc. Os aplicativos baseados em SGX permitem fora do processo e exigem hospedagem extra. Esses aplicativos expõem os componentes necessários, como o AESM (Architectural Enclave Service Manager), externo ao aplicativo.

É altamente recomendável usar esse recurso. Esse recurso aumenta o tempo de atividade dos aplicativos de enclave durante as atualizações da plataforma Intel ou DCAP.

Diferenças no tipo de atestado

Não são necessárias atualizações para os componentes de geração de cotação do PSW para cada aplicativo em contêiner.

Com o off-of-proc, os proprietários de contêineres não precisam gerenciar atualizações dentro de seu contêiner. Em vez disso, os proprietários de contêineres confiam na interface fornecida que invoca o serviço centralizado fora do contêiner.

Para off-of-proc, não há preocupação de falhas devido a componentes PSW desatualizados. A geração de cotação envolve os componentes SW confiáveis - Quoting Enclave (QE) ou Provisioning Certificate Enclave (PCE), que fazem parte da base de computação confiável (TCB). 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 em seu contêiner.

Out-of-proc usa melhor a memória EPC. No modo de atestado in-proc, cada aplicativo de enclave instancia a cópia de QE e PCE para atestado remoto. Com out-of-proc, o contêiner não hospeda esses enclaves e não consome memória de enclave da cota de contêiner.

Há também salvaguardas contra a aplicação do kernel. Quando o driver SGX é transmitido para o kernel Linux, um enclave tem maior privilégio. Esse privilégio permite que o enclave invoque PCE, o que quebra o aplicativo de enclave em execução no modo in-proc. Por padrão, os enclaves não recebem essa permissão. Conceder esse privilégio a um aplicativo de enclave requer alterações no processo de instalação do aplicativo. O provedor do serviço que lida com solicitações fora do procedimento garante que o serviço seja instalado com esse privilégio.

Não é necessário verificar a compatibilidade com versões anteriores com PSW e DCAP. O provedor valida atualizações para os componentes de geração de cotação do PSW para compatibilidade com versões anteriores. Esta etapa lida com problemas de compatibilidade antecipadamente e os aborda antes de implantar atualizações para cargas de trabalho confidenciais.

Atestado fora do procedimento para cargas de trabalho confidenciais

O modelo de atestado fora do procedimento funciona para cargas de trabalho confidenciais. O solicitante de cotação e a geração de cotação são executados separadamente, mas na mesma máquina física. A geração de cotações acontece de forma centralizada e atende às solicitações de COTAÇÕES de todas as entidades. Defina corretamente a interface e torne a interface detetável para qualquer entidade solicitar cotações.

Diagrama do solicitante de cotação e interface de geração de cotação.

O modelo abstrato aplica-se a cenários de carga de trabalho confidenciais. Este modelo utiliza o serviço AESM já disponível. O AESM é conteinerizado e implantado como um conjunto de daemon no cluster do Kubernetes. O Kubernetes garante uma única instância de um contêiner de serviço AESM, encapsulado em um pod, a ser implantado em cada nó do agente. O novo conjunto de daemon SGX Quote tem uma dependência do sgx-device-plugin conjunto de daemon, uma vez que o contêiner de serviço AESM solicitaria memória EPC para sgx-device-plugin iniciar enclaves QE e PCE.

Cada contêiner precisa optar por usar a geração de cotação fora do proc definindo a variável SGX_AESM_ADDR=1 de ambiente 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 in-proc e out-of-proc dentro de um aplicativo. A infraestrutura fora do processo está disponível por padrão e consome recursos.

Nota

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 é tratada para seus aplicativos de nível superior. Consulte a implementação do atestado por provedor.

Exemplo de implementação

Por padrão, este serviço não está habilitado para o seu AKS Cluster com addon "confcom". Por favor, atualize o addon com o comando abaixo

az aks addon update --addon confcom --name " YourAKSClusterName " --resource-group "YourResourceGroup " --enable-sgxquotehelper

Quando o serviço estiver ativo, use o exemplo de docker abaixo para um aplicativo baseado em Open Enclave para validar o fluxo. Defina a SGX_AESM_ADDR=1 variável de ambiente no arquivo do Docker. Ou defina a variável no arquivo de implantação. Siga este exemplo para obter os detalhes do arquivo Docker e do YAML de implantação.

Nota

O pacote libsgx-quote-ex da Intel precisa ser empacotado no contêiner do aplicativo para que o atestado fora do processo 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 ser bem-sucedida e permitir que seus aplicativos executem o atestado remoto usando o serviço SGX Quote Helper.

Passos Seguintes