De resiliência de dados à soberania digital: padrões arquiteturais para plataformas cloud native

De resiliência de dados à soberania digital: padrões arquiteturais para plataformas cloud native

TL;DR: Regulamentações como EU Data Act e NIS-2 exigem mais que apenas localização de workloads — exigem controle sobre control planes, chaves criptográficas e auditoria. O padrão de tenant clusters (ex.: vCluster) permite criar limites de soberania por jurisdição com control planes isolados, portabilidade de workloads e redução do blast radius. Para empresas brasileiras que operam sob LGPD ou precisam atender clientes europeus, esse é um caminho arquitetural mais operacional que provisionar clusters físicos por região.

Nos últimos dois anos, a soberania digital evoluiu de uma discussão de política pública para uma preocupação prática de platform engineering. O EU Data Act está em plena aplicação desde 11 de janeiro de 2025. NIS-2 e DORA já moldam decisões de plataforma no dia a dia em setores regulados, e o Data Use and Access Act 2025 do Reino Unido está sendo implementado ao longo de 2026 com regras de portabilidade que têm impacto real.

Como resultado, os times de plataforma estão sendo cada vez mais solicitados a demonstrar não apenas onde as workloads rodam, mas também como a infraestrutura é operada, protegida e governada. Perguntas sobre control planes, chaves de criptografia, acesso administrativo, auditabilidade e portabilidade de workloads agora aparecem lado a lado com os requisitos tradicionais de data residency.

Para organizações que constroem plataformas cloud native, isso levanta um desafio arquitetural importante. Embora a infraestrutura regional continue sendo uma consideração relevante, muitos requisitos de soberania dependem, em última análise, de como o controle, o acesso e a responsabilidade operacional são distribuídos ao longo da stack da plataforma.

Este artigo explora como plataformas baseadas em Kubernetes podem atender a esses requisitos e por que o design do control plane está se tornando uma parte cada vez mais importante da conversa sobre soberania.

O que "soberania" realmente exige de uma plataforma?

Quando você decompõe o que reguladores, auditores e times de procurement continuam pedindo, quatro propriedades aparecem repetidamente:

• Contenção jurisdicional. Todo componente que pode ler dados do tenant, incluindo o control plane, roda sob uma jurisdição legal que a organização pode nomear e defender.
• Autonomia operacional. O time que opera a workload pode reconstruí-la, migrá-la e auditá-la sem depender de serviços gerenciados de um único vendor.
• Controle criptográfico e de acesso. Chaves, conteúdo do etcd e credenciais de admin não são acessíveis a uma entidade fora da jurisdição escolhida.
• Portabilidade. Se o hardware subjacente, o provedor ou o país precisar mudar, a workload se move sem reescrita.

Para construtores de nuvens soberanas, estas não são apenas caixas de regulamentação. Localização do control plane, armazenamento de metadados, acesso administrativo, criptografia e propriedade da gestão de chaves precisam ser explicitamente definidos, junto com estratégias de backup e modelos de acesso de suporte que respeitem o limite jurisdicional. Nada disso é resolvido com "escolhemos Frankfurt". É resolvido com escolhas de infraestrutura que vão até o control plane.

Por que um único cluster Kubernetes é insuficiente?

Ao construir uma plataforma soberana, esses requisitos rapidamente se tornam inevitáveis, com o Kubernetes servindo como a peça central que os une e fornece o substrato adequado para plataformas soberanas. O backing da CNCF, APIs declarativas e um ecossistema aberto (Kyverno para policy, Argo CD e Flux para GitOps, KubeVirt para VMs, Cilium para rede, SPIFFE/SPIRE para identidade de workloads) são exatamente os blocos de construção para os quais as empresas reguladas locais estão convergindo. A arquitetura de referência Kubernetes soberana da Swisscom publicada em architecture.cncf.io é um sinal claro de para onde a indústria está caminhando.

No momento em que você começa a mapear requisitos reais de soberania em um único cluster, as lacunas aparecem:

• Um control plane atende a todos os tenants. Um incidente jurisdicional afetando o data plane de um tenant corre o risco de afetar todos que compartilham o API server, etcd e controllers.
• Namespaces não são isolados. Mesmo com RBAC forte, CRDs são compartilhados, admission webhooks são compartilhados, e um controller mal configurado vaza pelo cluster.
• Cluster sprawl é o plano B usual. Um cluster Kubernetes completo por jurisdição, por ambiente, por time. Operacionalmente pesado, caro e lento para mudar.

Na prática, operadores frequentemente rodam plataformas compartilhadas que suportam múltiplos ambientes regulados simultaneamente, cada um com seus próprios requisitos operacionais, de compliance e de residência.

