El problema fundamental que aborda ReadyOn es la seguridad y el aislamiento de datos en entornos multi-inquilino de Kubernetes, donde la compartición de recursos introduce un modelo de amenaza significativamente diferente al de clústeres de un solo inquilino. Históricamente, Kubernetes no fue diseñado con los namespaces como un límite de seguridad estricto, lo que requiere capas adicionales para proteger datos sensibles de accesos no autorizados entre inquilinos. La necesidad de una solución robusta se agudiza en plataformas que manejan datos críticos para empresas Fortune 100, donde una brecha podría tener implicaciones regulatorias y de confianza severas.

La solución de ReadyOn, el modelo de las 'Cuatro Paredes', aborda esta deficiencia inherente al diseño de Kubernetes al implementar una estrategia de defensa en profundidad. En lugar de depender de una única capa de aislamiento, se construyen barreras independientes en diferentes niveles de la pila tecnológica. Esto eleva drásticamente el costo y la complejidad para un atacante que intente acceder a datos de otro inquilino, ya que requeriría superar múltiples mecanismos de seguridad simultáneamente, cada uno con una técnica de ataque fundamentalmente diferente.

Arquitectura del Sistema

La arquitectura de ReadyOn se articula en cuatro capas de aislamiento independientes, cada una operando en un nivel distinto de la pila. La 'Pared 1' es el aislamiento a nivel de namespace de Kubernetes, donde cada inquilino reside en un namespace dedicado con políticas estrictas de RBAC, cuotas de recursos y control de admisión. La consistencia se asegura mediante GitOps con Argo CD ApplicationSet, que genera todos los recursos necesarios a partir de una única entrada de configuración, garantizando una postura de seguridad idéntica para todos los inquilinos y corrigiendo automáticamente cualquier desviación del estado declarado.

La 'Pared 2' se enfoca en el aislamiento de cómputo. Karpenter provisiona pools de nodos dedicados y autoescalables para cada inquilino, utilizando una estrategia de 'dual-taint'. Cada nodo lleva un taint de identificación de inquilino y otro de tipo de carga de trabajo, y los pods deben tolerar ambos para ser programados, impidiendo la colocación de pods entre inquilinos. Un controlador de admisión valida que las toleraciones de los pods coincidan con la identidad del inquilino del namespace. Además, se aplican credenciales de nodo con alcance limitado (IMDSv2 con hop limit reducido) y roles IAM específicos por inquilino, restringiendo el impacto de un posible escape de contenedor.

La 'Pared 3' implementa aislamiento de red a nivel de Amazon VPC y Security Groups. Cada clúster Amazon Aurora de un inquilino está protegido por un Security Group que solo permite conexiones entrantes desde el Security Group asociado a los nodos de aplicación de ese mismo inquilino. Esto es una regla de red definida por software de AWS, independiente de Kubernetes. Las políticas de red de Kubernetes aplican un 'default-deny' para el tráfico entre namespaces. La VPC se segmenta en cuatro tiers (público, aplicación, base de datos, control plane) y el API server de EKS es privado, accesible solo vía VPN con OIDC y MFA.

Finalmente, la 'Pared 4' aborda el aislamiento de datos. Cada inquilino tiene un clúster Amazon Aurora dedicado, eliminando la necesidad de filtrado a nivel de fila en una base de datos compartida. Esto también permite el uso de claves de cifrado AWS KMS únicas por inquilino. Las cargas de trabajo utilizan credenciales de corta duración a través de IAM Roles for Service Accounts (IRSA), asumiendo roles IAM únicos y con alcance limitado al inquilino. La observabilidad (métricas, logs, trazas) también se segrega a backends dedicados por inquilino mediante OpenTelemetry.

Flujo de Aislamiento Multi-Inquilino (Ataque de Movimiento Lateral)

  1. 1 Pod Inquilino A Proceso no autorizado intenta acceder a recursos de Inquilino B
  2. 2 Pared 1: Aislamiento Namespace RBAC, Cuotas, Control de Admisión bloquean creación/modificación de recursos ...
  3. 3 Pared 2: Aislamiento Cómputo Karpenter dual-taint y validación de admisión impiden scheduling en nodos de ...
  4. 4 Pared 3: Aislamiento Red Security Groups de VPC y Network Policies default-deny bloquean conexiones TC...
  5. 5 Pared 4: Aislamiento Datos Aurora dedicado, IRSA, KMS por inquilino bloquean acceso a datos/secretos/obs...
  6. 6 Recursos Inquilino B Acceso denegado en todas las capas.
