A computação confidencial utiliza um ambiente de execução confiável (TEE) para proteger a memória em uso, garantindo a criptografia dos dados em repouso, trânsito e uso. Containers Confidenciais (CoCo) são uma combinação de TEE com implantações do Kubernetes. A implantação de um TEE no nível de pod possibilita forte isolamento das cargas de trabalho, tanto de outras cargas de trabalho no cluster quanto dos administradores.

O verdadeiro desafio dos containers confidenciais está em começar a usá-los. A decisão de implantar um pod em um container confidencial requer somente a alteração de uma única linha no manifesto do pod. No entanto, antes disso, é necessário implantar vários componentes juntos em vários clusters, de preferência. Recentemente, a Red Hat lançou o suporte para containers confidenciais no Microsoft Azure no Red Hat OpenShift Sandboxed Container Operator v1.9 e versões superiores e para atestado remoto com o build do Trustee desenvolvido pela Red Hat.

Neste post, descrevo como usar padrões validados para alcançar três objetivos:

1. Simplificar os esforços iniciais de implantação de containers confidenciais usando o OpenShift Sandboxed Container Operator e o build Red Hat do Trustee no Azure.
2. Criar uma base consistente e declarativa para containers confidenciais, viabilizando as implantações baseadas em práticas recomendadas.
3. Demonstrar como implantar aplicações usando containers confidenciais.

Visão geral dos padrões validados 

Padrões validados são arquiteturas de código dinâmico para diferentes casos de uso de nuvem híbrida e multicloud. Cada padrão é testado e, após a validação, adicionado ao sistema de integração contínua (CI) da Red Hat. Isso nos dá a certeza de que estamos fazendo testes com as versões mais recentes dos operadores e do OpenShift em vários ambientes de nuvem pública.

Cada repositório de padrões validados pela Red Hat demonstra um caso de uso na forma de recursos do Kubernetes (gráficos Helm, kustomize e objetos primitivos), descrevendo um stack de nuvem híbrida de forma declarativa e abrangente, dos serviços à infraestrutura de apoio. O uso de padrões validados facilita implantações complexas e altamente reproduzíveis. Além disso, eles são ideais para operar essas implantações em grande escala usando as práticas operacionais do GitOps.

Por que usar padrões validados? 

A implantação de soluções empresariais complexas é um processo que envolve várias etapas. Se executadas sem cuidado, cada etapa pode gerar erros ou ineficiências. O uso de padrões validados resolve essa questão ao oferecer um processo de implantação automatizado e pré-validado:

• Um modelo GitOps é usado para disponibilizar o caso de uso como código.
• Esses padrões servem como prova de conceito (PoC) modificada para atender a uma necessidade específica e podem ser desenvolvidos para se tornarem uma implantação real.
• Os padrões são altamente reproduzíveis e, por isso, excelentes para operar em grande escala.
• Os padrões validados são abertos à colaboração. Qualquer pessoa pode usar, contribuir e sugerir melhorias porque todos os repositórios Git são upstream.
• É possível modificar cada padrão validado conforme as necessidades específicas. Se você quiser trocar um componente (por exemplo, usar armazenamento do Ceph, em vez do S3), basta comentar as seções na configuração e incluir outro repositório.
• Eles foram testados. Após ser validado como padrão, o caso de uso é incluído na CI da Red Hat e continua a ser testado nas versões das soluções enquanto o padrão permanecer ativo.

Os padrões validados são uma solução "com tudo incluso". Começando ou não com o framework dos padrões, tanto o núcleo quanto um conjunto configurável de componentes são disponibilizados prontos para o uso. Neste artigo, usei um padrão validado para facilitar o processo inicial de implantação dos containers confidenciais.

Como implantar um padrão

O website de padrões validados traz uma documentação detalhada sobre o uso de padrões validados. As práticas recomendadas exigem:

1. Um repositório Git, como uma bifurcação do padrão. Os padrões validados usam GitOps e é você que deve controlar o repositório que está usando.
2. Um notebook de desenvolvedor com oc, Git e Podman instalados.
3. Um cluster do OpenShift em branco, quando o operador do padrão "gerencia" o cluster.

Como esses requisitos se relacionam:

Com essa configuração, o padrão validado é "proprietário" do que está no cluster, simplificando seu ponto de partida.

Como usar padrões validados para a implantação de containers confidenciais

Os containers em sandbox do Red Hat OpenShift são baseados em containers Kata. Além disso, eles têm a capacidade extra de executar containers confidenciais. Eles são implantados em um enclave isolado do hardware, proporcionando maior proteção para dados e códigos contra o acesso de usuários com privilégios, como administradores de nuvem ou de cluster. O projeto CNCF Confidential Containers é a base da solução de containers confidenciais do OpenShift.

