Perguntas frequentes sobre nós de computação confidencial no AKS (Serviço de Kubernetes do Azure)

Sim, para nós de enclave intel SGX.

Sim, os nós de VM DCSv3 dão suporte à rede acelerada. Máquinas Virtuais de DCSv2, não.

Atualmente, as VMs de DCSv2/DCSv3 de computação confidencial do Azure são instaladas com o Intel SGX DCAP 1.33.2

Não. Os nós de computação confidencial baseados no Mecanismo do AKS dão suporte a nós de computação confidencial que permitem instalações personalizadas e têm controle total sobre o seu plano de controle do Kubernetes.

Sim, você pode executar diferentes pools de nós no mesmo cluster do AKS, incluindo nós de ACC. Para direcionar os seus aplicativos de enclave em um pool de nós específico, considere adicionar seletores de nó ou aplicar limites de EPC. Veja mais detalhes no guia de início rápido sobre nós confidenciais aqui.

Não no momento. Entre em contato com a equipe do produto em acconaks@microsoft.com se você tiver necessidades de contêiner ou de nós do Windows.

Sim. As VMs também têm uma memória normal que pode executar cargas de trabalho de contêiner padrão. Considere o modelo de risco e de segurança dos seus aplicativos antes de decidir sobre os modelos de implantação.

SKUs da DCSv2/DCsv3. Mais informações sobre DCSv2 e DCSv3 estão disponíveis nas regiões com suporte

Sim. A CLI do Azure também pode ser usada como uma alternativa, conforme documentado aqui.

18.04 em Gen 2.

• Dá suporte apenas a nós da VM do Ubuntu 18.04 Gen 2
• Não há suporte para nós do Windows nem para contêineres do Windows
• Não há suporte para dimensionamento automático de pod horizontal baseado em memória EPC. Há suporte para escala com base na memória regular e CPU.
• No momento, o Dev Spaces no AKS para aplicativos confidenciais não têm suporte

Sim. A CLI do Azure também pode ser usada como uma alternativa, conforme documentado aqui.

Sim, você trará o software de wrapper de SGX para executar em um enclave Intel SGX e examinar a página de contêineres confidenciais para obter mais detalhes sobre ativadores de plataforma.

Vários habilitadores (projetos de software livre e ISVs) fornecem maneiras de habilitar contêineres confidenciais. Examine a página de contêineres confidenciais para obter mais detalhes e referências individuais a implementações.

Atestado é o processo de demonstrar e validar que foi criada uma instância em parte do software corretamente na plataforma de hardware específica. Ele também garante que a evidência seja verificável para fornecer garantias de que ele esteja sendo executado em uma plataforma segura e que não foi adulterada. Leia mais sobre como o atestado é feito em aplicativos de enclave.

A memória EPC aplica-se à parte do aplicativo que está programada para ser executada no enclave. O tamanho total do seu contêiner não é a maneira correta de compará-lo com a memória EPC máxima disponível. Na verdade, os computadores DCSv2 com SGX, permitem uma memória de VM máxima de 32 GB no local em que a parte não confiável do aplicativo utilizaria. No entanto, se o contêiner consumir mais do que a memória EPC disponível, o desempenho da parte do programa em execução no enclave poderá ser afetado.

Para gerenciar melhor a memória EPC nos nós de trabalho, considere o gerenciamento de limites baseados em memória EPC por meio do Kubernetes. Siga o exemplo abaixo como referência.

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

A memória EPC total disponível é compartilhada entre os aplicativos de enclave nas mesmas VMs ou nós de trabalho. Se o seu aplicativo usar mais memória EPC do que o disponível, o desempenho do aplicativo poderá ser afetado. Por esse motivo, recomendamos que você defina a tolerância por aplicativo no seu arquivo YAML de implantação para gerenciar melhor a memória EPC disponível por nós de trabalho, conforme mostrado nos exemplos acima. Como alternativa, você sempre pode optar por aumentar os tamanhos de VM do pool de nós de trabalho ou adicionar mais nós.

Atualmente, as VMs do SKU da DCsv2 de computação confidencial do Azure dão suporte a um só espaço de endereço para o programa em execução em um enclave. Processo único é uma limitação atual projetada para fins de alta segurança. No entanto, os habilitadores de contêiner confidenciais podem ter implementações alternativas para superar essa limitação.

Não. O produto oferece o Complemento do ACC, que inclui o (confcom), que poderá ajudar você com isso. Leia mais sobre os detalhes da implantação aqui.

Não. Para executar instalações personalizadas, recomendamos que você escolha as implantações de Nós de trabalho de computação confidencial do Mecanismo do AKS.

A assinatura não pode ser validada nativamente durante a inicialização do enclave, mas sim por meio do processo de atestado. Confira a referência aqui.

Os contêineres confidenciais permitem assinar o código do enclave, mas não o próprio contêiner do docker. Com a assinatura do código do enclave (que normalmente é o código do aplicativo principal em Java, Python etc.), você pode verificar por meio do atestado os detalhes de MRSIGNER do código em questão antes de confiar nele e no ambiente de execução por meio do fluxo de atestado.

Próximas etapas

Examine a página de contêineres confidenciais para obter mais detalhes sobre os contêineres confidenciais.