Kubernetes: Gestionar políticas de seguridad de red “Like a Boss” (2 de 3)

En esta segunda del artículo que comenzamos ayer Kubernetes: Gestionar la política de seguridad de red "Like a Boss", vamos a continuar con los ejemplos. En la primera parte vimos cómo configurar el entorno de trabajo con minikube y el plugin CNI Cilium, y ahora vamos a continuar con las pruebas y nuevos ejemplos.

Figura 6: Kubernetes: Gestionar políticas de seguridad de red “Like a Boss” (2 de 3)

Ya hemos comentado antes que, por defecto, la comunicación entre pods está totalmente abierta y no existe ningún tipo de restricción de bloqueo ingress o egress. Pero veamos un ejemplo práctico que seguro que queda mucho más claro. Vamos a crear un pod con mysql en el nombre de espacio default, y luego crearemos otro pod con mysql, pero lo usaremos como cliente para conectarnos al servidor de mysql.

Fichero mysql.yaml:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: mysql
    spec:
      selector:
        matchLabels:
          app: mysql
      template:
        metadata:
          labels:
            app: mysql
        spec:
          containers:
          - image: mysql:5.6
            name: mysql
            env:
            - name: MYSQL_ROOT_PASSWORD
              value: password
            ports:
            - containerPort: 3306
              name: mysql

A este deployment le hemos añadido la etiqueta app=mysql. Esté será desplegado en el nombre de espacio default.

Nota: nunca pongas credenciales directamente de tus ficheros yaml

Para desplegar este fichero ejecutamos el siguiente comando:

kubectl apply -f mysql.yaml

Podemos monitorizar el progreso de despliegue para asegurarnos que se ha completado:

kubectl get pods -w

Ahora que tenemos corriendo nuestro mysql, vamos a ejecutar nuestro cliente para conectarnos al servidor. Para ellos vamos a coger la dirección IP del pod donde corre el servidor de bases de datos que nos interesa:

kubectl get pods -o wide

Ahora ejecutamos el cliente:

kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h IP -ppassword

Una vez que tengamos el prompt de mysql, podemos listar las bases de datos y salimos:

    show databases;
    ...
    exit

Figura 7: Se permite el tráfico entre pods dentro y fuera del espacio de nombres default

Ahora vamos a crear una política de red que deniegue todo tráfico ingress en todos los pods del nombre de espacio default. El contenido del fichero (deny-all-ingress.yaml) sería:

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: deny-all-ingress
    spec:
      podSelector: {}
      policyTypes:
      - Ingress

Creamos la nueva política:

kubectl apply -f deny-all-ingress.yaml

Ahora intentamos de nuevo ejecutar nuestro cliente y veremos que no se podrá conectar:

kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h IP -ppassword

Matamos el proceso y borramos el pod:

    ps -ef | grep kubectl 
    kill -9 ID_PROCESO

    kubectl delete po NOMBRE_POD

Figura 8: Los pods del espacio de nombres default no permiten tráfico entrante, pero sí saliente

Añadimos una política (allow-from-client.yaml) nueva que sólo permita ingress desde los pods con la etiqueta app=client:

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-client
    spec:
      podSelector:
        matchLabels:
        app: mysql
      policyTypes:
      - Ingress
      ingress:
      - from:
        - podSelector:
            matchLabels:
              app: client

Creamos la nueva política:

kubectl apply -f allow-from-client.yaml

Ahora ejecutamos de nuevo nuestro cliente, pero esta vez la añadimos la etiqueta app=client para que la política de red le deje conectar:

kubectl run -it --rm --image=mysql:5.6 --restart=Never --labels="app=client" mysql-client -- mysql -h IP -ppassword

Figura 9: El tráfico entrante haca client está bloqueado,
pero el entrante a mysql desde client está permitido

Ahora sí deberíamos poder conectarnos. En el siguiente vídeo se pueden observar todos los ejemplos de lo que hemos hablado hasta este momento.

Figura 10: Ejemplos de prueba de gestión de seguridad de red

En este momento, sólo los pods con la etiqueta app=client del espacio de nombres default, pero ¿qué ocurre si el equipo cyberhades desde su espacio de nombres cyberhade” necesitan conectarse a nuestra base de datos?. Pues lo vemos en la última parte de este artículo, donde continuaremos profundizando en todas las posibilidades que permite el uso de estas políticas de seguridad de red en entornos Kubernetes.

Happy Hacking Hackers!!!

*********************************************************************************************
- Kubernetes: Gestionar políticas de seguridad de red “Like a Boss” (1 de 3)
- Kubernetes: Gestionar políticas de seguridad de red “Like a Boss” (2 de 3)
- Kubernetes: Gestionar políticas de seguridad de red “Like a Boss” (3 de 3)
*********************************************************************************************

Autores:

Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.

Rafael Troncoso (@tuxotron) es Senior Software Engineer en SAP Concur, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" además del blog CyberHades. Puedes contactar con Rafael Troncoso en MyPublicInbox.