Por utilizar soluções baseadas em hardware dedicado, a computação confidencial oferece maior proteção para dados em uso. É possível criar ambientes isolados de sua propriedade no hardware. Isso evita acessos não autorizados ou alterações nos dados da sua carga de trabalho enquanto ela está sendo executada (dados em uso).

Com os containers confidenciais, é possível ter uma computação confidencial nativa em nuvem usando várias plataformas de hardware e tecnologias de apoio. O objetivo desses containers é padronizar a computação confidencial no nível do pod e simplificar o consumo em ambientes Kubernetes. Assim, os usuários do Kubernetes podem implantar cargas de trabalho de containers confidenciais aproveitando as mesmas ferramentas e fluxos de trabalho que já conhecem, sem precisar aprender tudo sobre as tecnologias de computação confidencial.

Para mais informações, leia O que é a solução de containers confidenciais do OpenShift. 

Arquitetura dos containers confidenciais 

A solução de containers confidenciais da Red Hat é baseada em dois operadores principais:

• Containers confidenciais do Red Hat OpenShift: uma funcionalidade adicionada ao operador de containers de sandbox do Red Hat OpenShift. Eles implantam os elementos essenciais de conexão entre cargas de trabalho (pods) e máquinas virtuais confidenciais (CVM) executadas no TEE do hardware.
• Atestado remoto: o build do Trustee desenvolvido pela Red Hat. Ele implanta e gerencia o Key Broker Service (KBS) em um cluster do Red Hat OpenShift.

Para mais informações, leia Introdução ao Trustee para containers confidenciais: visão geral dos serviços de atestado e casos de uso.

Normalmente, os containers confidenciais têm dois ambientes: uma zona confiável e outra não confiável. O Trustee e o operador de container de sandbox são implantados nestas zonas: 

Qual é o desafio, então? Fazer isso requer entender e conhecer os detalhes específicos da infraestrutura on-premise ou de nuvem. É importante considerar várias questões, como: em que região você está? Qual chipset (Intel, AMD, IBM Power, s390) e hipervisor você usará? 

Para mais informações, leia Considerações sobre a implantação da solução de containers confidenciais do Red Hat OpenShift.

Introdução ao padrão validado para containers confidenciais

O objetivo desse padrão validado é facilitar o processo inicial e mostrar como implantar Containers Confidenciais. Ele usa a arquitetura de padrão validado para:

