Directiva de Firewall Contrail
En el capítulo 4, se le ha dado la Kubernetes a Contrail cifra de asignación de objetos, que Figure 1se repite aquí.
Esta asignación destaca Contrail’implementación de los objetos principales de Kubernetes: Espacio de nombres, conjunto Pod, servicio, entrada y Directiva de red. En los capítulos 4 a 7’, nos Encuestamos todo lo Figure 1 que se encuentra en la red, salvo en las políticas de redes.
En este capítulo nos’centramos en la implementación de la Directiva de red en contrail. ’En primer lugar, presentamos el contrail firewall, que es la característica que se utiliza para implementar la Directiva de red Kubernetes; ’a continuación, establecemos un caso de prueba para comprobar cómo funciona Kubernetes la Directiva de red en contrail; a continuación, según los resultados de las pruebas’, exploramos las políticas de Firewall contrail y sus reglas en detalle para poder comprender la contrail implementación, así como la asignación entre los dos objetos en el diagrama de asignación de Figure 1objetos de.
Introducción a Firewall Contrail
En el capítulo 3, se presentó el concepto de directiva de red Kubernetes. Lo hicimos detalladamente a través de la definición del archivo YAML y creamos una directiva de red basada en ella. También’se mencionó que la creación de objetos de políticas de’red se consiguió t? s efecto, a menos que la implementación de redes Kubernetes lo permita. Contrail, como Kubernetes CNI, implementa las redes Kubernetes y admite la Directiva de red Kubernetes a través de Firewall de Contrail. Este es el enfoque de este capítulo:’demostraremos cómo funciona la Directiva de red en el entorno contrail a través de contrail Firewall.
’Primero, revise algunos conceptos importantes en contrail.
Enrutamiento inter-VN.
En Contrail, las redes virtuales se aíslan de forma predeterminada. Esto significa que las cargas de trabajo en VN1 no pueden comunicarse con cargas de trabajo en otro VN2. Para permitir las comunicaciones de la red intervirtual entre VN1 y VN2, se requiere Contrail Directiva de red. Contrail Directiva de red también puede proporcionar seguridad entre dos redes virtuales al permitir o denegar el tráfico especificado.
Contrail Directiva de red.
Se usa una directiva de red Contrail para permitir la comunicación entre redes virtuales y modificar el tráfico de red virtual. Describe qué tráfico se permite o no entre las redes virtuales. De forma predeterminada, sin una directiva de red Contrail, se permite la comunicación dentro de la red virtual, pero se rechaza el tráfico de la red entre virtuals. Cuando cree una directiva de red, debe asociarla con una red virtual para que surta efecto.
’No confunda contrail Directiva de red con la Directiva de red Kubernetes. Son dos características de seguridad diferentes y funcionan por separado.
Grupo de seguridad (SG).
Un grupo de seguridad, a menudo abreviado como un SG, es un grupo de reglas que permite a un usuario especificar el tipo de tráfico que se permite o no a través de un puerto. Cuando se crea una VM o un conjunto Pod en una red virtual, se puede asociar un SG con la VM cuando se inicia. A diferencia de Contrail Directiva de red, que se configura de manera global y está asociada a las redes virtuales, el SG se configura por puerto y se aplicará a los flujos de vRouter específicos asociados con el puerto de la VM.
Limitación de políticas de red Contrail y SG
En los entornos de nube Contrail modernos, a veces es difícil usar solo la Directiva de red y el grupo de seguridad existentes para lograr los objetivos de seguridad deseados. Por ejemplo, en los entornos de nube, las cargas de trabajo se pueden mover de un servidor a otro y, probablemente, la IP suele estar cambiando. El hecho de depender de las direcciones IP para identificar los puntos de conexión que deben protegerse es una molestia. En su lugar, los usuarios deben aprovechar los atributos de nivel de aplicación para manipular las políticas,’de modo que las políticas no tengan que actualizarse cada vez que se mueva una carga de trabajo y cambie el entorno de red asociado. Asimismo, en producción, es posible que un usuario necesite agrupar cargas de trabajo basadas en combinaciones de etiquetas, lo que es difícil de traducir al idioma existente de una directiva de red o SG.
Contrail Directiva de seguridad del cortafuegos.
Este capítulo presenta otra característica importante: Contrail Directiva de seguridad del cortafuegos.
Contrail Directiva de seguridad del Firewall permite la desacoplamiento del enrutamiento de las políticas de seguridad, vand proporciona segmentación de la multidimensión y portabilidad de las políticas, a la vez que mejora de manera significativa las funciones de análisis y visibilidad del usuario.
A fin de implementar la segmentación del tráfico de varias dimensiones, Contrail Firewall introduce el concepto de etiquetas. Las etiquetas son pares clave-valor asociados con diferentes entidades en la implementación. Las etiquetas se pueden definir previamente o personalizadas o definidas por el usuario. Las etiquetas Contrail son prácticamente lo mismo que las etiquetas Kubernetes. Ambos se utilizan para identificar los objetos y las cargas de trabajo. Como puede ver, esto es similar a Kubernetes diseño de políticas de red, y es natural que Contrail utilice su Directiva de seguridad de Firewall para implementar Kubernetes Directiva de red. Teóricamente, Contrail Directiva de red o SG se pueden ampliar para hacer el trabajo, pero la compatibilidad de las etiquetas con Contrail Firewall hace que sea mucho más sencilla
A veces Contrail Directiva de seguridad del cortafuegos se conoce como Contrail seguridad, Contrail firewall, seguridad de Firewall de Contrail o simplemente Contrail FW.
Caso de uso de la Directiva de red Contrail Kubernetes
En esta sección, vamos’a crear un caso de uso para comprobar cómo funciona Kubernetes Directiva de red en los entornos contrail. ’Empezamos creando unos cuantos espacios de nombres y pods Kubernetes necesarios en la prueba. ’Confirmamos que cada conjunto Pod puede comunicarse con el dut (dispositivo sometido a prueba) gracias al modelo predeterminado de redes allow-any-any, y luego crear las políticas de red y observar cualquier cambio con el mismo patrón de tráfico.
Diseño de red
El diseño del caso de uso se muestra en la Figure 2.
En la Figure 2 , seis nodos se distribuyen en tres departamentos: dev, QA y jtac. El Departamento de desarrollo está ejecutando un servidor de base de datos (dbserver-dev), donde se almacena toda la información valiosa recopilada por el cliente. En su lugar, el diseño requiere que nadie tenga acceso directo a este servidor de base de servidores, sino que solo se permite el acceso a él a través de otro servidor Apache front-end en el Departamento de desarrollo, que se denomina WebServer-dev. Además, por razones de seguridad, el acceso a la información del cliente sólo debe concederse a clientes autorizados. Por ejemplo, solo los nodos del Departamento jtac, un nodo en el Departamento de desarrollo llamado cliente1-dev, y el 10.169.25.20 IP de origen pueden acceder a la BD a través de webserver. Y, por último, el servidor de base de datos dbserver-dev no debe iniciar ninguna conexión con otros nodos.
Preparación de la práctica
Este es un diseño de red muy común y simplificado que puede ver en cualquier lugar. Si modelamos todos estos elementos de red en el mundo de la Kubernetes, se parece a la Figure 3.
Pods necesitamos crear los siguientes recursos:
Tres espacios de nombres: dev, QA, jtac
Seis pods:
Dos pods de servidor: WebServer-dev, dbserver-dev
Dos pods de cliente en el mismo espacio de nombres que los pods de servidor: client1-dev, client2-dev
Dos pods de cliente de dos espacios de nombres diferentes: cliente-QA, cliente-jtac
Dos CIDR:
Especificación 10.169.25.20/32, se trata de la estructura IP del nodo cent222
Especificación 10.169.25.21/32, se trata de la estructura IP del nodo cent333
Table 1: Entorno de prueba de la Directiva de red Kubernetes
NS | caja | FUNC |
partido | client1-dev | cliente web |
partido | client2-dev | cliente web |
asegura | cliente-QA | cliente web |
jtac | cliente: jtac | cliente web |
partido | servidor WebServer-dev | servidor WebServer que atiende a clientes |
partido | dbserver-dev | dbserver Serving Server |
Bien, deje’que prepare los recursos de namespace y K8S necesarios con un archivo todo en uno YAML que defina los espacios de nombres de dev, QA y jtac:
Idealmente, cada conjunto Pod debe ejecutarse con distintas imágenes. Por lo general, los puertos TCP son diferentes en un servidor WebServer y en un servidor de base de datos. En nuestro caso, para simplificar la prueba, usamos la misma imagen contrail-WebServer que’utilizamos a lo largo de todo el libro para todos los pods, de modo que la comunicación entre los clientes y el servidor WebServer y el servidor de base de datos utilice el mismo número de puerto 80 que atiende el mismo servidor http. Además, agregamos una etiqueta: política en todos los pods, de manera que la visualización de todos los pods utilizados en esta prueba también es más fácil.
Bien y ahora cree todos los recursos:
Modo de tráfico antes de crear la Directiva de red Kubernetes
Dado que tenemos todos los espacios de nombres y Juniper, antes de definir cualquier directiva de red’, voy a seguir adelante y enviar tráfico entre clientes y servidores.
Por supuesto, Kubernetes de redes, de forma predeterminada, sigue el modelo allow-any-any, por lo que deberíamos esperar que Access funcione entre cualquier conjunto Pod, que va a ser una relación de acceso completamente entrelazada. Sin embargo, tenga en cuenta que la DUT de esta prueba es WebServer-dev y dbserver-dev es aquél que más nos interesa observar. Para simplificar la verificación, según nuestro diagrama, nos’centramos en acceder a los pods de servidor de los pods de cliente, tal como se muestra en la figura 8,4.
Los puntos destacados de la figura 8,4 son que todos los clientes pueden tener acceso a los servidores, siguiendo el modelo permit-any-any:
no hay ninguna restricción entre los clientes ni WebServer-dev Pod
no hay ninguna restricción entre los clientes y dbserver, Pod de desarrollador
Y la comunicación entre el cliente y los servidores es bidireccional y simétrica – cada extremo puede iniciar una sesión o aceptar una sesión. Estas se asignan a la Directiva de salida y la Directiva de entrada, respectivamente, en Kubernetes.
Obviamente, esto no cumple nuestro objetivo de diseño, que es exactamente por qué necesitamos la Directiva de red Kubernetes, y’pronto nos encontraremos esa parte. Por ahora, veamos’rápidamente cómo comprobar el modelo allow-any-any networking.
Primero deje’que compruebe el servidor HTTP que se ejecuta en el puerto 80 de WebServer-dev y dbserver-pod de dev:
$kubectl exec -it webserver-dev -n dev -- netstat -antp| grep 80 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1/python $kubectl exec -it dbserver-dev -n dev -- netstat -antp| grep 80 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1/python
Como se mencionó anteriormente, en esta prueba todos los pods tienen la misma imagen de contenedor, de manera que todos los pods ejecutan la misma aplicación WebServer en sus contenedores. Simplemente asignaremos a cada conjunto POD para que refleje sus diferentes funciones en el diagrama.
Ahora podemos comprobar el acceso a este servidor HTTP desde otros pods con los siguientes comandos. Para probar el tráfico de entrada:
Estos comandos desencadenan las solicitudes HTTP en el servidor WebServer-dev Pod desde todos los clientes y hosts de los dos nodos. La opción-M5 rizo hace que rizo espere un máximo de cinco segundos como respuesta antes de notificar el tiempo de espera. Como era de esperar, todos los accesos pasan y devuelven el mismo resultado mostrado a continuación.
Desde cliente1-dev:
$ kubectl exec -it client1-dev -n dev -- \ curl http://$webserverIP | w3m -T text/html | grep -v "^$" Hello This page is served by a Contrail pod IP address = 10.47.255.234 Hostname = webserver-dev
Aquí, w3m obtiene el resultado de rizo, que devuelve un código HTML de la página web y lo procesa en texto legible y, a continuación, lo envía a grep para eliminar las líneas vacías. Para hacer que el comando sea más corto, puede definir un alias:
alias webpr='w3m -T text/html | grep -v "^$"'
Ahora el comando es más corto:
$ kubectl exec -it client1-dev -n dev -- curl http://$webserverIP | webpr Hello This page is served by a Contrail pod IP address = 10.47.255.234 Hostname = webserver-dev
De manera similar’, ll obtiene los mismos resultados de pruebas para obtener acceso a dbserver-dev desde cualquiera de los otros pods.
Crear Directiva de red Kubernetes
A continuación’, deje que s cree la Directiva de red K8S para implementar nuestro diseño. A partir de nuestro objetivo inicial de diseño, esto son lo que queríamos lograr mediante una política de red:
cliente1: dev y pods en jtac namespace (es decir, jtac-dev POD) puede acceder a WebServer y a dev Pod
WebServer: un pod (y solo él) tiene permiso de acceso dbserver-pod de desarrollador
los demás pods de cliente no tienen permitido acceder a los dos pods de servidor
todos los demás pods de cliente pueden seguir comunicándose entre sí.
Traducción de estos requisitos al idioma de la Directiva de red Kubernetes,’trabajamos con este archivo de YAML de políticas de red:
A partir de la definición de la Directiva de red,’que se basa en lo aprendido en el capítulo 3, es fácil que pueda saber lo que la Directiva está intentando imponer en nuestra configuración actual:
Según la política de entrada, los siguientes clientes pueden acceder a la caja Pod del servidor WebServer-dev, que se encuentra en el espacio de nombres dev:
cliente1: desarrollo desde el espacio de nombres dev
todos los pods del espacio de nombres jtac, que es el conjunto pod de cliente-jtac en nuestra configuración
clientes con 10.169.25.20 IP de origen (cent222 en la configuración)
Según la Directiva de salida, el conjunto de servidores WebServer-dev del espacio de nombres dev puede iniciar una sesión TCP en dbserver-pod de dev con el puerto de destino 80 para tener acceso a los datos.
Para el conjunto pod de destino-dev, se denegarán todos los demás accesos.
La comunicación entre los demás pods no se ve afectada por esta política de red.
En realidad, se trata del archivo de YAML de políticas de’red exacto que se muestra en el capítulo 3.
Cree’la Directiva y compruebe que tiene efecto:
$ kubectl apply -f policy1- do.yaml networkpolicy.networking.k8 s.io/policy1 created
$ kubectl get networkpolicies -- all-namespaces NAMESPACE NAME POD- SELECTOR AGE dev policy1 app=webserver-dev 17s
Creación de directiva de red post Kubernetes
Después de crear la Directiva de red directiva1,’deje que se pruebe el acceso al servidor http en WebServer-dev Pod desde podism-dev, Client-jtac y node cent222 host:
$ kubectl exec -it client1-dev -n dev -- curl http://$webserverIP | webpr Hello This page is served by a Contrail pod IP address = 10.47.255.234 Hostname = webserver-dev
El acceso de estos dos pods a WebServer-dev es correcto y es lo que queremos. Ahora, si repetimos la misma prueba desde el otro Pod-dev, Client-QA y otro nodo, cent333 ahora se agotará el tiempo de espera:
$ kubectl exec -it client2-dev -n dev -- curl http://$webserverIP -m 5 curl: (28) Connection timed out after 5000 milliseconds command terminated with exit code 28
$ kubectl exec -it client-jtac -n jtac -- curl http://$webserverIP -m 5 curl: (28) Connection timed out after 5000 milliseconds command terminated with exit code 28
$ curl http://$webserverIP -m 5 curl: (28) Connection timed out after 5000 milliseconds
Los nuevos resultados de la prueba después de aplicar la Directiva de red se ilustran en la Figure 5.
Un detalle del objeto de directiva de red indica lo mismo:
$ kubectl describe
netpol -n dev policy1
Name: policy1
Namespace: dev
Created on: 2019-09-29 21:21:14 -0400 EDT
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"networking.k8s.io/v1",
"kind":"NetworkPolicy",
"metadata":{"annotations":{},"name":
"policy1","namespace":"dev"},
"spec":{"egre...
Spec:
PodSelector:
app=webserver-dev
Allowing ingress
traffic: #<--- To
Port: 80/TCP
From:
IPBlock:
CIDR: 10.169.25.20/32
Except:
From:
NamespaceSelector:
project=jtac
From:
PodSelector:
app=client1-dev
Allowing egress
traffic:
To Port:
80/TCP To:
PodSelector:
app=dbserver-dev
Policy Types:
Ingress, Egress
En el ejercicio anterior, podemos concluir que K8S Directiva de red funciona de la manera esperada en Contrail.
Pero nuestra prueba no se ha hecho todavía. En la Directiva de red en la que se definieron la Directiva de entrada y salida, pero desde la perspectiva’’del servidor WebServer-dev, solo comprobamos que la política de entrada de la directiva1 funciona correctamente. Además, no hemos aplicado ninguna directiva al resto del servidor Pod dbserver-dev. Según el valor predeterminado permitir cualquier política, cualquier pods puede acceder directamente a él sin problemas. Obviamente, esto no es lo que queríamos de acuerdo con nuestro diseño original. Se necesita otra directiva de red de entrada para dbserver-Pod-dev, y finalmente, necesitamos aplicar una directiva de salida a dbserver-dev para asegurarse de que se pueda’conectar a cualquier otro pods. Por lo tanto, hay que confirmar al menos tres elementos de prueba, es decir:
Probar la política de salida de directiva1 aplicada a WebServer-pod de desarrollo;
Definir y probar la política de Ingress para dbserver-pod de desarrollo;
Defina y pruebe la Directiva de salida para dbserver-Pod-dev. ’Observemos primero la política de salida de la directiva1.
Directiva de salida de WebServer-pod de desarrollo
A’continuación se muestra la prueba del tráfico de salida:
El resultado muestra que solo el acceso a dbserver-dev se realiza correctamente mientras se agota el tiempo de espera de otros accesos de salida:
$ kubectl exec -it webserver-dev -n dev -- curl $dbserverIP -m5 | webpr Hello This page is served by a Contrail pod IP address = 10.47.255.233 Hostname = dbserver-dev $ kubectl exec -it webserver-dev -n dev -- curl 10.47.255.232 -m5 curl: (28) Connection timed out after 5001 milliseconds command terminated with exit code 28
Directiva de red de dbserver-pod de desarrollo
Hasta ahora, lo que es tan bueno. ’Observemos los elementos de prueba del segundo, el acceso de entrada a dbserver-dev pod de otros pods que no sea WebServer-pod de dev. Pruebe el tráfico de salida:
Todos los pods pueden acceder a dbserver, directamente a dev Pod:
$ kubectl exec -it client1-dev -n dev -- curl http://$dbserverIP -m5 | webpr Hello This page is served by a Contrail pod IP address = 10.47.255.233 Hostname = dbserver-dev
Nuestro diseño es bloquear el acceso desde todos los pods excepto WebServer-dev Pod. Para ello, es necesario aplicar otra directiva. A continuación se muestra el archivo YAML de la segunda Directiva:
Esta directiva de red, policy2, es muy similar a la anterior directiva1, excepto que parece más simple – . los tipos de directiva solo tienen entrada en la lista, por lo que solo se definirá una directiva de entrada. Y que la Directiva de entrada defina una lista blanca con solo un podSelector. En nuestro caso de prueba, solo un servidor WebServer-dev tiene su etiqueta coincidente con el mismo, por lo que será el único autorizado para iniciar la conexión TCP hacia Target Pod dbserver-dev en el puerto 80. Deje’que s cree la Directiva policy2 ahora y compruebe el resultado de nuevo:
$ kubectl exec -it webserver-dev -n dev -- curl http://$dbserverIP -m5 | webpr Hello This page is served by a Contrail pod IP address = 10.47.255.233 Hostname = dbserver-dev
$ kubectl exec -it client1-dev -n dev -- curl http://$dbserverIP -m5 | webpr command terminated with exit code 28 curl: (28) Connection timed out after 5002 milliseconds
Ahora el acceso a dbserver-pod de dev es asegurado.
Directiva de salida en dbserver-dev
Bien, solo uno de los últimos requisitos de nuestro objetivo de diseño: dbserver del servidor-dev no debe poder iniciar ninguna conexión con otros nodos.
Cuando revisó policy2, es posible que se me haya preguntado cómo haremos eso. En el capítulo 3 destacamos que la Directiva de red se basa en la lista blanca únicamente por su diseño. Por lo tanto, todo lo que usted ponga en la lista blanca significa que estará permitido. Solo una lista negra ofrece una denegación, pero incluso con una lista’negra que ganó, no podrá enumerar todos los demás pods para obtenerlos denegados.
Otra forma de pensar en esto es hacer uso de la Directiva implícita denegar todo. Suponiendo que esta secuencia de directivas está en el diseño actual de la Directiva de red Kubernetes:
policy2 en dbserver-dev
denegar todo para dbserver-dev
permitir todos los demás pods
Parece que si damos una lista blanca vacía en la política de salida de dbserver-dev, no se permitirá nada y se entrará en juego la política deny All para el conjunto pod de destino. El problema es, ¿cómo definimos una lista blanca vacía?:
Esto resulta que no’funciona de la manera esperada:
$ kubectl exec -it dbserver-dev -n dev -- curl http://10.47.255.232 -m5 | webpr Hello This page is served by a Contrail pod IP address = 10.47.255.232 Hostname = client1-dev
La comprobación de los detalles del objeto de Directiva no descubre algo que obviamente sea incorrecto:
$ kubectl describe netpol
policy2-tryout -n dev
Name: policy2-tryout
Namespace: dev
Created on: 2019-10-01 17:02:18 -0400 EDT
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"networking.k8s.io/v1",
"kind":"NetworkPolicy",
"metadata":{"annotations":{},"name":
"policy2-tryout",
"namespace":"dev"},"spec"...
Spec:
PodSelector:
app=dbserver-dev
Allowing ingress
traffic:
To Port:
80/TCP
From:
PodSelector:
app=webserver-dev
Allowing egress
traffic:
<none> (Selected pods are isolated for
egress connectivity)
#<
--- Policy Types: Ingress El problema está en el policyTypes. Se Haven’a agregar la salida, por lo que se pasará por alto cualquier cosa que esté configurada en la Directiva de salida. Si simplemente agrega salida en policyTypes, lo corregirá. Además, para expresar una lista blanca vacía, la salida: la palabra clave es opcional y no es obligatoria. A continuación se muestra el nuevo archivo de YAML de políticas:
Ahora elimine el policy2 antiguo y aplique esta nueva Directiva. Se bloquearán las solicitudes de dbserver-dev a cualquier pods (por ejemplo, Pod cliente1-dev):
$ kubectl exec -it dbserver-dev -n dev -- curl http://10.47.255.232 | webpr command terminated with exit code 28 curl: (7) Failed to connect to 10.47.255.232 port 80: Connection timed out
Y este es el diagrama final que ilustra el resultado de nuestra prueba de la Directiva de red en la Figure 6.
La acción Drop en la tabla de flujo
Antes de concluir la prueba, dejemos que’echemos un vistazo a la tabla de flujo vRouter cuando la política interrumpa el tráfico. En el nodo cent333 donde se ubican los Pod dbserver-dev:
$ docker exec -it vrouter_vrouter-agent_1 flow --match 10.47.255.232:80 Flow table(size 80609280, entries 629760) Entries: Created 33 Added 33 Deleted 30 Changed 54Processed 33 Used Overflow entries 0 (Created Flows/CPU: 7 9 11 6)(oflows 0) Action:F=Forward, D=Drop N=NAT(S=SNAT, D=DNAT, Ps=SPAT, Pd=DPAT, L=Link Local Port) Other:K(nh)=Key_Nexthop, S(nh)=RPF_Nexthop Flags:E=Evicted, Ec=Evict Candidate, N=New Flow, M=Modified Dm=Delete Marked TCP(r=reverse):S=SYN, F=FIN, R=RST, C=HalfClose, E=Established, D=Dead Listing flows matching ([10.47.255.232]:80) Index Source:Port/Destination:Port Proto(V) 158672<=>495824 10.47.255.232:80 6 (5) 10.47.255.233:42282 (Gen: 1, K(nh):59, Action:D(Unknown), Flags:, TCP:Sr, QOS:-1, S(nh):63, Stats:0/0, SPort 54194, TTL 0, Sinfo 0.0.0.0) 495824<=>158672 10.47.255.233:42282 6 (5) 10.47.255.232:80 (Gen: 1, K(nh):59, Action:D(FwPolicy), Flags:, TCP:S, QOS:-1, S(nh):59, Stats:3/222, SPort 52162, TTL 0, Sinfo 8.0.0.0)
La acción: D se establece en D (FwPolicy), que significa eliminar debido a la Directiva de Firewall. Mientras tanto, en el otro nodo cent222, en la que se encuentra la caja Pod-dev’, no vemos ningún flujo generado, lo que indica que el paquete no llega:
$ docker exec -it vrouter_vrouter-agent_1 flow --match 10.47.255.233 Flow table(size 80609280, entries 629760) ...... Listing flows matching ([10.47.255.233]:*) Index Source:Port/Destination:Port Proto(V)
Detalles de Contrail implementación
’Reiteramos que contrail implementa Kubernetes Directiva de red con una directiva de seguridad de Firewall contrail. También sabe que las etiquetas Kubernetes se exponen como etiquetas en Contrail. Contrail Directiva de seguridad utiliza estas etiquetas para implementar las políticas de Kubernetes especificadas. Las etiquetas de los objetos Kubernetes se crearán automáticamente etiquetas o se crearán manualmente en la interfaz de usuario.
En esta sección se’examinarán más detenidamente los contrail las políticas de firewall, las reglas de políticas y las etiquetas. En particular,’examinamos las relaciones de asignación entre los objetos Kubernetes que creamos y probamos en la última sección, y los objetos de contrail correspondientes en contrail sistema Firewall.
Contrail cortafuegos está diseñado con una estructura jerárquica:
El objeto de nivel superior se denomina Directiva de aplicación establecida, abreviada como AP.
APS tiene políticas de Firewall.
La Directiva del firewall tiene reglas de Firewall.
Las reglas del cortafuegos tienen los puntos de conexión.
Los puntos de conexión se pueden identificar a través de etiquetas o grupos de direcciones (CIDR).
La estructura se ilustra en la Figure 7.
Construir asignaciones
Kubernetes Directiva de red y Contrail Directiva de cortafuegos son dos entidades distintas en lo que se refiere a la semántica de la Directiva de red en la que se especifica cada una. Para que Contrail servidor de seguridad pueda implementar Kubernetes Directiva de red, Contrail necesita implementar la asignación uno a uno para una gran cantidad de datos de Kubernetes a Contrail Firewall. Estas construcciones de datos son las unidades de creación básicas de la Directiva de red Kubernetes y la correspondiente Contrail Directiva de Firewall.
En la Table 2 se enumeran las construcciones de directiva de red Kubernetes y sus estructuras correspondientes en contrail:
Table 2: K8s Directiva de red y asignación de construcción de Firewall de Contrail
Construcción de directiva de red K8s | Contrail construcción de Firewall |
Nombre de clúster | AP (uno por clúster K8S) |
Directiva de red | Directiva de Firewall (una por cada directiva de red K8S) |
Regla de la Directiva de entrada y salida | Regla de Firewall (una por K8S regla de directiva de entrada/salida) |
Especificación | Grupo de direcciones (uno por cada CIDR de directiva de red K8S) |
Sin | Tag (uno por cada etiqueta K8S) |
Cryptography | Etiqueta personalizada (una para cada espacio de nombres) |
El contrail-Kube-Manager, el KM, a medida’que se lee muchas veces en este libro, hace todas las traducciones entre los dos mundos. Básicamente, lo siguiente ocurrirá en el contexto de Kubernetes Directiva de red:
El KM creará un AP con un nombre de clúster Kubernetes durante su proceso de inicialización. Normalmente, el nombre de clúster predeterminado Kubernetes es K8S, por lo que verá un APS con el mismo nombre en su clúster.
El KM se registra en Kube-apiserver para vigilar los sucesos de las políticas de la red.
Siempre que se crea una directiva de red Kubernetes, se creará una directiva de Firewall Contrail correspondiente con todas las reglas de firewall y puntos de conexión de red coincidentes.
Para cada etiqueta creada en un objeto Kubernetes, se creará una etiqueta Contrail correspondiente.
En función de la etiqueta, se pueden localizar los objetos de Contrail correspondientes (VN, pods, VMI, proyectos, etc.).
Contrail aplicará las políticas y reglas del cortafuegos de Contrail en los AP de los objetos Contrail, así es cómo se permite o se deniega el tráfico específico.
Los APS se pueden asociar a objetos Contrail diferentes, por ejemplo:
VMI (interfaz de máquina virtual)
VM (máquina virtual) o pods
VN (red virtual)
proyectos
En Contrail clúster Kubernetes, el APS se asocia a Virtual Network. Cuando el tráfico entra en esas redes, las políticas de Firewall asociadas al APS se evaluarían y se tomaran las medidas respectivas para el tráfico.
En la sección anterior, creamos dos políticas de red Kubernetes en nuestro caso de uso. Ahora deje’que s explore los contrail objetos que se crean para estas políticas de red de Kubernetes.
Conjunto de políticas de aplicaciones (AP)
Como se mencionó anteriormente, contrail-Kube-Manager creará un APS con el nombre del clúster Kubernetes durante la fase de inicialización. En el capítulo 3, cuando presentamos Contrail espacios de nombres y el aislamiento, aprendimos que el nombre del clúster es K8S de forma predeterminada en Contrail. Por lo tanto, el nombre del APS también se K8S en la interfaz de usuario de Contrail que se muestra en la Figure 8.
Hay un conjunto de políticas de aplicaciones-aplicación predeterminadas más APS que se crea de forma predeterminada.
Cies
Ahora, haga clic en políticas del cortafuegos para mostrar todas las políticas de firewall en el clúster. En nuestro entorno de prueba, encontrará disponibles las siguientes políticas:
k8s-dev-policy1
k8s-dev-policy2
k8s-denyall
k8s-allowall
k8s-Ingress
Convención de nomenclatura de directiva de Firewall de Contrail
Las políticas K8S-dev-directiva1 y K8S-dev-policy2 son lo que’creamos. Aunque parezcan diferentes de los nombres de objeto que asignamos a nuestro archivo YAML, es fácil saber cuál es cuál. Cuando KM crea las directivas de cortafuegos Contrail basadas en las políticas de red Kubernetes, agrega el nombre de clúster al nombre de la Directiva de firewall, más el espacio de nombres, delante de nuestro nombre de directiva de red:
<cluster name>-<namespace-name>-<kubernetes network policy name>
Esto le resultará familiar. Anteriormente mostramos cómo KM da nombre a la red virtual en Contrail interfaz de usuario después del nombre de objetos de red virtual de Kubernetes que creamos en el archivo YAML
La Directiva de Firewall K8s-Ingress se crea para que el equilibrado de carga de entrada asegure que los ingresos funcionen correctamente en Contrail. Esta guía no incluye ninguna explicación detallada.
Pero la pregunta más grande es: ¿por qué seguimos viendo dos políticas de Firewall aquí, ya que nunca hemos creado políticas de red como allowall o denyall?
Bueno, recuerde cuando introdujemos la política de red Kubernetes en el capítulo 3, y mencioné que Kubernetes Directiva de red utiliza un método de la lista blanca y las políticas de denegar todo y permitir todas implícitas. La naturaleza del método de la lista blanca indica denegar todo tipo de acción que se agrega en la lista blanca, mientras que el comportamiento implícito permitir todo garantiza que una caja Pod que no esté involucrada en ninguna política de red pueda continuar su modelo de tráfico permitir-cualquier-cualquiera. El problema con Contrail firewall con respecto a esta implícita es que, de forma predeterminada, sigue un modelo denegar todo: todo lo que no esté definido explícitamente quedará bloqueado. Por eso, en Contrail implementación, estas dos políticas de red implícitas correspondientes son aceptadas por dos políticas explícitas generadas por el módulo KM.
En este punto, puede producirse una pregunta. Con varias políticas de firewall, ¿cuál debe aplicarse y evaluarse primero y cuáles más tarde? Es decir, en qué secuencia Contrail aplicar y evaluar cada política – una evaluación de políticas de firewall con una secuencia diferente conducirá a resultados completamente diferentes. Tan solo Imagínese estas dos secuencias denyall-allowall frente a allowall-denyall. El primero da un deny a todos los demás pods, mientras que el último da un pase la respuesta es el número de secuencia.
Número de secuencia
Cuando se evalúan las políticas de Firewall de un APS, tienen que evaluarse en una secuencia determinada. Todas las políticas del cortafuegos y todas las reglas del cortafuegos (que pronto lo haremos) en cada una de las políticas tienen un número de secuencia. Cuando hay una directiva coincidente, ésta se ejecutará y la evaluación se detendrá. Vuelve a contrail-Kube-Manager que asigna el número de secuencia correcto para todas las políticas cortafuegos y reglas cortafuegos, para que todo funcione en el orden correcto. El proceso se realiza automáticamente sin intervención manual. ’No tendrá que preocuparse por estas cosas cuando cree las directivas de red Kubernetes.
A’continuación, vamos a volver a visitar los números de secuencia’más adelante, pero por ahora vamos a ver las reglas definidas en la Directiva del cortafuegos.
Reglas de directiva de Firewall
En la siguiente captura de la lista de políticas del cortafuegos, puede ver el número de reglas de cada Directiva.
Existen cuatro reglas para la política K8S-la directiva1. Al hacer clic en las reglas, las reglas se mostrarán detalladas como en la Figure 11.
Es similar a la Directiva de red Kubernetes directiva1 que se’probó. ’Pongamos las reglas, mostradas en las capturas de pantalla, en la Table 3.
Table 3: Normativa
Filete # | Intervención | Servicios | End Point1 | Dirs | Finalizar Point2 | Hacer coincidir etiquetas |
1 | Pass | TCP: 80 | Project = jtac | > | App = WebServer-dev & & namespace = dev | - |
2 | Pass | TCP: 80 | App = cliente1-& & espacio de nombres de los desarrolladores = desarrollador | > | App = WebServer-dev & & namespace = dev | - |
3 | Pass | TCP: 80 | App = WebServer-dev & & namespace = dev | > | App = dbserver-& de Desarrollador & namespace = dev | - |
4 | Pass | TCP: 80 | Grupo de direcciones: 10.169.25.20/32 | > | App = WebServer-dev & & namespace = dev | - |
La primera columna del cuadro 8,2 es el número de la regla que agregamos; todas las demás columnas se importan desde la captura de pantalla de UI. ’Ahora, compárela con la información del objeto Kubernetes:
$ kubectl get netpol --all-namespaces -o yaml apiVersion: v1 items: - apiVersion: extensions/v1beta1 kind: NetworkPolicy metadata: ...... spec: egress: - ports: - port: 80 protocol: TCP to: - podSelector: #<---rule#3 matchLabels: app: dbserver-dev ingress: - from: - ipBlock: #<---rule#4 cidr: 10.169.25.20/32 - namespaceSelector: #<---rule#1 matchLabels: project: jtac - podSelector: #<---rule#2 matchLabels: app: client1-dev ports: - port: 80 protocol: TCP podSelector: matchLabels: app: webserver-dev policyTypes: - Ingress - Egress
Las reglas que vemos en la Directiva de Firewall K8S-dev-directiva1 coincide con las reglas en Kubernetes Directiva de red directiva1
Reglas en la Directiva de Firewall K8S-denyall
’Ahora, vuelva y examine las reglas de la Directiva K8S denyall que generó km para nuestras políticas de red Kubernetes.
De nuevo, si lo convertiremos en una tabla, aparecerá como se muestra en la Table 4.
Table 4: Contrail UI: Reglas de directiva de K8S-denyall
Filete # | Intervención | Servicios | End Point1 | Dirs | Finalizar Point2 | Hacer coincidir etiquetas |
1 | niegue | Any: any | App = WebServer-dev & & namespace = dev | > | ninguna | - |
2 | niegue | Any: any | ninguna | > | App = dbserver-& de Desarrollador & namespace = dev | - |
3 | niegue | Any: any | ninguna | > | App = WebServer-dev & & namespace = dev | - |
Las reglas K8S-alldeny son sencillas. Solo indican a Contrail que rechace la comunicación con todos los demás pods que no se encuentren en la lista blanca. Una cosa que merece mencionar es que hay una regla en la dirección de App = WebServer-dev & & namespace = dev a any, por lo que se deniega el tráfico de salida para WebServer-pod de desarrollador, mientras que no existe una regla de este tipo de App = dbserver-dev & & namespace = dev a any. Si revisa nuestra prueba de la última sección, en la policy2 de la directiva original, no definimos una opción de salida en policyTypes para denegar el tráfico de salida de dbserver-dev, es decir, que no existe esta regla cuando se traduce en Contrail firewall, tampoco. Si cambiamos policy2 a la nueva Directiva policy2-out-denyall y examinamos lo mismo,’verámos ahora la regla que falta.
Preste atención al hecho de que la política K8S-denyall solo se aplica a los Juniper – pods que son seleccionados por las políticas de la red. En este caso, solo se aplica a pods, servidor WebServer-dev y dbserver-dev. Otros pods, como Client-jtac o Client-QA no se efectuarán. En cambio, esos pods serán aplicados por la política de K8S-allowany,’que se examinarán a continuación.
Reglas en la Directiva de Firewall K8S-allowall
En la Figure 14, la Directiva K8S-allowall parece tener más reglas que otras políticas.
A pesar del número de reglas, de hecho K8S-allowall es el más simple. Funciona en el nivel NS y simplemente cuenta con dos reglas para cada NS. En la interfaz de usuario, dentro del campo de búsqueda, la clave en un espacio de nombres como filtro, por ejemplo, dev’o QA, y los resultados se pueden ver en las Figure 15 y Figure 16.
Lo que se dice en esta directiva es: para aquellos pods que aún no tienen ninguna política de red aplicada, dejemos’que continúe el Kubernetes predeterminado allow-any-any Networking Mode y lo permita todo.
Número de secuencia
Después de haber explorado las Contrail reglas de la directiva’del cortafuegos, deje que el número de secuencia regrese a él y observe cómo funciona exactamente.
El número de secuencia es un número que se adjunta a todas las políticas del cortafuegos y sus reglas que deciden el orden en el que se aplican y evalúan todas las políticas, y que hace lo mismo en una política concreta. Cuanto más bajo sea el número de secuencia, mayor será la prioridad. Para encontrar el número de secuencia, debe consultar los atributos Directiva del cortafuegos y objeto de regla de políticas en Contrail base de datos de configuración.
’Primero, examine el objeto de directiva de firewall en APS para comprobar su número de secuencia.
En el capítulo 5 utilizamos el comando rizo para extraer los datos del objeto loadbalancer cuando presentamos el servicio. Aquí utilizamos config editor para hacer lo mismo.
La Figure 17 y la Figure 18 capturan el número de secuencia en las políticas del cortafuegos.
Las cinco políticas que se’observarán aparecen en estas capturas de pantallas, en APS K8S. Por ejemplo, la Directiva K8S-dev-directiva1, que se asigna a la Directiva de red Kubernetes directiva1 que definimos explícitamente, y la política K8S-denyall, que es lo que el sistema generó automáticamente. Las figuras show K8S-dev-directiva1 y K8S-denyall tienen secuencias de 00038,0 y 00042,0, respectivamente. Por lo tanto K8S-dev-directiva1 tiene una prioridad más alta, por lo que se aplicará y evaluará primero. Esto significa que los tipos de tráfico que definimos en la lista blanca se permitirán en primer lugar y, a continuación, se denegará cualquier otro tráfico hacia o desde el conjunto pod de destino. Este es el objetivo exacto que queríamos lograr.
Todos los números de secuencia de todas las políticas de cortafuegos se enumeran en la Table 5, de mayor a menor prioridad:
Table 5: Números de secuencia
Número de secuencia | Directiva de Firewall |
00002.0 | k8s-Ingress |
00038.0 | k8s-dev-policy1 |
00040.0 | k8s-dev-policy2 |
00042.0 | k8s-denyall |
00043.0 | k8s-allowall |
Basándose en el número de secuencia, la aplicación y el orden de evaluación son las primeras políticas explícitas, seguidas de la Directiva deny All y terminan con la directiva allow ALL. Se acepta el mismo orden que en Kubernetes.
Número de secuencia en las reglas de directiva de cortafuegos
Como se mencionó anteriormente, en la misma directiva de firewall, también habrá que aplicar y evaluar reglas de directiva en un orden determinado. En Contrail cortafuegos que se asegura de nuevo por el número de secuencia. Los números de secuencia de las reglas de directiva de Firewall K8S-dev-directiva1 se muestran en la Figure 19 y en la Figure 20.
Y la Table 6 enumera el número de secuencia de todas las reglas de la política de Firewall K8S-dev-directiva1, de máxima prioridad a la más baja.
Table 6: Números de secuencia para la Directiva1
panorama # | regla de Firewall |
00000.0 | dev-ingress-policy1-0-ipBlock-0-cidr-10.169.25.20/32-0 |
00001.0 | dev-ingress-policy1-0-namespaceSelector-1-0 |
00002.0 | dev-ingress-policy1-0-podSelector-2-0 |
00003.0 | dev-egress-policy1-podSelector-0-0 |
’Compárelos con nuestra directiva de red configuración del archivo YAML:
ingress: - from: - ipBlock: cidr: 10.169.25.20/32 #<---seq# 00000.0 - namespaceSelector: #<---seq# 00001.0 matchLabels: project: jtac - podSelector: #<---seq# 00002.0 matchLabels: app: client1-dev ports: - protocol: TCP port: 80 egress: - to: - podSelector: #<---seq# 00003.0 matchLabels: app: dbserver-dev ports: - protocol: TCP port: 80
Encontramos que el número de secuencia de reglas es coherente con la secuencia que aparece en el archivo YAML Es decir, las reglas se aplicarán y evaluarán en el mismo orden en el que se definen.
Marcar
Nos’hemos hablando de las etiquetas contrail y ya sabemos que contrail-Kube-Manager traducirá cada etiqueta Kubernetes en una etiqueta contrail, que se adjunta al puerto correspondiente de una Pod, como se muestra en la Figure 21.
Visualización de UI
Contrail UI proporciona una visualización agradable para la seguridad, como se muestra en la Figure 22. TI’se explica por sí mismo si sabe cómo funciona la seguridad contrail.
