La soberanía de una plataforma nativa de la nube no está determinada únicamente por el lugar donde se ejecuta una carga de trabajo o se almacenan sus datos. Según un análisis publicado por la CNCF el 18 de agosto de 2026 y escrito por Chamod Perera, embajador de la CNCF, y Suvin Kodituwakku, ingeniero sénior de software en WSO2, demostrar la soberanía también depende de dónde reside el estado de control, de las rutas de los registros y los metadatos, de las entidades capaces de acceder a las claves y las credenciales, y de la capacidad del equipo para seguir operando si desaparece un servicio del proveedor.
El análisis propone considerar la soberanía como una propiedad de la topología de la plataforma, no simplemente como la elección de una región en una lista de configuración. Utiliza OpenChoreo, una plataforma interna de código abierto para desarrolladores y un proyecto en fase Sandbox de la CNCF, como ejemplo examinable de este enfoque, y subraya que los principios arquitectónicos no se limitan a ella.
Cuatro preguntas que van más allá de la ubicación de los servidores
El artículo sostiene que, ante marcos como la EU Data Act, NIS-2, DORA y la UK Data Use and Access Act, los equipos de plataformas deben responder preguntas prácticas que van más allá de identificar la región geográfica. La primera es: ¿bajo qué jurisdicción legal opera cada componente que puede tocar datos del inquilino, incluidos el nivel de control y los registros? La segunda es: ¿puede el equipo ejecutar, reconstruir y trasladar las cargas de trabajo si deja de estar disponible el servicio alojado del proveedor?
Las otras dos preguntas se refieren a si partes externas a las fronteras pueden acceder a las claves, al estado de los clústeres o a las credenciales de administración, y a si cambiar de proveedor, hardware o país exige reescribir la carga de trabajo. El análisis concluye que estas preguntas se centran principalmente en dónde residen el control y el estado, y quién tiene capacidad para acceder a ellos.
¿Cómo funciona la arquitectura multinivel?
OpenChoreo divide la plataforma en clústeres independientes, cada uno con su propio ciclo de vida, límites de seguridad y comportamiento de escalado:
- Nivel de control: conserva el estado deseado mediante API declarativas y ejecuta los reconciliadores, pero no ejecuta las cargas de trabajo de los inquilinos.
- Niveles de datos: clústeres de Kubernetes compatibles que ejecutan realmente las cargas de trabajo, cada uno con su propio servidor de API y estado.
- Niveles de observabilidad: recopilan y sirven registros, métricas y trazas.
- Niveles de flujos de trabajo: ejecutan operaciones de CI y GitOps.
- Nivel de experiencia: proporciona el portal del desarrollador, una CLI y API y MCP.
El elemento más importante es el modelo de comunicación. Los niveles de datos, observabilidad y flujos de trabajo abren conexiones salientes y autenticadas mutuamente mediante mTLS hacia la puerta de enlace del nivel de control, mientras que el nivel de control no inicia conexiones hacia ellos. De este modo, los servidores de API de los clústeres que alojan cargas de trabajo reguladas no quedan expuestos a Internet. Además, el nivel de control conserva el estado deseado, no el estado operativo completo del inquilino; por eso, el nivel de datos puede seguir atendiendo solicitudes incluso cuando se pierde la conexión con el nivel de control.
¿Qué cambia en la práctica para los equipos de plataformas?
Cada nivel de datos puede vincularse a una jurisdicción legal específica, de modo que el modelo «una jurisdicción, un nivel de datos» sea revisable y auditable. Cada nivel de datos también envía sus datos operativos a un nivel de observabilidad regional, en lugar de hacer pasar los registros y las trazas por el nivel de control. Así, las cargas de trabajo de los inquilinos y sus métricas permanecen dentro de los límites regionales definidos.
La capacidad de continuidad al margen del proveedor depende de que cada nivel de datos sea un clúster completo y compatible de Kubernetes, no un punto final gestionado y cerrado. El análisis señala el uso de componentes de código abierto del ecosistema CNCF y nativo de la nube, como Argo Workflows, Cloud Native Buildpacks, OpenSearch, Prometheus, OpenTelemetry, Flux, cert-manager y Cilium. La arquitectura modular permite sustituir un componente o conectar un sistema de observabilidad existente utilizando la misma interfaz de consulta.
La protección de secretos y claves se deja en manos de un almacén compatible con External Secrets Operator o de un almacén de secretos elegido por la entidad operadora, en lugar de imponer una propiedad predeterminada de las claves. También pueden aplicarse permisos detallados a nivel de espacios de nombres, proyectos y componentes, vinculando los grupos a cualquier proveedor de identidad OAuth2/OIDC, ya se trate de un desarrollador, una herramienta CLI o un agente de inteligencia artificial.
Integración de clústeres virtuales con los niveles de la plataforma
Este modelo no elimina el patrón de clúster por inquilino, sino que lo complementa. El clúster virtual proporciona a cada inquilino un nivel de control virtual, un servidor de API y un almacén propios dentro de un clúster anfitrión compartido, lo que aísla el estado de control entre inquilinos a un coste inferior al de dedicar un clúster a cada uno. Sin embargo, por sí solo no determina la jurisdicción en la que debe alojarse el inquilino, dónde se envían los registros ni quién tiene autorización para promover la carga de trabajo entre dos entornos o regiones.
Aquí, la capa de la plataforma añade controles de distribución y operación. Un recurso DataPlane puede incluir la etiqueta de la jurisdicción legal y vincular un recurso observabilityPlaneRef a un nivel de observabilidad regional, mientras que las rutas de promoción determinan los entornos entre los que puede trasladarse la carga de trabajo. El portal del desarrollador también ofrece rutas prediseñadas que reducen la necesidad de conceder a los usuarios acceso directo a clústeres sensibles.
Sin embargo, esta combinación tiene un límite claro: los inquilinos ubicados en el mismo anfitrión comparten el nodo y el núcleo del sistema operativo. Si el modelo de amenazas exige aislamiento de hardware para cada inquilino, el clúster virtual no será suficiente y se necesitará un nivel de datos físico independiente.
La soberanía como configuración declarativa y auditable
El análisis propone representar la topología mediante recursos declarativos de Kubernetes y conservarlos en Git: qué región utiliza cada nivel de datos, qué destino recibe los datos de observabilidad y qué rutas de promoción están permitidas. Así, crear una nueva jurisdicción se convierte en una solicitud de incorporación de cambios (pull request) revisable, y la respuesta a por qué los datos de un inquilino se encuentran en una región determinada se basa en un registro de cambios, no en una captura de pantalla de un panel de control.
No obstante, la arquitectura multinivel no modifica la jurisdicción legal de la entidad que opera la infraestructura ni elimina su exposición a los sistemas jurídicos a los que está sujeta. También traza los límites, pero por sí sola no impone políticas sobre lo que ocurre dentro de ellos; la certificación de la cadena de suministro, la SBOM, el registro de auditoría y la identidad de las cargas de trabajo mediante herramientas como SPIFFE/SPIRE siguen siendo controles independientes que deben integrarse.
El coste operativo constituye la última limitación: cada clúster adicional necesita observabilidad, actualización y copias de seguridad. Por ello, la arquitectura está justificada cuando los límites trazados tienen un peso legal o de seguridad real, y puede resultar excesiva en entornos que no lo necesitan. En conclusión, combinar clústeres por inquilino para aislar recursos, una arquitectura multinivel para determinar qué puede cruzar las fronteras y configuraciones declarativas gestionables mediante control de versiones transforma la soberanía de una promesa contractual en una propiedad que puede operarse y auditarse.