1. Implantar os operadores necessários para a execução dos containers confidenciais.
2. Configurar os componentes periféricos em segundo plano, como certificados (usando Let's Encrypt, se necessário).
3. Abstrair da nuvem a implantação dos containers confidenciais no cluster para o usuário, usando ferramentas como o Red Hat Advanced Cluster Manager.
4. Implantar um conjunto de aplicações de amostra para demonstrar várias funcionalidades dos containers confidenciais, como a manipulação deles.

Atualmente, o padrão é implantado no Microsoft Azure em um único cluster, com todos os componentes provenientes do mesmo padrão validado (mais implantações serão adicionadas no futuro).

Como funciona?

Utilizamos o operador de padrões validados para implantar o Argo CD. Por sua vez, o Argo CD implanta os demais operadores necessários. 

O problema é que o mapa de configuração de pods pares, como init-data e kata-policy, precisa ser configurado para apontar para o Trustee Key Broker Service (KBS). Essas informações são dinâmicas e o usuário precisa usar a interface de linha de comando (CLI) ou o portal do Azure. Do ponto de vista da segurança e da visibilidade, o init-data e o kata-policy também são um problema, por serem serializados em base64 antes de serem enviados para um mapa de configuração. Isso torna mais difícil para o usuário verificar a postura.

 

Esses problemas são resolvidos com o uso de metadados injetados pelo operador de padrões validados. Assim, fica mais fácil acessar as informações no cluster na nossa aplicação. As políticas avançadas do gerenciador de cluster são usadas para coletar as informações definidas pelo gerenciador do controlador da nuvem e, depois, injetá-las nos mapas de configuração e segredos apropriados para o operador de containers em sandbox.

O Hashicorp Vault é usado como um KMS no cluster com a configuração de segredos de padrões validados. Com isso, os usuários podem consistentemente inicializar o Vault usando um ambiente de estação de trabalho de desenvolvedor. Usamos isso para informar os segredos ao Trustee, e a sincronização é feita pelo operador de segredos externo.

A combinação de tudo isso possibilita a instalação com um único comando, como demonstrado abaixo: 

Requisitos 

Atualmente, estamos restritos ao Azure como plataforma e a uma topologia de padrão simples consistindo em um único cluster do OpenShift.

Os usuários podem usar um cluster do Azure Red Hat OpenShift ou do OpenShift autogerenciado no Azure. O padrão inclui a documentação sobre como usar openshift-install para criar um cluster. Além da disponibilidade na região, o cluster e a conta do Azure precisam ter acesso às CVMs. Hoje, o padrão pressupõe o uso de máquinas virtuais de classe DCasv5 para os containers confidenciais. No entanto, isso pode ser personalizado.

A única configuração extra necessária para o Azure é implantar um gateway NAT para a sub-rede do nó de trabalho. Isso acontecerá automaticamente.

Em termos de estação de trabalho de desenvolvedor, é necessária uma POSIX (macOS ou Linux) com oc e podman instalados.

Instruções detalhadas

São apenas três etapas:

1. Criar uma bifurcação

Primeiro, crie uma bifurcação do repositório GitHub de padrões validados na sua organização. Devido à consistência do Argo CD, não é seguro usar diretamente o repositório de padrões validados.

git clone https://github.com/(YOUR ORG}/coco-pattern.git

2. Gerar chaves aleatórias

Em seguida, gere os segredos de linha de base. O padrão inclui scripts para gerar chaves aleatórias:

sh scripts/gen-secrets.sh

3. Instalar

Faça login no cluster usando oc login e execute a instalação do padrão:

./pattern.sh make install

Pronto! Aguarde o sistema ficar online e navegue pelas aplicações implantadas.

Navegar pelas aplicações implantadas

O padrão implanta uma instância do Argo CD chamada Simple ArgoCD no menu de nove caixas no console web do OpenShift. Várias aplicações são implantadas. As duas aplicações mais importantes a considerar são: hello-openshift e kbs-access.

A aplicação hello-openshift implanta uma aplicação web três vezes: 

• como um pod padrão;
• como um pod Kata, no qual a configuração do agente é deliberadamente substituída para permitir que o usuário execute no pod; e
• como uma aplicação "segura" com reforço ativado para containers confidenciais.

A aplicação kbs-access é uma demonstração simples de como recuperar um segredo do Trustee usando "init container". Com o kbs-access, é possível acessar o segredo usando a API web dele. Assim, o usuário pode conferir como as alterações no segredo se propagam pelo sistema. O método "init container" para recuperar segredos é conveniente para aumentar a segurança das aplicações, já que permite fazer isso sem precisar do Trustee em todos os ambientes usados para desenvolver código.

Considerações de segurança na implantação de padrões para containers confidenciais 

O ponto central dos containers confidenciais é a segurança. Por isso, é importante considerar a postura de segurança do padrão validado. Há duas considerações principais sobre esse padrão:

• O padrão usa atualmente valores de referência simples. Leia sobre o fluxo de atestado RATS e desenvolva políticas adequadas às suas necessidades de segurança e ao perfil de risco do sistema.
• A implantação do Trustee deve ser separada. Na mesma linha do primeiro ponto, o serviço de atestado do Trustee é baseado no princípio de que ele opera em uma zona de segurança confiável diferente. O ideal é que seja em um ambiente diferente, como on-premise ou outro provedor de nuvem.

O diagrama abaixo mostra a arquitetura de implantação do Trustee em um ambiente separado, usando o padrão validado para containers confidenciais:

Trabalho futuro com padrões para containers confidenciais 

O padrão validado para containers confidenciais é tudo o que você precisa no início. O foco é primeiro ter sucesso com um único cluster e ambiente para você começar a fazer testes. Nosso foco imediato é expandir isso com exemplos mais práticos para você continuar sua jornada no uso de containers confidenciais.

Queremos oferecer suporte a implantações hub and spoke em vários clusters. Assim, o Trustee pode ser implantado no hub com o Red Hat Advanced Cluster Management e os clusters spoke onde as cargas de trabalho confidenciais são executadas.

Também pretendemos dar exemplos práticos de uso do Trustee para o gerenciamento de segredos. Os exemplos até agora são simples. Nossas prioridades para o desenvolvimento futuro são permitir a criptografia do armazenamento gerenciado em um TEE, a inicialização de segredo para aplicações que não reconhecem o Trustee e a configuração de VPN.

Além disso, queremos oferecer suporte para a implantação dos containers confidenciais e do Trustee em outros ambientes. Assim, outros recursos on-premise ou em vários provedores de serviços em nuvem poderão contar com essa confiança.

Resumo 

O padrão validado para containers confidenciais é um mecanismo simples para começar a usar esses containers. Ele é um excelente ponto de partida para a experimentação. Você pode bifurcar o padrão para implantar suas próprias aplicações autocontidas em um único repositório, usando uma abordagem padronizada GitOps app de apps com o Argo CD. Como demonstramos, começar essa jornada é muito simples, bastando um git clone e make install.