Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

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 1.

Figure 1: Firewall Contrail
Firewall Contrail

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 1 se enumeran las construcciones de directiva de red Kubernetes y sus estructuras correspondientes en contrail:

Table 1: 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:

  1. 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.

  2. El KM se registra en Kube-apiserver para vigilar los sucesos de las políticas de la red.

  3. 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.

  4. Para cada etiqueta creada en un objeto Kubernetes, se creará una etiqueta Contrail correspondiente.

  5. En función de la etiqueta, se pueden localizar los objetos de Contrail correspondientes (VN, pods, VMI, proyectos, etc.).

  6. 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 2.

Figure 2: Contrail UI: APS configurar > de seguridad > políticas globales > conjuntos de políticas de aplicaciones
Contrail UI: APS configurar > de seguridad > políticas globales > conjuntos de políticas de aplicaciones

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

Figure 3: Contrail UI: Políticas de cortafuegos
Contrail UI: Políticas de cortafuegos

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:

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.

Figure 4: Contrail UI: reglas de directiva de Firewall
Contrail UI: reglas de directiva de Firewall

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 5.

Figure 5: Contrail UI: Reglas de K8S-dev-directiva1
Contrail UI: Reglas de K8S-dev-directiva1

Es similar a la Directiva de red Kubernetes directiva1 que se’probó. ’Pongamos las reglas, mostradas en las capturas de pantalla, en la Table 2.

Table 2: 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:

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.

Figure 6: Contrail UI: Reglas de directiva de K8S-denyall
Contrail UI: Reglas de directiva de K8S-denyall

De nuevo, si lo convertiremos en una tabla, aparecerá como se muestra en la Table 3.

Table 3: 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.

Figure 7: Contrail UI: K8S-denyall reglas
Contrail UI: K8S-denyall reglas

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 8, la Directiva K8S-allowall parece tener más reglas que otras políticas.

Figure 8: Contrail UI: K8S-allowall reglas
Contrail UI: K8S-allowall reglas

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 9 y Figure 10.

Figure 9: Contrail UI: K8S-allowall reglas filtradas por el desarrollo de NS
Contrail UI: K8S-allowall reglas filtradas por el desarrollo de NS
Figure 10: Contrail UI: K8S-allowall reglas filtradas por QA NS
Contrail UI: K8S-allowall reglas filtradas por QA NS

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.

Tip

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 11 y la Figure 12 capturan el número de secuencia en las políticas del cortafuegos.

Figure 11: Contrail UI: Número de secuencia para políticas: Estableciendo > config editor
Contrail UI: Número de secuencia para políticas: Estableciendo > config editor
Figure 12: Contrail UI: Número de secuencia para políticas (continuación)
Contrail UI: Número de secuencia para políticas (continuación)

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 4, de mayor a menor prioridad:

Table 4: 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

Figure 13: Contrail número de secuencia de IU para las reglas: Estableciendo > config editor
Contrail número de secuencia de IU para las reglas: Estableciendo > config editor

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 13 y en la Figure 14.

Figure 14: Contrail de número de secuencia de IU para reglas (continuación)
Contrail de número de secuencia de IU para reglas (continuación)

Y la Table 5 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 5: 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:

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 15.

Figure 15: Interfaz de usuario de etiquetas
Interfaz de usuario de etiquetas

Visualización de UI

Contrail UI proporciona una visualización agradable para la seguridad, como se muestra en la Figure 16. TI’se explica por sí mismo si sabe cómo funciona la seguridad contrail.

Figure 16: Visualización de tráfico de muestra para la directiva anterior con carga de trabajo
Visualización de tráfico de muestra para la directiva anterior con carga de trabajo
Figure 17: Visualización de tráfico de muestra con más políticas de red
Visualización de tráfico de muestra con más políticas de red