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

En la primera parte de este artículo sobre Kubernetes: Gestionar políticas de seguridad "Like a Boss" vimos cómo configurar el plugin CNI Cilium en un minikube para después comenzar en la segunda parte a configurar las políticas de seguridad de red en las diferentes comunicaciones. Al final de la entrada anterior terminábamos con el primer ejemplo y con una nueva pregunta.

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

En este momento, tras la configuración hecha en la parte 2 de esta serie, 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 cyberhades necesitan conectarse a nuestra base de datos?

Para ello creemos un espacio de nombres nuevo llamada cyberhades, al que además le añadimos la etiqueta team=cyberhades:

    kubectl create namespace cyberhades
    kubectl label namespace cyberhades team=cyberhades

Ahora ejecutamos nuestro cliente de mysql, pero le decimos a Kubernetes que los queremos en el espacio de nombres de cyberhades, para ello le añadimos la opción -n cyberhades:

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

Kubernetes, o mejor dicho Cilium, no nos debería dejar conectarnos. Para poder hacerlo, creamos una política nueva, igual que la anterior, pero además de permitir acceso a los pods con la etiqueta app=client, vamos también añadir el espacio de nombres cyberhades, y para ello haremos uso de la etiqueta team=cyberhades (allow-from-client-cyberhades.yaml):

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

Creamos la nueva política:

    kubectl apply -f allow-from-client-cyberhades.yaml

Probamos de nuevo el comando anterior:

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

Figura 12: Misma situación anterior, pero ahora también client desde el espaciode nombres
cyberhades también se puede conectar con mysql en el espacio de nombres default

Y esta vez deberíamos de poder conectarnos tanto de el espacio de nombres de cyberhades como default, como puede verse en el siguiente vídeo:

Figura 13: Configuración de pruebas de Cilium en minikube

Para interactuar con las políticas de red podemos hacerlo a través del comando kubectl [verbo] networkpolicy. Un comando muy útil es el comando kubectl describe networkpolicy. Este nos muestra cómo Kubernetes interpreta nuestra política. Es importante prestar mucha atención a cómo definimos nuestros ingress y egress, porque un simple guión fuera de lugar a la hora de definir nuestro array en el fichero YAML, puede cambiar por completo el significado de las restricciones aplicadas.

Fijémonos en el from de la última política que hemos creado:

    ...
      - from:
        - podSelector:
            matchLabels:
              app: client
          namespaceSelector:
            matchLabels:
              team: cyberhades
    ...

Esto se traduce a: permitir conexiones de los pods con la etiqueta app=client “Y” (“and”) de los espacios de nombre con la etiqueta team=cyberhades.

Ahora supongamos que el namespaceSelector tuviera un guion al principio:

    ...
      - from:
        - podSelector:
            matchLabels:
              app: client
        - namespaceSelector:
            matchLabels:
              team: cyberhades
    ...

Ese simple guión demás nos cambia por completo la condición de ingress, en este caso en vez de un “Y” (“and”) sería un “O” (or) es decir, permitir conexiones de los pods con la etiqueta app=client “o” desde el o los espacios de nombre con la etiqueta team=cyberhades. Por lo tanto, cualquier pod en el espacio de nombres con etiqueta team=cyberhades podría conectar a nuestro servidor.

Veamos como kubectl describe mostraría esos ejemplos.

    kubectl describe networkpolicy allow-from-client-cyberhades 
    ...
    ...
    Allowing ingress traffic:
        To Port:  (traffic allowed to all ports)
        From:
        NamespaceSelector: team=cyberhades
        PodSelector: app=client
    ...

    kubectl describe networkpolicy allow-from-client-o-cyberhades
    ...
    ...
    Allowing ingress traffic:
        To Port:  (traffic allowed to all ports)
        From:
        PodSelector: app=client
        From:
        NamespaceSelector: team=cyberhades
    ...

Vemos como en el primer ejemplo tenemos un from y en el segundo dos.

Para terminar, hay que añadir que es una buena práctica de seguridad el denegar por defecto todo el tráfico, tanto ingress como egress, y partir de ahí ir creando políticas para ir permitiendo el tráfico que vayas necesitando. De esta forma si un pod es comprometido, se lo ponemos más difícil al atacante a la hora de moverse lateralmente por nuestra red.

El fichero que deniega todo el tráfico tendría un contenido como este:

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

Finalmente, en este enlace tenéis un buen números de políticas comunes. Todos los ejemplos usados se pueden encontrar en el repositorio de GitHub que tenemos para estos menesteres: https://github.com/cyberhades/network-policy-examples

Figura 14: Scripts de ejemplos utilizados en este artículo

Cómo hemos visto a través de los ejemplos sólo hemos jugado con el tráfico entrante (ingress), pero de la misma forma podemos hacerlo con el tráfico saliente (egress), nuestro objetivo debería ser controlar y limitar el tráfico de red. Esperamos que estos ejemplos os sirvan de ayuda a la hora de construir vuestra infraestructura con 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.