[NSX] Advanced Security Series 1: Desplegando NSX Application Platform

NSX-T (De ahora en adelante NSX) bajo mi punto de vista, es la mejor plataforma de virtualización de red disponible en el mercado.

Además de ofrecer un entorno SDN flexible, moderno y fácilmente escalable dentro de nuestro Data Center, NSX ofrece varias funcionalidades de seguridad desde un punto de vista de red que lo convierten en un gran aliado a la hora de proteger nuestras VMs.

Estas funcionalidades son:

• Firewall Distribuido, a nivel de vmnic dentro de cada una de nuestras VMs, dotandolo de una enorme granularidad tanto en el N-S como en el E-O (microsegmentación).
• Gateway Firewall, firewall que corre a nivel de puerta de enlace, convirtiéndolo en un sustituto perfecto al firewall perimetral tradicional. 
• Identity Firewall, firewall sincronizado con nuestro directorio activo o LDAP, permitiendo establecer conjuntos de reglas a nivel de grupo de AD. Resultando de gran utilidad en entornos de VDI.
• Distributed IDS/IPS, IDS/IPS capaz de detectar y prevenir tanto en el Norte-Sur, como en el Este-Oeste, sin necesidad de configuraciones o topologías complejas, ni de configurar port-mirroring para su funcionamiento.
• Malware Prevention, capaz de realizar un análisis profundo de archivos en cada una de nuestras VMs Windows impidiendo la descarga de malware mediante un bloqueo a nivel de red. 
• NSX Intelligence, motor de análisis distribuido capaz de detectar todos los flujos de tráfico dentro de nuestro DC y ofrecernos recomendaciones de seguridad personalizadas para cada uno de ellos.
• NSX Network Detection and Response (NDR), Panel de análisis para la correlación y visualización de amenazas hacia nuestro entorno.

Éstas 3 últimas (Malware Prevention, NSX Intelligence, NSX NDR) requieren del despliegue de NSX Application Platform para funcionar.

NSX Application Platform es una moderna plataforma de microservicios que corre dentro de un cluster de Kubernetes. En esta guía vamos a aprender a desplegarlo.

Prerequisitos

• NSX-T 3.2 o NSX 4.0
• Licencia de NSX ATP Válida
• Un entorno de Kubernetes (TKG, vSphere with Tanzu, Standalone)…
• Conectividad a internet desde el NSX Manager
• Conectividad entre la red de Ingress de K8s y el NSX Manager
• Un servidor DNS

1. (Vsphere with Tanzu), creando nuestro cluster de Kubernetes

En primer lugar, deberemos tomar como referencia la tabla de requisitos de VMware, para dimensionar un cluster que cumpla con los requisitos, en función del factor de forma que queramos instalar de NSXAP:

1.1 Tabla de dimensionamiento de cluster oficial de VMware

1.2 Creando la VM Class necesaria para los workers. (vSphere with Tanzu)

En mi caso, el factor de forma que quiero desplegar es evaluación ya que usaré el entorno para pruebas, por lo que desplegaré 1 control node y 1 worker añadiendo un volumen adicional de 64Gb tal y como se indica en los prerequisitos.

Según indica VMware, los workers para este factor de forma deben contar con 16vCPU y 64 GB de RAM, sin embargo por defecto en vSphere with Tanzu no hay ninguna VM Class con estas características, por lo que la crearemos.

En nuestro vCenter, iremos a «Workload Management» – «Services» y pincharemos en «Create VM Class»

A continuación, introduciremos:

• vCPU Count: 16
• Memory: 64 GB

Los parámetros de reserva son opcionales en función de la disponibilidad de recursos que queramos darle al entorno.

A continuación, iremos a nuestro namespace y añadiremos la VM class que acabamos de crear

Con esto, ya tendremos nuestro entorno de vSphere with Tanzu listo para desplegar un cluster con las características solicitadas.

1.3 Desplegando el cluster (vSphere with Tanzu)

El siguiente paso será preparar nuestro YAML para la creación del cluster, en mi caso será el siguiente:

apiVersion: run.tanzu.vmware.com/v1alpha1      #TKGS API endpoint
kind: TanzuKubernetesCluster                   #required parameter
metadata:
  name: nsxap                        #cluster name, user defined
  namespace: nsxap                   #vsphere namespace
spec:
  distribution:
    version: v1.20.7                             #Resolves to compatible TKR 1.20
  topology:
    controlPlane:
      count: 1                                 #number of control plane nodes
      class: guaranteed-small                #vmclass for control plane nodes
      storageClass: vsan-default-storage-policy          #storageclass for control plane
      volumes:
        - name: containerd
          mountPath: /var/lib/containerd
          capacity:
            storage: 64Gi
    workers:
      count: 1                                 #number of worker nodes
      class: nsx-class                #vmclass for worker nodes
      storageClass: vsan-default-storage-policy         #storageclass for worker nodes
      volumes:
        - name: containerd
          mountPath: /var/lib/containerd
          capacity:
            storage: 64Gi

