Arquitecturas soberanas en Kubernetes: cómo cumplir con soberanía digital sin sacrificar escalabilidad

Introducción

En 2025, el EU Data Act entró en vigor el 11 de enero, mientras que la NIS-2 y la DORA ya moldeaban decisiones diarias en sectores regulados. Para diciembre de 2026, el UK Data Use and Access Act 2025 completará su implementación con reglas estrictas de portabilidad. Estas normativas no solo exigen dónde corren las cargas, sino cómo se opera la infraestructura: quién controla el control plane, cómo se gestionan las claves de cifrado, qué auditorías se aplican y si los metadatos permanecen bajo una jurisdicción específica.

El problema central es que muchos equipos interpretan «soberanía» como elegir una región geográfica (ej.: Frankfurt). Sin embargo, reguladores y auditores piden demostraciones concretas de:

• Control sobre el control plane: quién administra el API Server, el etcd, los Controller Managers y los Admission Controllers.
• Aislamiento de metadatos: dónde se almacenan logs, políticas de red, y registros de auditoría.
• Portabilidad de cargas: capacidad de mover un tenant entre proveedores sin reescribir configuraciones.
• Acceso administrativo: quién tiene permisos de superuser y cómo se audita.

Kubernetes es el sustrato ideal para cumplir estos requisitos, pero requiere patrones arquitectónicos que vayan más allá de la regionalización. La CNCF ya respalda esta tendencia: proyectos como Kyverno (políticas), Argo CD/Flux (GitOps), vCluster (clusters tenant), y Cilium (red) forman la base de plataformas soberanas en Europa y Reino Unido.

Qué ocurrió

El cambio de paradigma comenzó en 2024, cuando regulaciones como la NIS-2 (aplicable desde octubre de 2024) obligaron a sectores críticos (energía, transporte, salud) a auditar no solo la infraestructura, sino también los procesos de patch management y gestión de incidentes. Para 2025, el EU Data Act añadió requisitos de portabilidad y control de metadatos, mientras que el UK Data Use and Access Act extendió estas exigencias a proveedores de servicios digitales con usuarios británicos.

El detonante técnico fue la incapacidad de muchos equipos para responder preguntas como:

• «¿Dónde reside el etcd que almacena los secretos de este tenant?»
• «¿Quién puede escalar el Control Plane de este cluster?»
• «¿Cómo se auditan los cambios en políticas de red en producción?»

La respuesta no fue migrar a un proveedor «europeo», sino rediseñar la arquitectura para que cada tenant tenga su propio control plane aislado. Ejemplo concreto: un SaaS con clientes en la UE y el Reino Unido no puede compartir un solo cluster de Kubernetes si el etcd y los logs de auditoría deben residir en jurisdicciones distintas. La solución adoptada por empresas como Swisscom (publicado en architecture.cncf.io) es implementar clusters tenant con sus propios API Servers, etcd y Controller Managers, pero alojados en un cluster subyacente compartido.

Impacto para DevOps, Infraestructura y Seguridad

Para equipos de DevOps

La adopción de tenant clusters introduce desafíos operativos:

• Multiplicación de control planes: Cada tenant requiere su propia versión de Kubernetes (ej.: un tenant en EKS 1.28 y otro en OpenShift 4.14).
• GitOps como columna vertebral: Las declaraciones de los tenant clusters (ubicación del etcd, políticas de cifrado, jurisdicciones) deben vivir en Git y ser reconciliadas automáticamente. Herramientas como Flux o Argo CD son esenciales para evitar drift.
• Overhead de actualizaciones: Parchear un API Server por CVE como CVE-2024-4064 (afecta a Kubernetes 1.28.x) ahora implica actualizar cada tenant cluster individualmente.

Para equipos de Seguridad

La soberanía digital exige:

• Aislamiento de secretos: Cada tenant cluster debe usar su propio Key Management Service (KMS). Ejemplo: con KMS de AWS, se asigna un CMK por tenant y se configura en el etcd mediante el flag --encryption-provider-config.
• Políticas de red obligatorias: Herramientas como Cilium (con su motor eBPF) permiten filtrar tráfico entre tenants a nivel de kernel, evitando fugas de metadatos.
• Auditoría unificada: Los logs de todos los control planes deben centralizarse en un SIEM (ej.: Grafana Loki o Elasticsearch) con retención acorde a la regulación (ej.: 5 años para NIS-2).