Por exemplo, um provedor pode operar ambientes de tenant separados para UE e Reino Unido, cada um apoiado por sua própria infraestrutura regional, armazenamento e limites de auditoria, como abaixo:

Pic: Sovereign Design, which isn't Sovereign ( From Sovereign: What It Means )

O desafio com o acima é que a colocação da workload sozinha não estabelece soberania. Mesmo que as workloads dos tenants rodem em regiões separadas, um control plane Kubernetes compartilhado ainda centraliza a autoridade administrativa, a aplicação de políticas, as APIs, os controllers e as principais decisões operacionais. Onde quer que esse control plane resida e quem quer que o governe, define, em última análise, o verdadeiro limite de soberania da plataforma.

Tenant clusters como primitivo de soberania

O padrão que vale a pena aprender aqui é o tenant cluster: um control plane Kubernetes isolado para um único limite de isolamento, rodando sobre um cluster subjacente compartilhado. Cada tenant cluster tem seu próprio API server, seu próprio controller manager, seu próprio scheduler e seu próprio data store. Da perspectiva da workload, ela está falando com um cluster Kubernetes real e conforme. Da perspectiva da plataforma, o control plane do tenant cluster roda como um conjunto de pods em um Control Plane Cluster compartilhado.

Uma forma popular de implementar esse padrão é o vCluster, um projeto open source que provisiona tenant clusters como pods dentro de um cluster Kubernetes existente. Vamos usá-lo como exemplo ao longo do restante deste post porque é fácil de testar localmente, mas as ideias arquiteturais se aplicam a qualquer coisa que dê a cada limite de isolamento seu próprio control plane.

Algumas propriedades dos tenant clusters são diretamente relevantes para a soberania.

Control planes independentes. Cada tenant cluster tem seu próprio API server e seu próprio backing store (etcd embutido, etcd externo ou um banco SQL). CRDs, admission webhooks e logs de auditoria de um tenant não vazam para o outro. Control planes separados também significam versões separadas do Kubernetes, ciclos de upgrade separados e variação na stack da plataforma por tenant, o que se torna mais importante quanto mais tenants você tiver. Um limite jurisdicional no nível do cluster se torna significativo.

Backing store plugável. O estado do tenant cluster pode viver em volumes criptografados em hardware que você controla, sob o operador que você escolher. A residência do estado, não apenas a residência da workload, torna-se algo que você pode projetar.

Isolamento de tenant, não namespaces multi-tenant. Workloads dentro de um tenant cluster não conseguem acessar a API do cluster subjacente. Para um isolamento de runtime mais forte na camada de contêiner, uma abordagem comum é emparelhar o tenant cluster com um runtime baseado em user-namespace, como o vNode, ou com gVisor ou Kata Containers onde um limite de VM é necessário. Isso é particularmente importante para operadores de nuvem de IA, onde o modelo de ameaça geralmente combina preocupações com container-escape com a necessidade de impedir que tenants observem as workloads uns dos outros em hardware compartilhado.

Portabilidade de workload. Um tenant cluster expõe uma API Kubernetes conforme. Workloads dentro dele são portáveis para qualquer Kubernetes conforme, gerenciado ou auto-gerenciado. Mover de um cluster subjacente apoiado por hyperscaler para um provedor soberano, ou para bare metal, não requer reescrita da workload.

O padrão que emerge é direto. Times de plataforma executam um pequeno número de clusters Kubernetes subjacentes, e tenants, jurisdições ou workloads reguladas recebem seus próprios tenant clusters. Limites de soberania tornam-se objetos de primeira classe que você pode declarar, auditar e mover, como no exemplo a seguir com vCluster:

Em termos de arquitetura, isso geralmente significa um control plane cluster subjacente por jurisdição soberana ou datacenter, com tenant clusters isolados provisionados para clientes dentro desse limite.

Por exemplo, um control plane cluster da UE pode atender exclusivamente tenants residentes na UE, enquanto um control plane cluster separado do Reino Unido atende independentemente clientes do Reino Unido. Este modelo permite que cada tenant execute seu próprio control plane Kubernetes sem exigir um cluster físico completo por cliente.

Um padrão prático: jurisdição como cluster

Considere uma empresa SaaS atendendo clientes na UE e no Reino Unido. Sob o EU Data Act, dados de clientes, logs de auditoria e metadados para tenants residentes na UE devem permanecer sob jurisdição da UE e ser portáveis. Clientes do Reino Unido caem sob o Data Use and Access Act 2025, um regime paralelo, mas não idêntico. O mesmo produto, dois limites de soberania.

