¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
  1. Libros
  2. Kubernetes
  3. Network policies
Extrait - Kubernetes Administre la plataforma de despliegue de sus aplicaciones en contenedores
Extractos del libro
Kubernetes Administre la plataforma de despliegue de sus aplicaciones en contenedores
3 opiniones
Volver a la página de compra del libro

Network policies

Objetivos del capítulo y requisitos previos

En el capítulo anterior, se implementó una primera capa de seguridad para evitar que nadie pudiera acceder a los recursos del clúster. En contraposición, si un tercero logra comprometer la integridad de un pod, nada impedirá que se siga atacando desde él.

De forma predeterminada, los pods en Kubernetes se pueden comunicar entre sí sin ninguna restricción. Esta situación sigue siendo aceptable para pequeños grupos de prueba, pero rápidamente se hará necesario restringir este acceso.

Las network policies

1. Presentación del mecanismo

Una forma de controlar el acceso sería definirlo en función de reglas de la aplicación. Todos los pods de un mismo servicio tendrían derecho a comunicarse entre sí (los pods de presentación con su base de datos, por ejemplo), pero no con el resto. Otro ejemplo de restricción sería no permitir la comunicación entre pods de dos espacios de nombres diferentes.

En Kubernetes, este mecanismo es compatible con recursos de tipo NetworkPolicy.

2. Kubernetes Network Plugins

Para poder utilizar este tipo de recursos, el clúster de Kubernetes debe tener una capa de gestión de red que admita la noción de policies. Esta capa cumple con un estándar: CNI (Container Network Interface).

Este estándar se implementa por los controladores (Calico, Weave, Flannel, etc.). El sitio oficial de Kubernetes hace referencia a parte de él en la siguiente página: https://kubernetes.io/docs/concepts/cluster-administration/networking/

Estos drivers utilizan diferentes mecanismos para realizar el control de la comunicación: 

  • Overlay: encapsulación de la comunicación en una red virtual (VLAN, veth, etc.).

  • Underlay: uso de recursos de hardware subyacentes (conmutadores, enrutadores, etc.).

Entre las muchas soluciones, una de ellas surge con mucha frecuencia: Calico. De hecho, se encuentra en los siguientes casos:

  • Las soluciones gestionadas (AWS, Azure y GKE) son propietarias y, en parte, se basan en Calico (por la parte NetworkPolicies).

  • Calico también se puede usar en clústeres de Kubernetes instalados en máquinas clásicas (on premise).

En el caso de Calico, el procedimiento de instalación se realizará sobre Minikube. 

3. Network policies en servicios gestionados e instalación propietaria

La activación de las políticas de red se abordó durante la creación de los clústeres por servicios administrados (Azure, AWS o GKE) o para la instalación interna o propietaria (Kubespray).

No dude en volver a los capítulos Servicios gestionados de Kubernetes e Instalar Kubernetes en interno, sobre la instalación de clústeres con Kubespray...

Proteger la aplicación WordPress

1. Contexto

La arquitectura de la aplicación MailHog es simple. De hecho, MailHog no interactúa con otros servicios (sin base de datos o servicios a los que llamar).

Desde este punto de vista, una aplicación WordPress es más representativa de un caso real, ya que consta de las siguientes partes:

  • una capa de presentación,

  • una base de datos.

2. Desplegar WordPress

Para el resto del ejercicio, se implementará un sitio web de WordPress en el espacio de nombres test, con una regla Ingress en la dirección wordpress.eni.yannig.ovh.

Para publicar la aplicación WordPress usando el chart Helm, es necesario utilizar los siguientes parámetros:

  • Habilitar Ingress usando el campo ingress --> enable=true.

  • Utilizar nginx con el campo ingress --> ingressClassName.

  • Habilitar el cifrado usando el campo ingress --> tls.

  • Anotaciones de configuración de reglas Ingress:

  • Activar la seguridad TLS: kubernetes.io/tls-acme=’true’

  • Especificar el objeto ClusterIssuer que se va a utilizar, usando la anotación cert-manager.io/cluster-issuer (letsencrypt-prod)

  • Especificar la dirección usando el campo ingress --> hostname=wordpress.eni.yannig.ovh.

A continuación, se muestra el contenido del archivo de configuración wordpress-test.yaml correspondiente:

# https://github.com/bitnami/charts/blob/master/bitnami/
wordpress/values.yaml 
 
ingress: 
  ingressClassName: nginx 
  enabled: true 
  tls: true 
  annotations: 
    kubernetes.io/tls-acme: "true" 
    cert-manager.io/cluster-issuer: "letsencrypt-prod" 
  hostname: "wordpress.eni.yannig.ovh"

 Con este archivo, lance el despliegue de WordPress:

$ helm upgrade --install wordpress bitnami/wordpress \ 
               --namespace test --create-namespace \ 
               -f wordpress-test.yaml

Espere a que el despliegue se complete y se propaguen las entradas de DNS.

3. Restringir los accesos

a. Referencia del conjunto de flujo

En el caso de WordPress, se permiten las siguientes comunicaciones:

  • El controlador Ingress se puede comunicar con el pod de WordPress....