Para equipos de Cloud e Infraestructura

Las decisiones de diseño impactan en:

• Costos: Un tenant cluster en vCluster consume ~1/3 de recursos vs. un cluster físico (según benchmarks de CNCF, 2025).
• Latencia: El API Server de un tenant cluster alojado en un cluster subyacente en otra región añade ~15ms de RTT (medido con kube-bench en entornos GKE).
• Portabilidad: Los tenant clusters son 100% compatibles con cualquier distribución de Kubernetes (EKS, AKS, OpenShift, RKE2), pero requieren que los Custom Resource Definitions (CRDs) sean estándar.

Detalles técnicos

Componentes clave y versiones afectadas

La implementación típica sigue este patrón:

1. Cluster subyacente: Un cluster Kubernetes compartido (ej.: EKS en eu-central-1) con:

– Red: Cilium con políticas de red estrictas (ej.: denegar tráfico entre namespaces de distintos tenants).

– GitOps: Flux sincronizando declaraciones desde un repositorio Git privado.

1. Provisión del tenant cluster: Se declara un CRD de vCluster en el cluster subyacente:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: eu-tenant-1
   ---
   apiVersion: vcluster.loft.sh/v1alpha1
   kind: VirtualCluster
   metadata:
     name: eu-tenant-1
     namespace: eu-tenant-1
   spec:
     helmRelease:
       chart:
         name: vcluster
         repo: https://charts.loft.sh
         version: 0.16.0
     service:
       type: LoadBalancer
     sync:
       nodes:
         enabled: true
       ingresses:
         enabled: true
     backingStore:
       persistence:
         size: 10Gi
         storageClass: gp3-encrypted
         encryption:
           enabled: true
           kmsKeyId: arn:aws:kms:eu-central-1:123456789012:key/abcd1234-5678-90ef-ghij-klmnopqrstuv
     controlPlane:
       replicas: 3
       kubernetesVersion: "1.28.0"
   

1. Políticas de soberanía:

– Políticas de red: Kyverno aplica reglas como:

     apiVersion: kyverno.io/v1
     kind: ClusterPolicy
     metadata:
       name: block-cross-tenant-traffic
     spec:
       validationFailureAction: enforce
       rules:
       - name: block-between-tenants
         match:
           resources:
             kinds:
             - NetworkPolicy
         validate:
           message: "No se permite tráfico entre tenants."
           pattern:
             spec:
               podSelector: {}
               policyTypes:
               - Ingress
               ingress: []
     

1. Gestión de claves:

– El etcd se inicializa con cifrado en reposo:

     etcd --data-dir=/var/lib/etcd \
           --wal-dir=/var/lib/etcd/wal \
           --listen-client-urls=https://0.0.0.0:2379 \
           --listen-peer-urls=https://0.0.0.0:2380 \
           --name=eu-tenant-1 \
           --initial-advertise-peer-urls=https://$(hostname):2380 \
           --cert-file=/etc/etcd/pki/server.crt \
           --key-file=/etc/etcd/pki/server.key \
           --trusted-ca-file=/etc/etcd/pki/ca.crt \
           --client-cert-auth=true \
           --encryption-provider-config=/etc/etcd/encryption-config.yaml
     

Vectores de riesgo y cómo mitigarlos

1. Auditar la infraestructura actual

1. Listar todos los clusters Kubernetes y mapear:

– Proveedor de Key Management (¿usando el mismo KMS para todos los tenants?).

– Políticas de red (NetworkPolicies aplicadas).

   kubectl get pods -A -l component=etcd --field-selector=metadata.namespace!=kube-system
   kubectl get cm -A | grep encryption-config
   kubectl get np -A
   

1. Identificar violaciones:

– Si no hay políticas de red que bloqueen tráfico entre namespaces de distintos tenants, aplicar Cilium o Calico de inmediato.