CapaTecnologíaJustificación
orchestration Amazon EKS Plataforma de orquestación de contenedores base para las cargas de trabajo multi-inquilino.
orchestration Kubernetes Namespaces Límite lógico primario para la segregación de inquilinos, base para otras capas de aislamiento. RBAC, Resource Quotas, Admission Control por namespace.
orchestration Karpenter Provisionamiento y autoescalado de nodos de cómputo dedicados por inquilino. vs Cluster Autoscaler Estrategia de dual-taint (tenant-identifier y workload-type).
networking Amazon VPC Security Groups Aislamiento de red a nivel de infraestructura, controlando el acceso a bases de datos entre inquilinos. Reglas de entrada/salida por Security Group de nodo de aplicación a Security Group de base de datos.
networking Kubernetes Network Policies Control de tráfico de red a nivel de pod/namespace, aplicando un modelo de 'default-deny'. Default-deny para tráfico inter-namespace.
storage Amazon Aurora Base de datos relacional dedicada por inquilino para garantizar el aislamiento de datos. vs Bases de datos compartidas con RLS Clústeres dedicados por inquilino, cifrado con AWS KMS por inquilino.
security IAM Roles for Service Accounts (IRSA) Provisión de credenciales de AWS de corta duración y con alcance limitado para cargas de trabajo. vs Credenciales de larga duración en pods Federación OIDC entre EKS e IAM, roles IAM únicos por inquilino.
security AWS Secrets Manager Almacenamiento seguro de secretos por inquilino, integrados con GitOps. vs Almacenamiento de secretos en Git Rutas de secretos con alcance de inquilino, External Secrets Operator.
observability OpenTelemetry Recopilación y enrutamiento de métricas, logs y trazas a backends de observabilidad dedicados por inquilino. Backends de observabilidad dedicados por inquilino.
orchestration Argo CD ApplicationSet Automatización de la provisión y gestión de recursos de Kubernetes mediante GitOps. vs Helm, Kustomize sin GitOps Generación de recursos de namespace, RBAC, Network Policies, Resource Quotas y secretos. 
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: tenant-applications
spec:
  generators:
  - list:
      elements:
      - tenant: acme-corp
        awsAccountId: "123456789012"
      - tenant: example-inc
        awsAccountId: "987654321098"
  template:
    metadata:
      name: '{{tenant}}-app'
      namespace: argocd
    spec:
      project: default
      source:
        repoURL: https://github.com/readyon/tenant-configs.git
        targetRevision: HEAD
        path: '{{tenant}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{tenant}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
---
Ejemplo simplificado de cómo un Argo CD ApplicationSet puede generar recursos de Kubernetes para un nuevo inquilino, incluyendo namespace, RBAC y Network Policies, a partir de una plantilla.
# Karpenter Provisioner para nodos de inquilino
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: tenant-acme-corp-frontend
spec:
  requirements:
    - key: kubernetes.io/arch
      operator: In
      values: ["amd64"]
    - key: kubernetes.io/os
      operator: In
      values: ["linux"]
    - key: karpenter.sh/capacity-type
      operator: In
      values: ["on-demand"]
    - key: tenant
      operator: In
      values: ["acme-corp"]
    - key: workload
      operator: In
      values: ["frontend"]
  taints:
    - key: tenant
      value: acme-corp
      effect: NoSchedule
    - key: workload
      value: frontend
      effect: NoSchedule
  # ... otros campos de Karpenter
---
# Pod de aplicación con tolerations
apiVersion: v1
kind: Pod
metadata:
  name: acme-corp-frontend-pod
  namespace: acme-corp
spec:
  containers:
  - name: app
    image: myapp:latest
  tolerations:
  - key: tenant
    operator: Equal
    value: acme-corp
    effect: NoSchedule
  - key: workload
    operator: Equal
    value: frontend
    effect: NoSchedule
  # ... otros campos del Pod
Ejemplo de cómo un Pod de Kubernetes se configura con tolerations para ser programado en nodos con taints específicos de inquilino y tipo de carga de trabajo, y cómo un Karpenter Provisioner define estos taints.

Fundamentos Teóricos

El concepto de 'defensa en profundidad' (defense-in-depth) es un principio de seguridad bien establecido que se remonta a estrategias militares y ha sido adoptado en la informática. Implica la aplicación de múltiples capas de controles de seguridad para proteger los activos, de modo que si una capa falla, otra pueda mitigar la amenaza. Este principio fue formalizado en el contexto de la seguridad de sistemas por autores como Saltzer y Schroeder en su seminal paper 'The Protection of Information in Computer Systems' (1972), donde describen la necesidad de múltiples mecanismos de protección para lograr un sistema seguro.

La estrategia de ReadyOn de combinar aislamiento a nivel de namespace, cómputo, red y datos refleja directamente este principio. Cada 'pared' representa una capa de control independiente, diseñada para ser superada con una técnica diferente. Esto se alinea con la idea de que la seguridad no es un punto único de fallo, sino una composición de barreras que incrementan la dificultad para un atacante. La elección de bases de datos dedicadas por inquilino, en lugar de una base de datos compartida con filtrado a nivel de fila, también se relaciona con el principio de 'mínimo privilegio' y la reducción de la superficie de ataque, ya que elimina la posibilidad de errores lógicos en la aplicación que podrían llevar a la divulgación de datos entre inquilinos.