Kubernetes Network Policies: Microsegmentación para cargas de trabajo en contenedores
Por defecto, en Kubernetes cualquier Pod puede comunicarse con cualquier otro. Las Network Policies cambian eso — le mostramos cómo.
El problema: Red plana
En un clúster Kubernetes estándar, cada Pod puede alcanzar a cualquier otro Pod, independientemente del Namespace. Esto es cómodo para los desarrolladores, pero una pesadilla para los equipos de seguridad.
Comprender las Network Policies
Las Network Policies son reglas de firewall nativas de Kubernetes a nivel de Pod. Definen qué tráfico está permitido; todo lo demás se bloquea (Default Deny).
- Ingress Policies: Controlan el tráfico entrante: ¿qué Pods pueden comunicarse con este Pod?
- Egress Policies: Controlan el tráfico saliente: ¿a dónde puede este Pod establecer conexiones?
- Basado en Labels: Las Policies seleccionan Pods mediante Labels, no mediante direcciones IP, de forma dinámica y nativa de Kubernetes.
Buenas prácticas
- Default Deny: Comience con una Policy que bloquee todo el tráfico y luego permita de forma selectiva.
- Aislamiento por Namespace: Separe los entornos (dev, staging, prod) a nivel de Namespace con Policies.
- Permitir DNS: No olvide permitir Egress al puerto 53 (DNS); de lo contrario, el Service Discovery dejará de funcionar.
- Plugin CNI: Asegúrese de que su plugin CNI soporte Network Policies. Calico y Cilium son recomendables.
Conclusión
Las Network Policies son imprescindibles para clústeres Kubernetes en producción. No tienen coste, se gestionan de forma declarativa y reducen drásticamente la superficie de ataque. En devRocks, forman parte de cada configuración de clúster.
¿Preguntas sobre este tema?
Le asesoramos con gusto sobre las tecnologías y soluciones descritas en este artículo.
ContactarSeit über 25 Jahren realisieren wir Engineering-Projekte für Mittelstand und Enterprise.