2. Implementar tenant clusters con vCluster

1. Instalar vCluster en el cluster subyacente:

   helm repo add loft-sh https://charts.loft.sh
   helm install vcluster loft-sh/vcluster -n vcluster-system --create-namespace
   

1. Crear un tenant cluster para la UE:

   # eu-tenant-cluster.yaml
   apiVersion: vcluster.loft.sh/v1alpha1
   kind: VirtualCluster
   metadata:
     name: eu-tenant-production
     namespace: eu-tenants
   spec:
     helmRelease:
       chart:
         name: vcluster
         version: 0.16.0
     backingStore:
       persistence:
         storageClass: "gp3-encrypted"
         size: 20Gi
         encryption:
           enabled: true
           kmsKeyId: "arn:aws:kms:eu-central-1:123456789012:key/eu-tenant-key"
     sync:
       nodes:
         enabled: true
     controlPlane:
       replicas: 3
       kubernetesVersion: "1.28.0"
   

1. Aplicar con Flux:

   flux create source git eu-tenants \
     --url=https://github.com/empresa/soberania-manifests \
     --branch=main
   flux create kustomization eu-tenants \
     --source=GitRepository/eu-tenants \
     --path=./clusters/eu \
     --prune=true
   

3. Implementar políticas de soberanía con Kyverno

# sovereign-policies.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: sovereign-data-residency
spec:
  validationFailureAction: enforce
  background: true
  rules:
  - name: check-etcd-region
    match:
      resources:
        kinds:
        - ConfigMap
        names:
        - kube-apiserver
    validate:
      message: "El etcd debe residir en la UE para este tenant."
      pattern:
        metadata:
          labels:
            k8s-app: kube-etcd
        data:
          etcd-url: "https://etcd.eu-central-1.amazonaws.com:*"
  - name: enforce-tls-1.3
    match:
      resources:
        kinds:
        - Deployment
        names:
        - kube-apiserver
    validate:
      message: "TLS menor a 1.3 no permitido."
      pattern:
        spec:
          template:
            spec:
              containers:
              - name: kube-apiserver
                args:
                - --tls-min-version=1.3

4. Configurar auditoría unificada

Usar Grafana Loki para centralizar logs de todos los control planes:

# loki-values.yaml
loki:
  storage:
    filesystem:
      chunks_directory: /data/loki/chunks
  limits_config:
    retention_period: 720h # 30 días para NIS-2
    retention_stream:
    - selector: '{namespace="eu-tenant-production"}'
      priority: 1
      period: 8760h # 1 año

5. Validar el diseño

• [ ] Cada tenant cluster tiene su propio API Server (ver kubectl get endpoints -n eu-tenant-production kubernetes).
• [ ] Los secretos están cifrados con claves específicas por tenant (ver kubectl get secrets -A -o json | jq '.items[].metadata.annotations["encryption.k8s.io/key-id"]').
• [ ] Las políticas de red bloquean tráfico entre tenants (probar con curl entre pods de distintos namespaces).
• [ ] Los logs de auditoría están centralizados y retienen datos por el período legal.

Conclusión

La soberanía digital ya no es un requisito de compliance abstracto, sino un constraint arquitectónico que exige rediseñar los cimientos de las plataformas cloud-native. Los equipos que adopten clusters tenant con sus propios control planes, políticas declarativas (Kyverno + GitOps) y aislamiento de secretos evitarán multas millonarias y ganarán flexibilidad para cumplir con regulaciones como EU Data Act, NIS-2 o UK Data Use Act.

El patrón no es complejo, pero requiere disciplina operativa: versionar cada tenant cluster, auditar cada cambio en políticas, y tratar las jurisdicciones como first-class citizens en la declaración de la plataforma. Herramientas como vCluster, Flux y Kyverno no son opcionales; son los bloques que permiten escalar soberanía sin sacrificar agilidad.

Fuentes

• CNCF Blog: From data residency to digital sovereignty
• Swisscom Sovereign Kubernetes Reference Architecture
• NIST Vulnerability Database: CVE-2024-4064
• Grafana Loki Retention Policies