Aplicamos y el cluster empezará a crearse, esperamos a que esté listo:

2. Creando los roles necesarios y obteniendo el Kubeconfig

Una vez que nuestro cluster esté listo, necesitaremos crear el ServiceAccount y ClusterRoleBinding correspondientes para que NSX pueda logar y crear objetos en el cluster.

2.1 Opción A: Script para generación automatizada de Kubeconfig

Para simplificar esta tarea, he creado un script que se encarga automáticamente de crear estos roles y obtener el kubeconfig (Si usamos vSphere with Tanzu) o bien obtener el kubeconfig (Cualquier otro cluster de Kubernetes) automáticamente una vez creados estos roles.

Podéis descargarlo aquí, o si preferís no descargarlo, podéis ver y copiar el contenido aquí:

# /bin/bash
echo "*****************************************************"
echo "* NSX Application Platform Kubeconfig obtain script *"
echo "*               https://sd-juan.es                  *"
echo "*                 September, 2022                   *"
echo "*****************************************************"
echo "Please, chose an option:"
echo "1. Automatically create the Service Account and Clusterrolebinding, and then get the Kubeconfig (Vsphere with Tanzu)"
echo "2. I have already created the SA and CRB, Just get the kubeconfig (Other kubernetes deployments)"
echo ""
read -p "Option: " option

if [[ "$option" == "1" ]]
then
  printf "\nPlease input the IP of your supervisor cluster"
  read -p "Supervisor cluster IP: " supervisor_cluster_ip
  printf "\nPlease, input your vSphere SSO User: "
  read "ssouser"
  printf "\nPlease input the namespace where your cluster resides: "
  read namespace
  printf "\nPlease input the cluster name: "
  read cluster_name
  echo "**********************************************************************************************"
   if kubectl vsphere login --server $supervisor_cluster_ip -u $ssouser --tanzu-kubernetes-cluster-name $cluster_name --tanzu-kubernetes-cluster-namespace $namespace --insecure-skip-tls-verify
   then
     echo "**********************************************************************************************"
     echo "Login OK"
     echo "**********************************************************************************************"
     echo "Creating the required SA and CRB"
     echo "**********************************************************************************************"
     sleep 2
     if kubectl create serviceaccount napp-admin -n kube-system && kubectl create clusterrolebinding napp-admin --serviceaccount=kube-system:napp-admin --clusterrole=cluster-admin
     then
       echo "**********************************************************************************************"
       echo "SA and CRB created"
       echo "**********************************************************************************************"
       printf "\nPlease, input the name of the kubeconfig file to be created"
       read -p "kubeconfig name: " kubeconfigname

       SECRET=$(kubectl get serviceaccount napp-admin -n kube-system -ojsonpath='{.secrets[].name}')
       TOKEN=$(kubectl get secret $SECRET -n kube-system -ojsonpath='{.data.token}' | base64 -d)
       kubectl get secrets $SECRET -n kube-system -o jsonpath='{.data.ca\.crt}' | base64 -d > ./ca.crt
       CONTEXT=$(kubectl config view -o jsonpath='{.current-context}')
       CLUSTER=$(kubectl config view -o jsonpath='{.contexts[?(@.name == "'"$CONTEXT"'")].context.cluster}')
       URL=$(kubectl config view -o jsonpath='{.clusters[?(@.name == "'"$CLUSTER"'")].cluster.server}')
       TO_BE_CREATED_KUBECONFIG_FILE=$kubeconfigname
       filepath() {
          readlink -f $TO_BE_CREATED_KUBECONFIG_FILE
       }
       if kubectl config --kubeconfig=$TO_BE_CREATED_KUBECONFIG_FILE set-cluster $CLUSTER --server=$URL --certificate-authority=./ca.crt --embed-certs=true && kubectl config --kubeconfig=$TO_BE_CREATED_KUBECONFIG_FILE set-credentials napp-admin --token=$TOKEN && kubectl config --kubeconfig=$TO_BE_CREATED_KUBECONFIG_FILE set-context $CONTEXT --cluster=$CLUSTER --user=napp-admin && kubectl config --kubeconfig=$TO_BE_CREATED_KUBECONFIG_FILE use-context $CONTEXT
       then
       echo "**********************************************************************************************"
       echo "kubectl file created on" ; filepath
       echo "**********************************************************************************************"
       exit
       fi
       echo "Error creating Kubeconfig, Check folder permissions"
       exit
    fi
    echo "Error while creating roles, please check above"
    exit
  fi
  echo "Error while connecting to vSphere, please check your parameters"
  exit
