Soberanía de datos en infraestructura cloud native: cuando la geografía ya no alcanza

Introducción

En 2024, el 68% de las empresas europeas reportaron que al menos uno de sus proveedores de cloud estaba sujeto a leyes de acceso extraterritorial, como la CLOUD Act estadounidense o la Ley de Seguridad Nacional de China. El problema ya no es dónde está físicamente un servidor, sino quién puede obligar legalmente a un proveedor a entregar datos almacenados en él. Lo que comenzó como un debate de data residency derivó en un cambio estructural: la soberanía de datos pasó de ser una decisión geográfica a un requisito de control jurisdiccional y operacional.

Ejemplos recientes lo confirman:

• En junio de 2026, la UE propuso el Cloud and AI Development Act (CADA), que exige un marco de cuatro niveles de soberanía para la contratación pública de cloud.
• Canadá evalúa a sus proveedores de cloud en métricas como «residencia de datos canadiense» y «control jurisdiccional directo».
• La Ley de Datos de la UE (Data Act) y el Reglamento de IA introducen requisitos de interoperabilidad, trazabilidad y gobernanza que trascienden la ubicación física.

Para equipos de DevOps e infraestructura, esto significa que las decisiones técnicas ya no son solo de performance o costo, sino de cumplimiento normativo. La solución no pasa por evitar el cloud, sino por diseñar plataformas donde el control jurídico y el técnico converjan.

Qué ocurrió

De la geografía al control: las leyes que redefinieron la soberanía

Durante años, los proveedores de cloud vendieron soberanía como una cuestión de «elegir una región». Sin embargo, regulaciones como:

• CLOUD Act (EE.UU., 2018, actualizado en 2023):

– Afecta a gigantes como AWS, Azure y Google Cloud, cuyos datos pueden ser requeridos si su matriz está en EE.UU.

• Ley de Seguridad Nacional de China (2017, enmiendas en 2021 y 2025):

• NIS2 (UE, 2022, aplicación desde 2024) y DORA (UE, 2022, aplicación en 2025):

El impacto en la arquitectura cloud-native

Las empresas reguladas ya no pueden confiar en:

1. Regiones geográficas: Las leyes extraterritoriales anulan la protección de elegir un availability zone en la UE.
2. Contratos de confidencialidad: La CLOUD Act permite a los gobiernos acceder a datos incluso con cláusulas de no divulgación.
3. Dependencia de proveedores: Un vendor lock-in con un hyperscaler puede convertirse en un riesgo legal si ese proveedor está sujeto a leyes de otro país.

• Kubernetes para la orquestación y políticas de gobernanza.
• OpenStack como infraestructura autónoma y sin dependencias externas.
• GitOps para operar múltiples entornos jurisdiccionales con consistencia.
• Políticas como código para automatizar el cumplimiento.

Ejemplo concreto:

Una empresa de telecomunicaciones europea migra sus cargas de trabajo críticas a un stack basado en:

• Kubernetes 1.30 (con admission controllers para restringir pods a nodos en su jurisdicción).
• OpenStack Zed (para infraestructura bare metal y almacenamiento self-hosted).
• Kyverno para aplicar políticas de soberanía en tiempo real.

El resultado: cumple con CADA sin sacrificar escalabilidad ni automatización.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

DevOps: La soberanía como requisito operativo

Para los equipos de DevOps, la soberanía ya no es un checkbox de cumplimiento, sino un driver de diseño arquitectónico. Las implicaciones incluyen:

1. Multi-cluster vs. single-cluster:

– Ahora: Clusters separados por jurisdicción, cada uno con:

– Su propio control plane (evitando dependencia de un hyperscaler centralizado).

– Políticas de node affinity para evitar que un pod se schedulee fuera de su zona jurisdiccional.

– Namespaces aislados por región o unidad de negocio regulada.

– Según un informe de CNCF 2026, el 42% de las empresas europeas reguladas ya operan más de 5 clusters separados por requisitos de soberanía.

– El overhead de gestionar múltiples clusters se mitiga con GitOps (ver sección Qué deberían hacer).

1. Cadena de suministro y SBOMs:

– Herramientas como Cosign (para firmar imágenes) y Syft (para generar SBOMs) se integran en los pipelines de CI/CD.

– Ejemplo:

     # Ejemplo de política de Kyverno para requerir SBOM en imágenes
     apiVersion: kyverno.io/v1
     kind: ClusterPolicy
     metadata:
       name: require-sbom
     spec:
       validationFailureAction: enforce
       rules:
       - name: check-sbom-attached
         match:
           resources:
             kinds:
               - Pod
         validate:
           message: "La imagen debe tener un SBOM adjunto."
           pattern:
             spec:
               containers:
                 - image: "*"
                   imagePullSecrets:
                     - name: *sbom-present*
     

