Política de segurança para contêineres confidenciais no Serviço Kubernetes do Azure
Conforme descrito pelo Confidential Computing Consortium (CCC), "Computação Confidencial é a proteção de dados em uso através da realização de computação em um ambiente de execução confiável (TEE) baseado em hardware e atestado." Os Contêineres Confidenciais AKS são projetados para proteger os dados dos pods do Kubernetes em uso contra acesso não autorizado de fora desses pods. Cada pod é executado em uma VM de Utilitário (UVM) protegida pelo AMD SEV-SNP TEE criptografando os dados em uso e impedindo o acesso aos dados pelo Sistema Operacional Host (SO). Os engenheiros da Microsoft colaboraram com as comunidades de código aberto Confidential Containers (CoCo) e Kata Containers no projeto e implementação dos Confidential Containers.
Visão geral da política de segurança
Um dos principais componentes da arquitetura do sistema Kata Containers é o agente Kata. Ao usar Kata Containers para implementar Confidential Containers, o agente é executado dentro do TEE baseado em hardware e, portanto, faz parte da Trusted Computing Base (TCB) do pod. Como mostrado no diagrama a seguir, o agente Kata fornece um conjunto de APIs ttrpc permitindo que os componentes do sistema fora do TEE criem e gerenciem pods Kubernetes baseados em Confidential. Esses outros componentes (por exemplo, o Kata Shim) não fazem parte do TCB do pod. Portanto, o agente deve se proteger de chamadas de API potencialmente maliciosas ou com bugs.
Nos Contêineres Confidenciais do AKS, a autoproteção da API do agente Kata é implementada usando uma política de segurança (também conhecida como Política do Agente Kata), especificada pelos proprietários dos pods confidenciais. O documento de política contém regras e dados correspondentes a cada pod, utilizando a linguagem de política Rego padrão da indústria. A aplicação da política dentro da VM de Utilidade (UVM) é implementada usando o Open Policy Agent (OPA) – um projeto graduado da Cloud Native Computing Foundation (CNCF).
Conteúdo da política
A política de segurança descreve todas as chamadas para as APIs ttrpc do agente (e os parâmetros dessas chamadas de API) esperadas para criar e gerenciar o pod Confidencial. O documento de política de cada pod é um ficheiro de texto, utilizando a linguagem Rego. O documento político contém três secções de alto nível.
Dados
Os dados da política são específicos para cada pod. Contém, por exemplo:
- Uma lista de contêineres que devem ser criados no pod.
- Uma lista de APIs bloqueadas pela política por padrão (por motivos de confidencialidade).
Exemplos de dados incluídos no documento de política para cada um dos contêineres em um pod:
- Informações sobre integridade de imagem.
- Comandos executados no contêiner.
- Volumes de armazenamento e montagens.
- Contexto de segurança de execução. Por exemplo, o sistema de arquivos raiz é somente leitura?
- O processo pode ganhar novos privilégios?
- Variáveis de ambiente.
- Outros campos da configuração de tempo de execução do contêiner Open Container Initiative (OCI).
Regras
As regras de política, especificadas no formato Rego, são executadas pela OPA para cada chamada de API do agente Kata de fora da VM do utilitário (UVM). O agente fornece todas as entradas de API para OPA, e OPA usa as regras para verificar se as entradas são consistentes com os dados da política. Se as regras e os dados da política não permitirem entradas de API, o agente rejeitará a chamada de API retornando uma mensagem de erro "bloqueado pela política". Aqui estão alguns exemplos de regras:
- Cada camada de contêiner é exposta como um dispositivo de bloco virtio somente leitura para a VM do utilitário (UVM). A integridade desses dispositivos de bloco é protegida usando a tecnologia dm-verity do kernel Linux. O valor raiz esperado da árvore de hash dm-verity é incluído nos dados da política e verificado em tempo de execução pelas regras da política.
- As regras rejeitam a criação de contêiner quando uma linha de comando, montagem de armazenamento, contexto de segurança de execução ou variável de ambiente inesperada é detetada.
Por padrão, as regras de política são comuns a todos os pods. A ferramenta genpolicy gera os dados da política e é específica para cada pod.
Valores predefinidos
Ao avaliar as regras do Rego usando os dados da política e as entradas da API como parâmetros, a OPA tenta encontrar pelo menos um conjunto de regras que retorna um true valor com base nos dados de entrada. Se as regras não retornarem true, o OPA retornará ao agente o valor padrão para essa API. Exemplos de valores padrão da Política:
default CreateContainerRequest := false– significa que qualquer chamada de API CreateContainer é rejeitada, a menos que um conjunto de regras de Política permita explicitamente essa chamada.default GuestDetailsRequest := true– significa que chamadas de fora do TEE para a API GuestDetails são sempre permitidas porque os dados retornados por esta API não são confidenciais para confidencialidade das cargas de trabalho do cliente.
Enviando a política para o agente Kata
Todas as VMs do Utilitário de Contêiner Confidencial (UVM) do AKS são iniciadas usando uma política padrão genérica incluída no sistema de arquivos raiz da VM do Utilitário (UVM). Portanto, uma política que corresponda à carga de trabalho real do cliente deve ser fornecida ao agente em tempo de execução. O texto da política é incorporado no arquivo de manifesto do YAML conforme descrito anteriormente e é fornecido dessa forma ao agente no início da inicialização da VM do utilitário (UVM). A anotação de política percorre os componentes kubelet, containerd e Kata shim do sistema AKS Confidential Containers. Em seguida, o agente que trabalha em conjunto com a OPA impõe a política para todas as chamadas para suas próprias APIs.
A política é fornecida usando componentes que não fazem parte do seu TCB, portanto, inicialmente, essa política não é confiável. A confiabilidade da política deve ser estabelecida por meio de Atestado Remoto, conforme descrito na seção a seguir.
Estabelecer confiança no documento de política
Antes de criar a VM do utilitário (UVM), o shim Kata calcula o hash SHA256 do documento Policy e anexa esse valor de hash ao TEE. Essa ação cria uma forte ligação entre o conteúdo da Política e a VM do Utilitário (UVM). Este campo TEE não é modificável posteriormente pelo software executado dentro da VM do utilitário (UVM) ou fora dela.
Ao receber a política, o agente verifica se o hash da política corresponde ao campo TEE imutável. O agente rejeita a Política de entrada se detetar uma incompatibilidade de hash.
Antes de lidar com informações confidenciais, suas cargas de trabalho devem executar etapas de Atestado Remoto para provar a qualquer Terceira Parte Confiável que a carga de trabalho é executada usando as versões esperadas das versões TEE, SO, agente, OPA e sistema de arquivos raiz. O atestado é implementado em um contêiner executado dentro da VM do utilitário (UVM) que obtém evidências de atestado assinadas do hardware AMD SEV-SNP. Um dos campos da evidência de atestado é o campo TEE hash de política descrito anteriormente. Portanto, o serviço de Atestado pode verificar a integridade da política, comparando o valor desse campo com o hash esperado da política de pod.
Imposição de políticas
O agente Kata é responsável por fazer cumprir a política. A Microsoft contribuiu para a comunidade Kata e CoCo, o código do agente responsável por verificar a política para cada chamada de API ttrpc do agente. Antes de executar as ações correspondentes à API, o agente usa a API REST OPA para verificar se as regras e os dados da política permitem ou bloqueiam a chamada.