0Pricing
Cyber Security Academy · Lección

Seguridad de pods y políticas de red

Aísle las cargas de trabajo.

Seguridad de pods y políticas de red es una lección gratuita de Cyber Security Academy en CoddyKit. Esta es la lección 3 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 Cyber Security Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Cyber Security Academy incluye 4 lecciones en total.

Aislamiento de cargas de trabajo

Dos controles limitan lo que puede hacer un pod comprometido: Pod Security restringe los privilegios de un pod, y Network Policies restringen qué pods pueden comunicarse entre sí. Juntos limitan el radio de impacto.

  • Pod Security impide los escapes hacia el nodo.
  • Network Policies impiden el movimiento lateral entre pods.

Configuraciones peligrosas de los pods

Varios campos de la especificación de un pod amplían considerablemente el riesgo si se permiten.

  • privileged: true concede un acceso casi equivalente al del host.
  • hostPID, hostNetwork y hostIPC rompen el aislamiento de los namespaces.
  • Los volúmenes hostPath montan directorios del nodo.
  • Las capacidades añadidas, como SYS_ADMIN, permiten escapar.
  • Ejecutarse como root (runAsUser: 0).

Pod Security Admission

Pod Security Admission (PSA) sustituyó a PodSecurityPolicy. Aplica tres estándares integrados en cada namespace.

  • Privileged: sin restricciones (evítelo para las cargas de trabajo).
  • Baseline: bloquea las escaladas de privilegios conocidas.
  • Restricted: práctica recomendada de endurecimiento (sin root, sin privilegios y con las capacidades eliminadas).
# Enforce the restricted standard on a namespace
kubectl label namespace prod \
  pod-security.kubernetes.io/enforce=restricted

Un securityContext reforzado

Defina el principio de mínimo privilegio en los niveles del pod y del contenedor mediante un securityContext.

  • Ejecute como un usuario no root y use un sistema de archivos raíz de solo lectura.
  • Elimine todas las capacidades de Linux y añada únicamente las necesarias.
  • Impida la escalada de privilegios.
# securityContext fields (YAML)
# runAsNonRoot: true
# readOnlyRootFilesystem: true
# allowPrivilegeEscalation: false
# capabilities: drop: [ALL]
kubectl apply -f hardened-deploy.yaml

Más allá de los estándares: motores de políticas

Para aplicar reglas más completas que las de PSA, los controladores de admisión aplican políticas personalizadas.

  • OPA Gatekeeper evalúa restricciones de Rego.
  • Kyverno usa políticas YAML y puede mutar además de validar.

Estas herramientas pueden prohibir hostPath, exigir imágenes firmadas o imponer etiquetas en todo el clúster.

# Apply a Kyverno policy that disallows privileged pods
kubectl apply -f disallow-privileged.yaml

Redes abiertas de forma predeterminada

De forma predeterminada, todos los pods pueden comunicarse con todos los demás pods de todos los namespaces. No hay segmentación hasta que se añaden Network Policies. Esta red plana explica por qué un solo pod comprometido puede explorar y atacar todo el clúster.

# From a pod, the flat network lets you reach any service
curl http://internal-db.prod.svc.cluster.local:5432

Conceptos básicos de Network Policies

Network Policies son reglas limitadas a un namespace que seleccionan pods y permiten entradas y salidas específicas. Son aditivas: aplicar cualquier política a un pod lo cambia a denegación predeterminada para la dirección cubierta.

  • Los selectores coinciden con los pods mediante etiquetas.
  • Las reglas permiten tráfico desde o hacia pods, namespaces o CIDR específicos.
  • Se requiere un CNI compatible con políticas (Calico, Cilium).

Denegar de forma predeterminada y permitir después

El patrón recomendado consiste en establecer una base de denegación predeterminada por namespace y, después, reglas explícitas de permiso para los flujos necesarios.

# Default-deny all ingress in a namespace (YAML)
# kind: NetworkPolicy spec: podSelector: {} policyTypes: [Ingress]
kubectl apply -f default-deny.yaml

# Then allow only frontend -> backend
kubectl apply -f allow-frontend.yaml

Bloqueo de salidas y metadatos

Las políticas de salida son tan importantes como las de entrada.

  • Restrinja a qué endpoints externos pueden acceder los pods (limita la exfiltración y el C2).
  • Bloquee la IP de metadatos de la nube 169.254.169.254 desde los pods para impedir el robo de credenciales del nodo.
  • Limite el DNS y el tráfico interno este-oeste.

Defensa en tiempo de ejecución

Las políticas estáticas se complementan con la detección en tiempo de ejecución.

  • Falco alerta sobre llamadas al sistema sospechosas (un shell en un contenedor, montajes sensibles).
  • Los perfiles de seccomp restringen las llamadas al sistema que puede realizar un contenedor.
  • AppArmor/SELinux añaden control de acceso obligatorio en el nodo.
# Apply the runtime/default seccomp profile (securityContext)
# seccompProfile: type: RuntimeDefault
kubectl apply -f seccomp-deploy.yaml

Pruebas de aislamiento

Al validar el aislamiento, intente realizar conexiones entre pods y utilizar mecanismos de escape desde un pod de prueba, y confirme que las políticas los bloquean. Hágalo en un namespace controlado y elimine los pods de prueba después.

Informe de cualquier pod que se ejecute con privilegios o de cualquier namespace que carezca de denegación predeterminada, incluyendo la corrección exacta del manifiesto.

Comprobación rápida

Confirme sus conocimientos sobre el aislamiento.

Repaso

Ha aprendido a aislar las cargas de trabajo.

  • Pod Security Admission (restricted) y securityContext bloquean los escapes.
  • Gatekeeper/Kyverno aplican políticas de admisión personalizadas.
  • La red está abierta de forma predeterminada; aplique una denegación predeterminada y, después, permisos explícitos.
  • Las reglas de salida, el bloqueo de metadatos y Falco proporcionan una defensa adicional.

A continuación: protección de la cadena de suministro y los secretos.

Preguntas frecuentes

¿La lección «Seguridad de pods y políticas de red» es gratis?

Sí — el texto completo de «Seguridad de pods y políticas de red» 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 Cyber Security Academy, actualiza a CoddyKit PRO. El curso de Cyber Security Academy incluye 4 lecciones en total.

¿Qué aprenderé en «Seguridad de pods y políticas de red»?

Aísle las cargas de trabajo. Practicas Cyber Security Academy 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 Cyber Security Academy?

No se requiere experiencia previa. Cyber Security Academy 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 3 de 4.

¿Cuánto tiempo toma la lección «Seguridad de pods y políticas de red»?

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 Cyber Security Academy?

Sí. Cada lección de Cyber Security Academy 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. Modelo de amenazas de Kubernetes
  2. RBAC y cuentas de servicio
  3. Seguridad de pods y políticas de red
  4. Protección de la cadena de suministro y secretos
← Volver a Cyber Security Academy