Uma maneira limpa de expressar isso é um tenant cluster por jurisdição, declarado como recursos Kubernetes e gerenciado por GitOps. A forma é a mesma independentemente de qual ferramenta você usar: um recurso customizado descreve a localização do tenant cluster, o backing store e a postura de política, e um controller reconcilia isso.

As restrições que precisam estar em algum lugar nesse recurso são:

• Um node selector ou restrição de topologia que fixa cada pod no tenant cluster a nodes rotulados com a jurisdição correta, aplicada como uma restrição rígida no nível do control plane do tenant, em vez de deixada para o bom comportamento.
• Um backing store para o próprio estado do tenant cluster (seu etcd ou equivalente SQL) que viva na jurisdição escolhida. Os dados do control plane, os objetos da API, os secrets, não devem transitar por um serviço gerenciado não jurisdicional.
• Um sink de audit log local à jurisdição, para que o fluxo de auditoria do tenant cluster nunca cruze o limite que o regulador se preocupa.
• Um pacote de políticas (Kyverno ou OPA Gatekeeper) carregado no tenant cluster que aplique residência, proveniência de imagem e requisitos de SBOM de dentro.

Um tenant cluster do Reino Unido parece estruturalmente idêntico, com rótulos diferentes, um backing store diferente e um destino de auditoria diferente. Adicionar uma nova jurisdição é um pull request, não uma construção de cluster.

A definição completa vive no Git. A trilha de auditoria para "por que os dados do tenant X estão na jurisdição Y" é um histórico de commits, não uma captura de tela de um console.

Reduzindo o blast radius de um incidente de soberania

A conversa sobre soberania geralmente se concentra na residência. A propriedade mais difícil é o que acontece quando algo dá errado: uma intimação, um controller mal configurado, uma credencial vazada.

Tenant clusters reduzem o blast radius de maneiras concretas.

Uma solicitação ao estilo CLOUD Act contra o operador do cluster subjacente não produz automaticamente o conteúdo do etcd de um tenant cluster se esse backing store viver com um operador local à jurisdição. O alvo legal e o alvo técnico são desacoplados por design.

Um admission webhook comprometido no tenant cluster da UE não consegue alcançar o tenant cluster do Reino Unido, porque eles não compartilham um control plane. O webhook vive inteiramente dentro do API server de um tenant cluster.

Um upgrade de CRD em toda a plataforma é escalonado por tenant cluster. Você pode executar Kubernetes 1.34 em uma jurisdição e 1.33 em outra enquanto um regulador termina sua revisão de um CVE. A variação de versão se torna uma feature, não um problema.

Essas propriedades não são mágicas. Elas decorrem de dar a cada limite de soberania seu próprio control plane, e são muito difíceis de adaptar retroativamente a um único cluster compartilhado.

Bare metal, nuvens de IA e para onde isso está indo

O mesmo padrão se compõe para baixo. Se o requisito é soberania de hardware, não apenas soberania do operador, o próprio cluster subjacente pode rodar em bare-metal provisionado com Metal3 e Ironic (ou ferramentas de nível superior como Tinkerbell) ou camadas como vMetal. Os tenant clusters então herdam esse limite de hardware por construção. Nenhuma parte da stack roda em infraestrutura fora da jurisdição escolhida. O guia Sovereign AI Cloud on Bare Metal GPUs percorre o que isso parece de ponta a ponta para uma build pesada em GPU.

Isso é particularmente importante para a onda de nuvem de IA. Workloads pesadas em GPU têm sido o argumento mais forte para a dependência de hyperscalers, e também são as workloads mais expostas sob os requisitos de logging e governança do Artigo 12 do EU AI Act. Um padrão de clusters subjacentes com GPU em bare metal soberano, com tenant clusters por cliente ou por jurisdição que obtêm acesso a GPU através de Dynamic Resource Allocation, dá aos times de plataforma de IA uma resposta crível tanto para "onde o treinamento roda?" quanto para "quem pode subpoena os pesos?".

Isso não é hipotético. A Polarise, um provedor alemão de nuvem soberana de IA, é um exemplo de operador executando exatamente essa forma em produção: capacidade de GPU compartilhada por baixo, um tenant cluster por cliente por cima, tudo sob jurisdição da UE. O operador muda, o padrão é o mesmo.

O que isso não resolve

Vale a pena ser honesto sobre os limites.

