A soberania de uma plataforma cloud-native não é determinada apenas pelo local onde a carga de trabalho é executada ou os dados são armazenados. Segundo uma análise publicada pela CNCF em 18 de agosto de 2026 e escrita por Chamod Perera, embaixador da CNCF, e Suvin Kodituwakku, engenheiro de software sênior da WSO2, demonstrar a soberania também depende do local onde o estado de controle está, dos caminhos dos logs e dos metadados, das entidades capazes de acessar chaves e credenciais e da capacidade da equipe de continuar operando caso um serviço do fornecedor desapareça.
A análise propõe considerar a soberania como uma propriedade da topologia da plataforma, e não apenas como a escolha de uma região em uma lista de configurações. O OpenChoreo, uma plataforma interna de código aberto para desenvolvedores e um projeto em estágio Sandbox da CNCF, é usado como exemplo verificável dessa abordagem, com a ressalva de que os princípios arquitetônicos não se limitam a ele.
Quatro perguntas que vão além da localização dos servidores
O material afirma que as equipes de plataforma, diante de estruturas como o EU Data Act, o NIS-2, o DORA e o UK Data Use and Access Act, precisam responder a perguntas práticas que vão além da definição da região geográfica. A primeira é: sob qual jurisdição legal opera cada componente que pode tocar nos dados do locatário, incluindo o plano de controle e os logs? A segunda é: a equipe consegue operar, reconstruir e mover as cargas de trabalho se o serviço hospedado pelo fornecedor parar?
As outras duas perguntas dizem respeito à possibilidade de partes externas às fronteiras acessarem chaves, o estado dos clusters ou credenciais administrativas, e a se uma mudança de fornecedor, hardware ou país exigiria reescrever a carga de trabalho. A análise conclui que essas perguntas se concentram principalmente em onde estão o controle e o estado, e em quem tem capacidade de acessá-los.
Como funciona a arquitetura multinível?
O OpenChoreo divide a plataforma em clusters independentes, cada um com seu próprio ciclo de vida, limites de segurança e comportamento de escalabilidade:
- Nível de controle: mantém o estado desejado por meio de APIs declarativas e executa unidades de reconciliação, mas não executa as cargas de trabalho dos locatários.
- Níveis de dados: clusters Kubernetes compatíveis que executam efetivamente as cargas de trabalho, cada um com seu próprio servidor de API e estado.
- Níveis de monitoramento: coletam e disponibilizam logs, métricas e traces.
- Níveis de fluxo de trabalho: executam operações de CI e GitOps.
- Nível de experiência: fornece o portal do desenvolvedor, a CLI, APIs e MCP.
O elemento mais importante é o modelo de comunicação. Os níveis de dados, monitoramento e fluxo de trabalho abrem conexões de saída com autenticação mútua por mTLS para o gateway do nível de controle, enquanto o nível de controle não inicia conexões com eles. Assim, os servidores de API dos clusters que hospedam cargas de trabalho regulamentadas não ficam expostos à internet. Além disso, o nível de controle mantém o estado desejado, não o estado operacional completo do locatário; por isso, o nível de dados consegue continuar atendendo às solicitações mesmo quando perde a conexão com o nível de controle.
O que muda na prática para as equipes de plataforma?
Cada nível de dados pode ser associado a uma jurisdição legal específica, tornando o modelo “uma jurisdição, um nível de dados” passível de revisão e auditoria. Cada nível de dados também envia seus dados operacionais para um nível regional de monitoramento, em vez de encaminhar logs e traces pelo nível de controle. Dessa forma, as cargas de trabalho dos locatários e suas medições permanecem dentro das fronteiras regionais definidas.
A capacidade de continuar operando longe do fornecedor depende de cada nível de dados ser um cluster Kubernetes completo e compatível, e não um endpoint gerenciado e fechado. A análise menciona o uso de componentes de código aberto do ecossistema CNCF e cloud-native, como Argo Workflows, Cloud Native Buildpacks, OpenSearch, Prometheus, OpenTelemetry, Flux, cert-manager e Cilium. A arquitetura modular permite substituir um componente ou conectar um sistema de monitoramento existente usando a mesma interface de consulta.
A proteção de segredos e chaves é deixada para um armazenamento compatível com o External Secrets Operator ou para um cofre escolhido pela entidade operadora, em vez de impor uma propriedade padrão das chaves. Também é possível aplicar permissões granulares no nível de namespaces, projetos e componentes, vinculando grupos a qualquer provedor de identidade OAuth2/OIDC, seja o solicitante um desenvolvedor, uma ferramenta CLI ou um agente de inteligência artificial.
Integração dos clusters virtuais com os níveis da plataforma
Esse modelo não elimina o padrão de cluster do locatário; ele o complementa. O cluster virtual oferece a cada locatário um plano de controle virtual, um servidor de API e um armazenamento próprios dentro de um cluster host compartilhado, isolando o estado de controle entre os locatários a um custo menor do que um cluster dedicado para cada um. No entanto, ele não determina sozinho em qual jurisdição o locatário deve ser hospedado, para onde os logs devem ser enviados ou quem tem permissão para promover a carga de trabalho entre dois ambientes ou regiões.
É nesse ponto que a camada da plataforma acrescenta controles de distribuição e operação. Um recurso DataPlane pode carregar uma etiqueta de jurisdição legal e associar o recurso observabilityPlaneRef a um nível regional de monitoramento, enquanto os caminhos de promoção definem os ambientes entre os quais a carga de trabalho pode se mover. O portal do desenvolvedor também oferece caminhos prontos que reduzem a necessidade de conceder aos usuários acesso direto aos clusters sensíveis.
Essa combinação, porém, tem um limite claro: os locatários que estão no mesmo host compartilham o nó e o kernel do sistema operacional. Se o modelo de ameaça exigir isolamento de hardware para cada locatário, o cluster virtual não será suficiente, e será necessário um nível de dados físico independente.
Soberania como configuração declarativa e auditável
A análise propõe representar a topologia por meio de recursos Kubernetes declarativos e mantê-la no Git: qual região usa qual nível de dados, qual destino recebe os dados de monitoramento e quais caminhos de promoção são permitidos. Assim, criar uma nova jurisdição torna-se uma solicitação de mesclagem (pull request) passível de revisão, e a resposta sobre por que os dados de um locatário estão em determinada região passa a se basear em um registro de alterações, não em uma captura de tela de um painel de controle.
Mesmo assim, a arquitetura multinível não altera a jurisdição legal da entidade que opera a infraestrutura nem elimina sua exposição aos sistemas jurídicos aos quais está sujeita. Ela também traça as fronteiras, mas não impõe por si só políticas sobre o que acontece dentro delas; a atestação da cadeia de suprimentos, a SBOM, o registro de auditoria e a identidade das cargas de trabalho por meio de ferramentas como SPIFFE/SPIRE continuam sendo controles separados que precisam ser integrados.
O custo operacional é a última limitação: cada cluster adicional precisa de monitoramento, atualização e backup. Portanto, a arquitetura se justifica quando as fronteiras traçadas têm peso jurídico ou de segurança real, e pode se tornar excessiva em ambientes que não precisam disso. Em conclusão, a combinação de clusters de locatários para isolar recursos, uma arquitetura multinível para definir o que pode atravessar as fronteiras e configurações declarativas gerenciáveis por versão transforma a soberania de uma promessa contratual em uma propriedade que pode ser operada e auditada.