0Pricing
DevOps Bootcamp · Lección

Network Policies para el aislamiento

Controle el flujo de tráfico de red entre Pods y namespaces mediante Network Policies de Kubernetes.

Network Policies para el aislamiento es una lección gratuita de DevOps Bootcamp en CoddyKit. Esta es la lección 2 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de DevOps Bootcamp, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de DevOps Bootcamp incluye 4 lecciones en total.

Políticas de red: agentes de tráfico

En Kubernetes, los Pods pueden comunicarse libremente entre sí de forma predeterminada. Esto ofrece gran flexibilidad, pero no siempre es lo ideal para la seguridad.

Las políticas de red actúan como firewalls para sus Pods y controlan qué tráfico de red se permite entrante (ingress) y saliente (egress).

De forma predeterminada: todos los Pods pueden comunicarse

De forma predeterminada, una vez implementado un Pod, puede comunicarse con cualquier otro Pod del clúster, independientemente del namespace. Este modelo de «red plana» simplifica la configuración, pero carece de aislamiento.

En entornos de producción, a menudo es necesario restringir la comunicación para mejorar la seguridad y evitar accesos no autorizados entre los componentes de la aplicación.

Reglas de ingress y egress

Las políticas de red definen reglas para determinar cómo pueden comunicarse los Pods. Se centran principalmente en dos tipos de tráfico:

  • Ingress: Tráfico entrante a un Pod.
  • Egress: Tráfico saliente de un Pod.

Estas reglas se aplican a Pods específicos mediante etiquetas y pueden dirigirse a otros Pods, namespaces o bloques de IP.

Requisito del plugin CNI

¡Las políticas de red no son magia! Para que funcionen, su clúster de Kubernetes debe tener un plugin de Container Network Interface (CNI) que las admita.

Plugins de CNI populares como Calico, Cilium y Weave Net proporcionan esta funcionalidad. Sin un CNI compatible, las políticas de red no tendrán ningún efecto.

Anatomía de una política

Las políticas de red se definen mediante YAML. Entre los campos clave se incluyen:

  • metadata.name: Un nombre único para la política.
  • spec.podSelector: Selecciona los Pods a los que se aplica esta política.
  • spec.policyTypes: Especifica si la política se aplica a Ingress, Egress o a ambos.
  • spec.ingress/spec.egress: Enumera las reglas para el tráfico permitido.

Bloquear todo el tráfico entrante

Vamos a crear una política para denegar todo el tráfico entrante a los Pods con la etiqueta app: backend en el namespace actual. Este es un punto de partida habitual para una postura de seguridad de «denegación predeterminada».

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-backend-ingress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress: [] # An empty ingress list denies all incoming traffic

Permitir ingress desde el frontend

Ahora vamos a modificar nuestra política para permitir tráfico entrante únicamente desde Pods con la etiqueta app: frontend del mismo namespace hacia nuestros Pods app: backend.

Observe la sección from, que especifica los Pods de origen.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Controlar el tráfico saliente

Al igual que el ingress, puede controlar el tráfico egress (saliente). Aquí crearemos una política que permita a los Pods app: backend realizar solicitudes salientes únicamente a Pods con la etiqueta app: database.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress-to-db
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database

Dirigirse a otros namespaces

¿Qué ocurre si su frontend está en un namespace diferente, por ejemplo web-apps? Puede utilizar namespaceSelector para seleccionar Pods de otros namespaces.

Esta política permite el ingress a los Pods app: backend desde cualquier Pod del namespace web-apps.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-apps-ingress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: web-apps
      podSelector: {} # All pods in the selected namespace

Desafío sobre políticas

Considere un Pod con las etiquetas app: web y env: prod. ¿Qué política de red permitiría únicamente tráfico entrante desde Pods del namespace monitoring?

Repaso: proteja su red

¡Buen trabajo! Ha aprendido cómo las políticas de red de Kubernetes proporcionan un aislamiento de red fundamental para sus aplicaciones.

  • Actúan como firewalls para los Pods.
  • Controlan el tráfico ingress (entrante) y egress (saliente).
  • Requieren un plugin de CNI que las admita.
  • Se definen mediante YAML con podSelector, policyTypes y definiciones de reglas.
  • Pueden seleccionar Pods mediante etiquetas e incluso namespaces completos.

¡Utilícelas para aplicar un modelo de red basado en el «mínimo privilegio»!

Preguntas frecuentes

¿La lección «Network Policies para el aislamiento» es gratis?

Sí — el texto completo de «Network Policies para el aislamiento» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de DevOps Bootcamp, actualiza a CoddyKit PRO. El curso de DevOps Bootcamp incluye 4 lecciones en total.

¿Qué aprenderé en «Network Policies para el aislamiento»?

Controle el flujo de tráfico de red entre Pods y namespaces mediante Network Policies de Kubernetes. Practicas DevOps Bootcamp con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar DevOps Bootcamp?

No se requiere experiencia previa. DevOps Bootcamp en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 2 de 4.

¿Cuánto tiempo toma la lección «Network Policies para el aislamiento»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de DevOps Bootcamp?

Sí. Cada lección de DevOps Bootcamp incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Control de acceso basado en roles (RBAC)
  2. Network Policies para el aislamiento
  3. Estándares de seguridad de los Pods
  4. Cuentas de servicio e identidad de cargas de trabajo
← Volver a DevOps Bootcamp