1. Resiliencia vs. dependencia:

– Un stack soberano reduce la exposición a:

– Sanciones comerciales (ej.: restricciones de exportación de tecnología).

– Cambios regulatorios (ej.: un hyperscaler decide dejar de operar en una región).

– Interrupciones por disputas legales (ej.: un proveedor es obligado a suspender servicios).

Cloud: La ilusión de la región ya no alcanza

Los proveedores de cloud tradicionalmente ofrecían «soberanía» como un feature premium. Sin embargo:

• AWS GovCloud (EE.UU.): Sujeta a la CLOUD Act.
• Azure Government (EE.UU.): Mismo riesgo.
• Google Cloud Assured Workloads: Depende de la jurisdicción de Alphabet Inc.

Empresas como Telefónica en España o Deutsche Bahn en Alemania están migrando a:

• OpenStack autohospedado (sin dependencia de licencias de hipervisores propietarios).
• Kubernetes on bare metal (evitando capas de virtualización externas).
• Redes definidas por software (SDN) con Neutron de OpenStack para aislamiento jurisdiccional.

Seguridad: De la auditoría manual a la automatización continua

Los modelos tradicionales de cumplimiento (documentación, revisiones manuales, checklists) no escalan en entornos cloud-native con cientos de workloads:

• Métrica: Según Help Net Security (2026), el 78% de las brechas de cumplimiento en cloud ocurren por falta de automatización en la aplicación de políticas.
• Solución: Políticas como código integradas en el control plane de Kubernetes.

# Política para restringir imágenes solo de registros soberanos
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: sovereign-image-repos
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    repos:
      - "registry.sovereign.example.com"
      - "ghcr.io/empresa-sov"
    excludedImages:
      - "ghcr.io/empresa-sov/dev-images/*"

• Trazabilidad total: Cada cambio de política queda registrado en Git.
• Ejecución inmediata: Las políticas se aplican antes de que un pod se schedulee.
• Reducción de falsos positivos: Las políticas se prueban en CI pipelines antes de llegar a producción.

Infraestructura: OpenStack como columna vertebral soberana

Kubernetes depende de una capa inferior de infraestructura:

• Banco nacional en Europa: Usa OpenStack para cumplir con CADA, evitando dependencia de hyperscalers.
• Operador ferroviario en Asia: Implementa federated learning para modelos de IA sin salir de su jurisdicción, usando Kubernetes + OpenStack.

Detalles técnicos

Kubernetes: Cómo los admission controllers y policy engines imponen soberanía

1. Restricción de nodos por jurisdicción:

   # Ejemplo de NodeAffinity para restringir pods a nodos en "EU-Central-1"
   apiVersion: v1
   kind: Pod
   metadata:
     name: app-eu
   spec:
     affinity:
       nodeAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
           - matchExpressions:
             - key: topology.kubernetes.io/zone
               operator: In
               values:
               - EU-Central-1
   

1. Prohibición de imágenes no verificadas:

1. Aislamiento de namespaces:

• Falco: Monitoreo de comportamientos sospechosos en tiempo real (ej.: un pod intentando acceder a recursos fuera de su jurisdicción).
• Trivy: Escaneo de vulnerabilidades en imágenes antes de su despliegue.

OpenStack: La infraestructura autónoma para soberanía

# Instalación de OpenStack Zed en bare metal (sin hipervisores)
sudo apt install openstack -y
sudo openstack configure --hypervisor none --network-backend neutron

# Configuración de clave para Keystone (sin dependencia de proveedores externos)
openstack domain create sovereign-domain
openstack project create sovereign-project --domain sovereign-domain
openstack user create sovereign-user --project sovereign-project --password-file /etc/keystone/sovereign-passwd

1. Sin telemetría obligatoria: OpenStack no envía datos a servidores externos.
2. Sin licencias proprietary: Ironic permite bare metal sin depender de VMware o Nutanix.
3. Control sobre firmware: OpenStack puede integrarse con herramientas como OpenBMC para verificar firmware de servidores.

GitOps: Operar múltiples jurisdicciones sin perder la cabeza

Repositorio Git (monorepo o multi-repo)
├── base/              # Configuración compartida
│   ├── kustomization.yaml
│   └── policies/
├── eu-sovereign/      # Overlay para UE
│   ├── cluster-config.yaml
│   └── gitops-controller.yaml
├── ca-sovereign/      # Overlay para Canadá
│   ├── cluster-config.yaml
│   └── rbac-policies.yaml
└── audit/             # Configuración para auditorías

• Argo CD o Flux: Sincronizan el estado deseado en cada cluster.
• SOPS o Sealed Secrets: Para gestionar secretos cifrados por jurisdicción.

