Compartilhar via

Contêineres Confidenciais (versão prévia) no AKS (Serviço de Kubernetes do Azure)

  • Artigo

Os contêineres confidenciais fornecem um conjunto de recursos e funcionalidades para proteger ainda mais as cargas de trabalho de contêiner padrão, para alcançar metas mais altas de segurança de dados, privacidade de dados e integridade de código de runtime. O AKS (Serviço de Kubernetes do Azure) inclui Contêineres Confidenciais (versão prévia) no AKS.

Contêineres Confidenciais se baseiam em Contêineres Confidenciais Kata e criptografia baseada em hardware para criptografar a memória do contêiner. Eles estabelecem um novo nível de confidencialidade de dados impedindo que os dados na memória durante a computação estejam em texto não criptografado e em formato legível. Obtém-se confiança no contêiner por meio do atestado de hardware, permitindo o acesso aos dados criptografados por entidades confiáveis.

Juntamente com Restrição de Área de Pod, você pode executar cargas de trabalho confidenciais isoladas no Azure para proteger seus dados e cargas de trabalho. O que torna um contêiner confidencial:

  • Transparência: o ambiente de contêiner confidencial em que o aplicativo confidencial é compartilhado, você pode ver e verificar se ele é seguro. Todos os componentes da TCB (Base de Computação Confiável) devem ser de software livre.
  • Auditabilidade: você tem a capacidade de verificar e ver qual versão do pacote de ambiente CoCo, inclusive o SO Convidado Linux e se todos os componentes estão atuais. A Microsoft assina o SO convidado e o ambiente de runtime do contêiner para verificações por meio do atestado. Ela também libera um SHA (algoritmo de hash seguro) de builds de SO convidado para criar uma história de audibilidade e controle de cadeia de caracteres.
  • Atestado completo: tudo o que faz parte do TEE deve ser totalmente medido pela CPU com a capacidade de verificar remotamente. O relatório de hardware do processador AMD SEV-SNP deve refletir as camadas de contêiner e o hash de configuração de runtime de contêiner por meio das declarações de atestado. O aplicativo pode buscar o relatório de hardware localmente, inclusive o relatório que reflete a imagem do SO convidado e o runtime do contêiner.
  • Integridade do código: a imposição de runtime está sempre disponível por meio de políticas definidas pelo cliente para contêineres e configuração de contêiner, como políticas imutáveis e assinatura de contêiner.
  • Isolamento do operador: designs de segurança que presumem privilégios mínimos e maior blindagem de isolamento de todas as partes não confiáveis, inclusive administradores de cliente/locatário. Ele inclui a proteção do acesso existente do plano de controle do Kubernetes (kubelet) para os pods confidenciais.

Com outras medidas de segurança ou controles de proteção de dados, como parte da sua arquitetura geral, esses recursos ajudam você a cumprir os requisitos de conformidade regulatória, do setor ou de governança para a proteção de informações confidenciais.

Este artigo ajuda você a entender o recurso Contêineres Confidenciais e como implementar e configurar o seguinte:

  • Implantar ou atualizar um cluster do AKS usando a CLI do Azure
  • Adicionar uma anotação ao YAML do pod para marcar o pod como sendo executado por um contêiner confidencial
  • Adicionar uma política de segurança ao YAML do pod
  • Habilitar a imposição da política de segurança
  • Implantar seu aplicativo em computação confidencial

Cenários com suporte

Contêineres Confidenciais (versão prévia) são apropriados para cenários de implantação que envolvem dados confidenciais. Por exemplo PII (informações de identificação pessoal) ou dados com forte segurança necessária para conformidade regulatória. Alguns cenários comuns com contêineres são:

  • Execução da análise de Big Data usando o Apache Spark para reconhecimento de padrões de frauda no setor financeiro.
  • Execução de executores auto-hospedados do GitHub para assinar o código com segurança como parte das práticas de DevOps de CI/CD (integração contínua e implantação contínua).
  • Inferência do Machine Learning e treinamento de modelos de ML usando um conjunto de dados criptografado de uma fonte confiável. Ele só é descriptografado dentro de um ambiente de contêiner confidencial para preservar a privacidade.
  • Criação de salas limpas de Big Data para correspondência de ID como parte da computação de várias partes em setores como varejo com publicidade digital.
  • Criação de zonas de destino de Confiança Zero de computação confidencial para atender aos regulamentos de privacidade para migrações de aplicativos para a nuvem.

Considerações

Veja a seguir as consideração com esta versão prévia de Contêineres Confidenciais:

  • Um aumento no tempo de inicialização do pod em comparação com pods runc e pods isolados do kernel.
  • Não há suporte para imagens de contêiner da versão 1.
  • Atualizações de segredos e ConfigMaps não são refletidas no convidado.
  • Contêineres efêmeros e outros métodos de solução de problemas como exec em um contêiner, saídas de log de contêineres e stdio (ReadStreamRequest e WriteStreamRequest) exigem uma modificação e reimplantação de política.
  • A ferramenta de gerador de política não dá suporte a tipos de implantação cronjob.
  • Devido às medidas de camada de imagem de contêiner que estão sendo codificadas na política de segurança, não recomendamos usar a marca latest ao especificar contêineres.
  • Serviços, balanceadores de carga e EndpointSlices só dão suporte ao protocolo TCP.
  • Todos os contêineres em todos os pods nos clusters devem ser configurados para imagePullPolicy: Always.
  • O gerador de política só dá suporte a pods que usam endereços IPv4.
  • Os valores de ConfigMaps e segredos não poderão ser alterados se a configuração usar o método de variável de ambiente após a implantação do pod. A política de segurança a impede.
  • Não há suporte para logs de terminação de pod. Enquanto os pods gravam logs de terminação em /dev/termination-log ou em um local personalizado, se especificado no manifesto do pod, o host/kubelet não pode ler esses logs. As alterações do convidado para esse arquivo não são refletidas no host.

Visão geral da alocação de recursos

É importante que você entenda o comportamento de alocação de recursos de memória e processador nesta versão.

  • CPU: O shim atribui uma vCPU ao sistema operacional base dentro do pod. Se nenhum recurso limits for especificado, as cargas de trabalho não terão compartilhamentos de CPU separados atribuídos, a vCPU será compartilhada com essa carga de trabalho. Se os limites de CPU forem especificados, os compartilhamentos de CPU serão alocados explicitamente para cargas de trabalho.
  • Memória: o manipulador Kata-CC usa memória de 2 GB para o sistema operacional UVM e X MB de memória adicional, em que X é o recurso limits se especificado no manifesto YAML (resultando em uma VM de 2 GB quando nenhum limite é fornecido, sem memória implícita para contêineres). O manipulador Kata usa memória de base de 256 MB para o sistema operacional UVM e X MB de memória adicional quando o recurso limits é especificado no manifesto YAML. Se os limites não forem especificados, um limite implícito de 1.792 MB será adicionado, resultando em uma VM de 2 GB e 1.792 MB de memória implícita para contêineres.

Nesta versão, não há suporte para especificar solicitações de recurso nos manifestos do pod. O contêiner Kata ignora solicitações de recurso do manifesto YAML do pod e, como resultado, containerd não passa as solicitações para o shim. Use limit de recurso em vez de requests de recurso para alocar recursos de memória ou CPU para cargas de trabalho ou contêineres.

Com o sistema de arquivos de contêiner local apoiado pela memória de VM, gravar no sistema de arquivos do contêiner (incluindo registro em log) pode preencher a memória disponível fornecida para o pod. Essa condição pode resultar em possíveis falhas de pod.

Próximas etapas