Denegar por defecto

La denegación por defecto es una política con podSelector: {} (todos los pods del namespace) y los tipos que se quieren cerrar, sin ninguna regla de ingress ni de egress. Al seleccionar a todos y no permitir nada, deja cada pod aislado en esos sentidos. A partir de ahí, cada comunicación necesaria se abre con una política propia, y todas se suman.

Los tipos son independientes: una política con solo Ingress cierra la entrada y deja la salida como estaba.

Si se deniega la salida, los pods dejan de poder hablar con el servidor de nombres del clúster, y con él se cae cualquier llamada que use un nombre de servicio en lugar de una dirección. El fallo se parece a una avería de la aplicación: tiempos de espera al resolver. La política de salida casi siempre necesita una regla que permita el tráfico hacia el servidor de nombres, por UDP y por TCP, antes de abrir lo demás.

Abre los manifiestos de cada namespace y el extracto de registros posterior a la activación.

Una política de denegación que lleva un selector de etiquetas protege únicamente a los pods con esa etiqueta. Los demás siguen sin aislar, y a simple vista el namespace «tiene una política de denegación». Esta trampa es frecuente cuando se copia un manifiesto de otro lugar y se deja la etiqueta de origen.

El inventario que mantiene el equipo marca, namespace por namespace, si hay denegación de entrada y de salida. Un valor parcial significa que existe alguna, pero no cubre todo, y no es lo mismo que no tener ninguna.

En un namespace que hoy funciona sin políticas, activar la denegación por defecto de golpe corta todas las comunicaciones que nadie documentó. El orden seguro es el inverso: observar los flujos reales, escribir las políticas que los permiten, aplicarlas primero (no cambian nada mientras el pod no esté aislado) y por último activar la denegación.