O padrão de tenant cluster não muda a jurisdição legal do operador que executa o cluster subjacente. Se uma empresa sediada nos EUA opera o Kubernetes subjacente, a exposição ao CLOUD Act para esse operador permanece. O padrão reduz e particiona a exposição, não a elimina. Para workloads onde a jurisdição do operador é o próprio modelo de ameaça, você ainda precisa de um operador soberano em hardware soberano, com o padrão de tenant cluster por cima.

Este padrão também não substitui o restante da stack soberana da CNCF. Você ainda precisa de um policy engine como Kyverno ou OPA Gatekeeper, um pipeline de SBOM (a Cyber Resilience Act não vai esperar), um pipeline de audit log, uma camada de identidade de workload como SPIFFE/SPIRE e um GitOps controller. Tenant clusters são um primitivo, não uma plataforma. Frameworks como DORA e SecNumCloud 3.2 tornam isso explícito: o limite do tenant cluster é uma entrada para resiliência operacional e controles de soberania, não a resposta inteira.

Ref: vCluster DORA Infographic

E clusters por tenant têm um custo operacional. Cada um é um control plane real para monitorar, fazer upgrade e fazer backup. O benefício só justifica o custo quando o limite que você está desenhando tem peso legal ou de risco real. Um tenant cluster por cliente é overkill para um free tier. Um tenant cluster por jurisdição com alguns clientes regulados em cada um é exatamente a forma para a qual este padrão foi feito.

A forma de uma plataforma soberana em 2026

Juntando os fios, as plataformas que passam nas auditorias de 2026 tendem a se parecer com isto:

Um pequeno número de clusters Kubernetes subjacentes, em infraestrutura soberana onde o modelo de ameaça exigir. Tenant clusters por jurisdição, por workload regulada ou por cliente regulado, cada um com seu próprio control plane, declarado em Git, implantado via Argo CD ou Flux. Políticas aplicadas por Kyverno ou Gatekeeper no cluster subjacente e por tenant dentro de cada tenant cluster. Logs de auditoria transmitidos para sinks locais à jurisdição, nunca cruzando o limite que o regulador se preocupa. Workloads escritas contra APIs Kubernetes simples, portáveis entre clusters subjacentes à medida que procurement, geopolítica e disponibilidade de hardware mudam.

Soberania neste modelo não é uma cláusula de procurement. É um objeto no cluster, com um nome, um template e um histórico de commits. Essa é a forma que os reguladores estão começando a esperar, e a forma que os times de plataforma podem realmente operar.

Perguntas Frequentes

• O que exatamente diferencia um tenant cluster de um namespace isolado no Kubernetes?

  • Um tenant cluster tem seu próprio API server, controller manager, scheduler e armazenamento (etcd). Namespaces compartilham o mesmo control plane, o que significa que CRDs, admission webhooks e logs de auditoria vazam entre tenants. Com tenant clusters, cada limite de soberania ganha isolamento real de control plane.

• Esse padrão funciona para provedores de IA que treinam modelos com GPUs em nuvem?

  • Sim. O padrão é descrito no guia Sovereign AI Cloud on Bare Metal GPUs: clusters subjacentes com GPUs em hardware soberano, e tenant clusters por cliente ou jurisdição acessando GPUs via Dynamic Resource Allocation. Isso dá uma resposta crível tanto para 'onde o treinamento roda?' quanto para 'quem pode subpoena os pesos?'.

• Tenant clusters resolvem completamente a exposição ao CLOUD Act dos EUA?

  • Não. O padrão reduz e particiona a exposição, mas não a elimina. Se a operadora do cluster subjacente for uma empresa americana, a exposição ao CLOUD Act permanece. Para workloads onde a jurisdição do operador é o próprio modelo de ameaça, é necessário um operador soberano em hardware soberano, com o padrão de tenant clusters por cima.

• Qual é o custo operacional de adotar esse padrão?

  • Cada tenant cluster é um control plane real para monitorar, fazer upgrade e backup. O custo só se justifica quando o limite tem peso legal ou de risco real. Um tenant cluster por cliente é overkill para um free tier; um tenant cluster por jurisdição com poucos clientes regulados dentro é o cenário ideal para esse padrão.

• Esse padrão substitui outras ferramentas de segurança como Kyverno ou OPA Gatekeeper?

  • Não. Tenant clusters são um primitivo, não uma plataforma completa. Você ainda precisa de um policy engine (Kyverno ou OPA Gatekeeper), pipeline de SBOM, audit log pipeline, camada de workload identity (SPIFFE/SPIRE) e GitOps controller. O tenant cluster é um insumo para resiliência operacional e controles de soberania — não a resposta inteira.

---

Artigo originalmente publicado por Hrittik Roy, CNCF Ambassador em Cloud Native Computing Foundation.