elif [[ "$option" == "2" ]]
then
  printf "\nPlease, input the name of the kubeconfig file to be created"
  read -p "kubeconfig name: " kubeconfigname
  SECRET=$(kubectl get serviceaccount napp-admin -n kube-system -ojsonpath='{.secrets[].name}')
  TOKEN=$(kubectl get secret $SECRET -n kube-system -ojsonpath='{.data.token}' | base64 -d)
  kubectl get secrets $SECRET -n kube-system -o jsonpath='{.data.ca\.crt}' | base64 -d > ./ca.crt
  CONTEXT=$(kubectl config view -o jsonpath='{.current-context}')
  CLUSTER=$(kubectl config view -o jsonpath='{.contexts[?(@.name == "'"$CONTEXT"'")].context.cluster}')
  URL=$(kubectl config view -o jsonpath='{.clusters[?(@.name == "'"$CLUSTER"'")].cluster.server}')
  TO_BE_CREATED_KUBECONFIG_FILE=$kubeconfigname
  filepath() {
     readlink -f $TO_BE_CREATED_KUBECONFIG_FILE
  }
  if kubectl config --kubeconfig=$TO_BE_CREATED_KUBECONFIG_FILE set-cluster $CLUSTER --server=$URL --certificate-authority=./ca.crt --embed-certs=true && kubectl config --kubeconfig=$TO_BE_CREATED_KUBECONFIG_FILE set-credentials napp-admin --token=$TOKEN && kubectl config --kubeconfig=$TO_BE_CREATED_KUBECONFIG_FILE set-context $CONTEXT --cluster=$CLUSTER --user=napp-admin && kubectl config --kubeconfig=$TO_BE_CREATED_KUBECONFIG_FILE use-context $CONTEXT
  then
  echo "**********************************************************************************************"
  echo "kubeconfig file created on"; filepath
  echo "**********************************************************************************************"
  exit
  fi
  echo "Error creating Kubeconfig, Check folder permissions"
  exit
else
 echo "No valid option chosen, exiting"
fi

2.2 Opción B: Creando los roles manualmente

En caso de no estar utilizando vSphere with Tanzu, necesitaremos logarnos manualmente en el cluster y crear los roles usando el siguiente comando:

kubectl create serviceaccount napp-admin -n kube-system # creates the napp-admin serviceaccount in the kube-system namespace
kubectl create clusterrolebinding napp-admin --serviceaccount=kube-system:napp-admin --clusterrole=cluster-admin # creates the required clusterrolebinding for the napp-admin user

En caso de no querer automatizar la creación del kubeconfig, podemos seguir los pasos para obtenerlo indicados por VMware.

3. Registrando los servicios de mensajería e Interfaz en DNS

NSX Application Platform requiere de la exposición de dos servicios para funcionar

• Interface Service: Será el endpoint de HTTPS por el que el NSX Manager se conectará con Application Platform
• Messaging Service: Se utilizará para recibir datos de los colectores de NSX integrados en application platform

Estos dos servicios deben estar registrados en DNS previamente al despliegue, ya que NSX hará una búsqueda inversa en el momento del despliegue, y en caso de no encontrarlos fallará la instalación.

Ambos servicios deben registrarse con una IP dentro de nuestra red de Ingress de Kubernetes.

En mi caso, mi DNS es Windows Server, y mi red de Ingress es 172.16.242.0/24, por lo que he escogido las siguientes FQDNs e IPs para registrar mis servicios

• Interface Service:

• Messaging service:

4. Desplegando NSX Application Platform

4.1 Parámetros de despliegue

Una vez obtenido el kubeconfig, podemos proceder a desplegar NSX Application Platform. Para ello, en nuestro NSX Manager iremos a System – NSX Application Platform y pulsaremos en «Deploy NSX Application Platform«

Introduciremos el Helm repository y el Docker registry públicos de VMware:

Helm repository: https://projects.registry.vmware.com/chartrepo/nsx_application_platform
Docker registry: projects.registry.vmware.com/nsx_application_platform/clustering

Escogeremos la versión de NSXAP a desplegar, y continuaremos

En la siguiente pantalla, cargaremos el kubeconfig creado en el paso 2, así como introduciremos la FQDN de los servicios registrados en el paso 3, y escogeremos el factor de forma de nuestro NSX Application Platform.

Este factor de forma debe coincidir con el cluster creado en el paso 1

4.2 Preckecks y despliegue

En la siguiente pantalla correremos los prechecks, y si todo esta correcto, podremos avanzar al despliegue:

Pulsaremos en «Deploy» y esperaremos hasta que NSX Application Platform despliegue

Si todo ha ido bien, pasados unos minutos deberíamos de ver la siguiente pantalla, confirmándonos que ya podemos utilizar NSX Application Platform y activar funciones avanzadas de seguridad como NSX Intelligence, NSX Malware Prevention o Network Detection and Response

Como siempre, espero que os haya sido de utilidad y lo hayáis disfrutado tanto como yo. ¡No dudéis en comentar cualquier sugerencia o cuestión.!