Esta página demuestra cómo usar las políticas de red de clúster para controlar si un pod puede recibir tráfico de red entrante (o de ingreso) y si puede enviar tráfico saliente (o de egreso).
Las políticas de red le permiten limitar las conexiones entre objetos Pod, de modo que pueda reducir la exposición a ataques.
Las políticas de red actúan como un firewall en las capas 3 y 4 del modelo OSI . No ofrecen funciones adicionales como autorización o cifrado.
Restringir el tráfico entrante a los objetos Pod
Un objeto NetworkPolicy
permite configurar políticas de acceso a la red para un pod. Los objetos NetworkPolicy
contienen la siguiente información:
Objetos de pod a los que se aplica la política. Se definen objetos de pod y cargas de trabajo con etiquetas y selectores .
Tipo de tráfico al que afecta la política de red: entrada para tráfico entrante, salida para tráfico saliente o ambos.
Para las políticas de Ingress, qué objetos Pod pueden conectarse a los objetos Pod especificados.
Para las políticas de salida, los objetos Pod a los que se pueden conectar los objetos Pod especificados.
Ejemplo de restricción de tráfico entrante
Esta sección muestra la creación de una restricción de tráfico entrante en una aplicación de ejemplo. Modifique este ejemplo para adaptarlo a su entorno de aplicación.
Ejecute una aplicación de servidor web con la etiqueta
app=hello
y expóngala internamente en el clúster:kubectl run hello-web --labels app=hello \ --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 \ --port 8080 --expose
Configure una
NetworkPolicy
para permitir el tráfico al podhello-web
únicamente desde los objetos del podapp=foo
. GKE en AWS bloquea el tráfico entrante de objetos del pod que no tienen esta etiqueta, así como el tráfico externo y el tráfico de objetos del pod en un espacio de nombres diferente.El siguiente manifiesto selecciona objetos Pod con la etiqueta
app=hello
y especifica una política de ingreso para permitir el tráfico solo desde objetos Pod con la etiquetaapp=foo
:Aplicar esta política al clúster:
kubectl apply -f hello-allow-from-foo.yaml
Verificar la política de Ingress
Ejecute un pod temporal con la etiqueta
app=foo
. Para verificar que se permita el tráfico entrante, realice una solicitud al punto finalhello-web:8080
:kubectl run -l app=foo --image=alpine --restart=Never --rm -i -t foo-app \ -- wget -qO- --timeout=2 http://hello-web:8080
Si el tráfico desde
app=foo
a los objetos Podapp=hello
está habilitado, la salida se verá así:Hello, world! Version: 1.0.0 Hostname: hello-web-2258067535-vbx6z
Ejecute un Pod temporal con una etiqueta diferente (
app=other
) y realice la misma solicitud para observar que el tráfico no está permitido:kubectl run -l app=other --image=alpine --restart=Never --rm -i -t other-app \ -- wget -qO- --timeout=2 http://hello-web:8080
La salida confirma que la conexión no recibe una respuesta:
wget: download timed out
Restringir el tráfico saliente de los objetos Pod
Puedes restringir el tráfico saliente del mismo modo que lo harías con el tráfico entrante.
Sin embargo, para consultar nombres de host internos como hello-web
o nombres de host externos como www.example.com
, debe crear una política de salida que permita el tráfico DNS en el puerto 53 mediante los protocolos TCP y UDP.
Para habilitar las políticas de red de salida, implemente una NetworkPolicy
que controle el tráfico saliente de los objetos Pod con la etiqueta app=foo
mientras permite el tráfico solo a los objetos Pod con la etiqueta app=hello
, así como el tráfico DNS.
El siguiente manifiesto especifica una NetworkPolicy
que controla el tráfico de salida de los objetos Pod con la etiqueta app=foo
con dos destinos permitidos:
- Objetos Pod en el mismo espacio de nombres con la etiqueta
app=hello
- Puntos finales internos o externos en el puerto 53 (UDP y TCP)
Aplicar esta política al clúster:
kubectl apply -f foo-allow-to-hello.yaml
Validar la política de salida
Implemente una nueva aplicación web llamada
hello-web-2
y expóngala internamente en el clúster:kubectl run hello-web-2 --labels app=hello-2 \ --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 --port 8080 --expose
Ejecute un Pod temporal con la etiqueta
app=foo
y valide que el Pod pueda establecer conexiones ahello-web:8080
:kubectl run -l app=foo --image=alpine --rm -i -t --restart=Never foo-app \ -- wget -qO- --timeout=2 http://hello-web:8080
El Pod responde a la solicitud:
Hello, world! Version: 1.0.0 Hostname: hello-web-2258067535-vbx6z
Validar que el Pod no pueda establecer conexiones con
hello-web-2:8080
:kubectl run -l app=foo --image=alpine --rm -i -t --restart=Never foo-app \ -- wget -qO- --timeout=2 http://hello-web-2:8080
La salida confirma que la conexión no recibe una respuesta:
wget: download timed out
Valide que el Pod no pueda establecer conexiones a sitios web externos como
www.example.com
.kubectl run -l app=foo --image=alpine --rm -i -t --restart=Never foo-app \ -- wget -qO- --timeout=2 http://www.example.com
La salida confirma que la conexión no recibe una respuesta:
wget: download timed out
Limpiar
Para eliminar los recursos que creó en este tutorial, ejecute estos comandos:
kubectl delete pods --labels app=hello-2
kubectl delete pods --labels app=hello
kubectl delete -f foo-allow-to-hello.yaml
kubectl delete -f hello-allow-from-foo.yaml
¿Qué sigue?
- Documentación de políticas de red de Kubernetes
- Utilice el registro de políticas de red para registrar cuándo las políticas de red de su clúster permiten o deniegan las conexiones a objetos Pod.