1. Un cambio en base/policies/sovereign-requirements.yaml se propaga a todos los overlays.
2. Cada cluster valida y aplica el cambio localmente.
3. Sin control plane centralizado: Cada cluster es autónomo.

Qué deberían hacer los administradores y equipos técnicos

1. Auditar la exposición actual a leyes extraterritoriales

1. Listar todos los proveedores de cloud y SaaS usados por la organización.
2. Verificar su matriz corporativa:

1. Identificar cargas de trabajo críticas:

# Listar todos los clusters de Kubernetes y sus proveedores de cloud
kubectl get nodes -o wide | grep -E "provider-id|region"

2. Diseñar una arquitectura soberana en 3 capas

• Desplegar OpenStack Zed en bare metal (usando Ironic).
• Configurar Keystone sin dependencia de proveedores externos.
• Implementar Ceph para almacenamiento distribuido.

# Instalación rápida de OpenStack en bare metal (ejemplo para Ubuntu 24.04)
sudo apt update && sudo apt install -y openstack
sudo openstack-install --hypervisor none --network-backend neutron --storage-backend ceph

• Instalar Kubernetes 1.30+ en los nodos bare metal.
• Configurar admission controllers:

  # Habilitar PodSecurity admission en modo "enforce"
  apiVersion: apiserver.config.k8s.io/v1
  kind: AdmissionConfiguration
  plugins:
  - name: PodSecurity
    configuration:
      apiVersion: pod-security.admission.config.k8s.io/v1
      kind: PodSecurityConfiguration
      defaults:
        enforce: "restricted"
        enforce-version: "latest"
  

• Instalar Kyverno para políticas de soberanía:

  helm repo add kyverno https://kyverno.github.io/kyverno/
  helm install kyverno kyverno/kyverno -n kyverno --create-namespace
  

• Configurar Argo CD para gestionar múltiples clusters:

  helm repo add argo https://argoproj.github.io/argo-helm
  helm install argocd argo/argo-cd -n argocd --create-namespace
  

• Crear repositorios por jurisdicción (ej.: eu-sovereign, ca-sovereign).
• Definir políticas como código en Git:

  # Ejemplo de política de Kyverno para restringir regiones
  apiVersion: kyverno.io/v1
  kind: ClusterPolicy
  metadata:
    name: restrict-region
  spec:
    validationFailureAction: enforce
    rules:
    - name: check-node-affinity
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "El pod debe especificar nodeAffinity para una jurisdicción válida."
        pattern:
          spec:
            affinity:
              nodeAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  nodeSelectorTerms:
                    - matchExpressions:
                      - key: topology.kubernetes.io/zone
                        operator: In
                        values:
                          - EU-Central-1
                          - EU-West-1
  

3. Migrar cargas de trabajo críticas en fases

• Migrar un servicio no crítico (ej.: un backend de desarrollo) a un cluster soberano.
• Verificar:

– Que OpenStack provee los recursos necesarios (CPUs, RAM, almacenamiento).

• Usar velero para migrar workloads desde el cloud público al cluster soberano:

  velero install \
    --provider aws \
    --plugins velero/velero-plugin-for-aws:v1.0.0 \
    --bucket sovereign-backups \
    --backup-location-config region=eu-central-1
  

• Validar compliance:

– Generar reportes de SBOMs con Syft:

    syft alpine:latest -o spdx-json > sbom-alpine-latest.json
    

• Automatizar auditorías:

– Configurar Prometheus + Grafana para monitorear violaciones de políticas.

• Capacitar equipos:

4. Prepararse para requisitos futuros: Firmware y hardware soberano

1. Generar un Hardware Bill of Materials (HBOM):

– Herramientas: OpenBMC o Redfish.

1. Verificar firmware:

– Configurar TPM 2.0 para medición de integridad de arranque.

1. Auditar la cadena de suministro:

– Validar con herramientas como FOSSA o Dependency-Track.

Conclusión

La soberanía de datos ya no es un lujo, sino un requisito de resiliencia y cumplimiento. Las arquitecturas que triunfarán serán aquellas que:

1. Automaticen el control jurisdiccional (no solo geográfico).
2. Eliminen dependencias de proveedores externos (usando OpenStack + Kubernetes on bare metal).
3. Integren políticas como código en el control plane (Kyverno, OPA/Gatekeeper, GitOps).

Fuentes

• CNCF: How data sovereignty is changing cloud native infrastructure design (2026)
• Help Net Security: Regulatory pressures driving sovereign cloud adoption (2026)
• CNCF: Kubernetes Admission Controllers Deep Dive (2025)
• OpenStack Zed Release Notes (2024)
• EU Cloud and AI Development Act (CADA) Proposal (2026)