Partilhar via

Contêineres confidenciais (visualização) com o Serviço Kubernetes do Azure (AKS)

  • Artigo

Os Contêineres Confidenciais fornecem um conjunto de recursos e capacidades para proteger ainda mais suas cargas de trabalho de contêiner padrão para alcançar maiores objetivos de segurança de dados, privacidade de dados e integridade de código de tempo de execução. O Serviço Kubernetes do Azure (AKS) inclui Contêineres Confidenciais (visualização) no AKS.

O Confidential Containers baseia-se no Kata Confidential Containers e na criptografia baseada em hardware para criptografar a memória do contêiner. Estabelece um novo nível de confidencialidade dos dados, impedindo que os dados na memória durante o cálculo estejam em texto claro e num formato legível. A confiança é obtida no contêiner por meio de atestado de hardware, permitindo o acesso aos dados criptografados por entidades confiáveis.

Juntamente com o Pod Sandboxing, você pode executar cargas de trabalho confidenciais isoladas no Azure para proteger seus dados e cargas de trabalho. O que torna um recipiente confidencial:

  • Transparência: o ambiente de contêiner confidencial onde seu aplicativo confidencial é compartilhado, você pode ver e verificar se é seguro. Todos os componentes da Trusted Computing Base (TCB) devem ser de código aberto.
  • Auditabilidade: Você tem a capacidade de verificar e ver qual versão do pacote de ambiente CoCo, incluindo Linux Guest OS e todos os componentes, são atuais. A Microsoft assina no SO convidado e no ambiente de tempo de execução do contêiner para verificações por meio de atestado. Ele também lança um algoritmo de hash seguro (SHA) de compilações do SO convidado para construir uma audibilidade de cadeia de caracteres e história de controle.
  • Atestado completo: Tudo o que faz parte do ETE deve ser totalmente medido pela CPU com capacidade de verificação remota. O relatório de hardware do processador AMD SEV-SNP deve refletir as camadas de contêiner e o hash de configuração de tempo de execução do contêiner por meio das declarações de atestado. O aplicativo pode buscar o relatório de hardware localmente, incluindo o relatório que reflete a imagem do SO convidado e o tempo de execução do contêiner.
  • Integridade do código: a imposição do tempo de execução está sempre disponível por meio de políticas definidas pelo cliente para contêineres e configuração de contêineres, como políticas imutáveis e assinatura de contêineres.
  • Isolamento do operador: designs de segurança que assumem o menor privilégio e a maior proteção de isolamento de todas as partes não confiáveis, incluindo administradores de clientes/locatários. Ele inclui o fortalecimento do acesso existente ao plano de controle do Kubernetes (kubelet) para pods confidenciais.

Com outras medidas de segurança ou controles de proteção de dados, como parte de sua arquitetura geral, esses recursos ajudam você a atender aos requisitos de conformidade regulamentares, do setor ou de governança para proteger 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 AKS usando a CLI do Azure
  • Adicione uma anotação ao seu pod YAML para marcar o pod como sendo executado como um contêiner confidencial
  • Adicionar uma política de segurança ao seu pod YAML
  • Permitir a aplicação da política de segurança
  • Implante seu aplicativo em computação confidencial

Cenários suportados

Os contêineres confidenciais (visualização) são apropriados para cenários de implantação que envolvem dados confidenciais. Por exemplo, informações de identificação pessoal (PII) ou quaisquer dados com forte segurança necessários para conformidade regulamentar. Alguns cenários comuns com contêineres são:

  • Execute análises de big data usando o Apache Spark para reconhecimento de padrões de fraude no setor financeiro.
  • Executar corredores do GitHub auto-hospedados para assinar código com segurança como parte das práticas de DevOps de Integração Contínua e Implantação Contínua (CI/CD).
  • Inferência e treinamento de Machine Learning de modelos de ML usando um conjunto de dados criptografados de uma fonte confiável. Apenas desencripta dentro de um ambiente de contentor confidencial para preservar a privacidade.
  • Criação de salas limpas de big data para correspondência de ID como parte da computação multipartidária em setores como o varejo com publicidade digital.
  • Criação de zonas de aterrissagem Zero Trust de computação confidencial para atender às regulamentações de privacidade para migrações de aplicativos para a nuvem.

Considerações

Seguem-se considerações com esta pré-visualização de Contentores Confidenciais:

  • Um aumento no tempo de inicialização do pod em comparação com pods runc e pods isolados do kernel.
  • As imagens de contêiner da versão 1 não são suportadas.
  • As 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 geradora de políticas não suporta tipos de implantação de cronjob.
  • Devido às medições da camada de imagem do contêiner serem codificadas na política de segurança, não recomendamos o uso da latest tag ao especificar contêineres.
  • Serviços, Balanceadores de Carga e EndpointSlices suportam apenas o protocolo TCP.
  • Todos os contêineres em todos os pods nos clusters devem ser configurados para imagePullPolicy: Always.
  • O gerador de políticas suporta apenas pods que usam endereços IPv4.
  • Os valores ConfigMaps e secrets não podem 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 impede-o.
  • Os logs de terminação de pod não são suportados. 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 de 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 SO base dentro do pod. Se nenhum recurso limits for especificado, as cargas de trabalho não tiverem 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 explicitamente alocados para cargas de trabalho.
  • Memória: O manipulador Kata-CC usa 2 GB de memória para o sistema operacional UVM e X MB de memória adicional, onde X é o recurso limits se especificado no manifesto YAML (resultando em uma VM de 2 GB quando nenhum limite é dado, sem memória implícita para contêineres). O manipulador Kata usa 256 MB de memória base 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 a especificação de solicitações de recursos nos manifestos do pod. O contêiner Kata ignora as solicitações de recursos do manifesto pod YAML e, como resultado, containerd não passa as solicitações para o shim. Use recurso limit em vez de recurso requests 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 VM, a gravação no sistema de arquivos de contêiner (incluindo o registro) pode preencher a memória disponível fornecida ao pod. Esta condição pode resultar em possíveis falhas do pod.

Próximos passos