¿Cómo limitar la interacción entre aplicaciones que trabajan en diferentes espacios de nombres?

Políticas de Red: Determinan qué conjuntos de pods están permitidos para interactuar entre sí y con endpoints externos. Se aplican a nivel de Namespace, Pod o Egress.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: default # Namespace al que se aplica la política
spec:
  podSelector: {} # Se aplica a todos los pods en el Namespace 'default'
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector: {} # Permite tráfico entrante desde pods en el mismo Namespace
  // No hay sección egress, lo que por defecto bloquea todo el tráfico saliente
  // Excepto en los casos que se permiten explícitamente.

Service Meshes (por ejemplo, Istio, Linkerd): Introducen sidecar containers en los pods y gestionan el tráfico de red a nivel de aplicaciones. Permiten implementar políticas de seguridad, incluyendo restricciones en la interacción entre Namespaces.

• Mutual TLS (mTLS): Cifra y autentica todo el tráfico entre servicios.
• Políticas de Autorización: Determinan qué servicios pueden interactuar entre sí basándose en la identidad.

SecurityContextConstraints (SCC) específicas de Namespace en OpenShift: Restringen las capacidades de los pods en Namespace específicos, afectando las capacidades de red.

Cluster separado para diferentes Zonas de Seguridad: Método más estricto, pero también el más costoso. Aísla completamente las aplicaciones que operan en diferentes clusters.

Reglas de Firewall: Configuración de reglas a nivel de infraestructura de red (por ejemplo, AWS Security Groups, GCP Firewall Rules), que permiten o bloquean tráfico entre subredes donde se encuentran los Worker Nodes de diferentes Namespaces.

Segmentación de Red a nivel de Hipervisor: Se usa en entornos de máquinas virtuales, donde cada Namespace o grupo de Namespaces se ubica en una subred separada con reglas de enrutamiento y firewall correspondientes.