Saltar al contenido principal

Capítulo 9.3 - Network Policies

Objetivos de Aprendizaje​

Al final de este capítulo, usted será capaz de:

  • Comprender qué son las Network Policies
  • Crear Network Policies para aislar el tráfico
  • Configurar reglas de ingress y egress
  • Utilizar selectors para seleccionar Pods
  • Implementar la segmentación de red
  • Comprender las limitaciones

Introducción​

Las Network Policies permiten controlar el tráfico de red entre los Pods en un clúster de Kubernetes. Proporcionan segmentación de red a nivel de aplicación.

¿Qué es una Network Policy?​

Una Network Policy define reglas que controlan el tráfico de red entre los Pods. Permite:

  • Autorizar o bloquear el tráfico ingress (entrante)
  • Autorizar o bloquear el tráfico egress (saliente)
  • Filtrar por namespace, labels o IPs

Importante: Las Network Policies requieren un CNI que las soporte (Calico, Cilium, etc.).

Comportamiento por Defecto​

Sin Network Policy​

Por defecto: Todos los Pods pueden comunicarse entre sí.

Con Network Policy​

Aislamiento: Solo el tráfico autorizado está permitido.

Ejemplo Básico​

Network Policy: Aislar un Namespace​

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  podSelector: {}  # Todos los Pods
  policyTypes:
  - Ingress
  - Egress

Resultado: No se permite ningún tráfico de ingress ni egress en el namespace production.

Network Policy: Autorizar el Tráfico Interno​

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-internal
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: production

Resultado: Solo se permite el tráfico proveniente del namespace production.

Selectors​

Pod Selector​

Seleccionar Pods específicos:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-network-policy
spec:
  podSelector:
    matchLabels:
      app: web
      tier: frontend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api

Resultado: Los Pods con app=web y tier=frontend solo pueden recibir tráfico de Pods con app=api.

Namespace Selector​

Seleccionar namespaces:

spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend

IP Block​

Seleccionar rangos de IPs:

spec:
  ingress:
  - from:
    - ipBlock:
        cidr: 192.168.1.0/24
        except:
        - 192.168.1.100/32

Ejemplo Completo: Aplicación Multi-Tier​

Arquitectura​

Network Policy: Frontend​

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-policy
  namespace: frontend
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from: []  # Permitir desde cualquier lugar (Internet vía Ingress)
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: backend
    ports:
    - protocol: TCP
      port: 80

Network Policy: Backend​

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: database
    ports:
    - protocol: TCP
      port: 5432

Network Policy: Database​

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-policy
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: backend
    ports:
    - protocol: TCP
      port: 5432
  egress: []  # No se permite tráfico saliente

Puertos y Protocolos​

Especificar los Puertos​

spec:
  ingress:
  - ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443
    - protocol: UDP
      port: 53

Port Range (según CNI)​

Algunos CNI soportan rangos de puertos:

spec:
  ingress:
  - ports:
    - protocol: TCP
      port: 8000-8999

Comandos Útiles​

Gestión​

# Crear una Network Policy
kubectl apply -f network-policy.yaml

# Ver las Network Policies
kubectl get networkpolicies
kubectl get netpol

# Detalles
kubectl describe networkpolicy frontend-policy

# Ver por namespace
kubectl get netpol -n production

Prueba​

# Probar la conectividad desde un Pod
kubectl exec -it test-pod -- curl http://api-service:8080

# Ver las reglas aplicadas (según CNI)
# Calico
calicoctl get networkpolicies

Limitaciones​

1. Soporte CNI​

No todos los CNI soportan Network Policies:

  • Soportan: Calico, Cilium, Weave Net, Antrea
  • No soportan: Flannel (básico)

2. Rendimiento​

Las Network Policies pueden impactar el rendimiento según el CNI.

3. Complejidad​

La gestión de muchas Network Policies puede volverse compleja.

Buenas Prácticas​

1. Inicio Progresivo​

Comenzar aislando los namespaces críticos, luego expandir.

2. Documentación​

Documentar las reglas de comunicación entre los servicios.

3. Pruebas​

Probar las Network Policies antes de aplicarlas en producción.

4. Monitoreo​

Supervisar las conexiones bloqueadas para detectar problemas.

5. Default Deny​

Utilizar una política "deny all" por defecto y luego autorizar explícitamente.

Resumen​

En este capítulo, usted ha aprendido:

Network Policy: Control del tráfico de red entre Pods
Comportamiento por defecto: Todos los Pods pueden comunicarse
Selectors: Pod, namespace, IP block
Ingress/Egress: Reglas para tráfico entrante y saliente
Ports: Especificar los puertos y protocolos permitidos
Casos de uso: Segmentación de red, aislamiento multi-tier
Limitaciones: Requiere un CNI compatible
Buenas prácticas: Inicio progresivo, default deny, pruebas

Próximos Pasos​

Capítulo 9.4: Pod Security Standards
Lab 9.3: Network Policies Avanzadas

Capítulo creado el: Diciembre 2024