Skip to content

Introduccion a CIS Benchmarks en Kubernetes

Desarrollo del tema

¿Qué es el CIS Benchmark en Kubernetes?

CIS significa Centro de seguridad de Internet. Es una organización global compuesta por profesionales, expertos en la materia y personas que se centran en mejorar la seguridad cibernética. Los puntos de referencia CIS son una serie de mejores prácticas y directrices que las empresas deben seguir para garantizar que su infraestructura de TI esté protegida contra numerosas amenazas y riesgos.

Existen muchos tipos de sistemas de TI y más de 140 puntos de referencia CIS para guiar hacia una ciberseguridad óptima. Un buen ejemplo es la infraestructura en la nube, en la que también puede encontrar una serie de mejores prácticas para configurar Kubernetes. Generalmente se denominan puntos de referencia CIS Kubernetes.

Propósito del CIS Benchmark en Kubernetes

Los puntos de referencia CIS brindan un conjunto específico de pautas adecuadas para Kubernetes y garantizan entornos de Kubernetes reforzados. De este modo, se protege de vulnerabilidades y configuraciones erróneas comunes. Los ingenieros de DevOps pueden utilizar diferentes herramientas para asegurarse de configurar los clústeres de Kubernetes de acuerdo con los puntos de referencia y también marcar cualquier configuración que no cumpla con el estándar CIS.

Diferentes partes del CIS Benchmark en Kubernetes

Los puntos de referencia CIS Kubernetes tienen varias partes que ayudan a deducir si una configuración es compatible o no y en qué medida afecta al sistema. Además de esto, los puntos de referencia también ayudan a las empresas a asignar la responsabilidad de garantizar el cumplimiento. Estas partes incluyen:

  • Puntuación: Los puntos de referencia CIS tienen varias recomendaciones debajo de cada uno de ellos. Estas recomendaciones cuentan con una prueba de evaluación en la que se comprueba la implementación de una recomendación. La recomendación se puntúa si la comprobación se puede realizar de forma automatizada. Por otro lado, si la verificación debe realizarse manualmente se conoce como no puntuado. Además, la puntuación también determinará qué tan seguro es el sistema y cuánto puede afectar al sistema la implementación de la recomendación.

  • Niveles: Hay dos niveles de recomendaciones de seguridad. El nivel 1 comprende medidas de seguridad básicas que no interfieren con el funcionamiento normal del sistema. El nivel 2 incluye medidas de seguridad que abordan la seguridad de Kubernetes en un nivel más profundo. Si bien esto puede garantizar el cumplimiento, lleva más tiempo implementarlo y podría interferir con el funcionamiento normal de la infraestructura.

  • Resultados: Hay dos resultados posibles una vez finalizada la evaluación. Pasar significa que la recomendación está incorporada a la infraestructura. Fallar significa que no se ha incorporado al sistema Kubernetes. Además, el punto de referencia detalla los próximos pasos y las soluciones que los ingenieros de DevOps pueden tomar para solucionar el problema y cambiar el estado de Pasa a Falla.

  • Responsabilidad: La parte final, la responsabilidad, se refiere a la entidad que debe incorporar la recomendación. Generalmente es la organización, pero también hay casos en los que es la empresa y el proveedor quien proporciona el servicio en la nube.

  • Configuración de componentes: CIS Benchmark se acepta en la comunidad nativa de la nube para configurar componentes de Kubernetes. El cumplimiento se puede garantizar mediante la configuración manual, que puede ser una tarea ardua, o preferiblemente mediante el uso de diversas herramientas que puedan automatizar el proceso haciéndolo más eficiente y seguro. Las configuraciones recomendadas de los componentes clave se enumeran a continuación.

Laboratorio: CIS Benchmark usando Trivy

Trivy es una herramienta poderosa y flexible para asegurar imágenes de contenedores y configuraciones de Kubernetes. Integrar Trivy en el flujo de trabajo de tu clúster de Kubernetes y en los pipelines de CI/CD puede ayudar a detectar y corregir vulnerabilidades y configuraciones inseguras de manera proactiva, mejorando significativamente la seguridad de tus aplicaciones y tu infraestructura en Kubernetes.

Instalación del operador y binario Trivy en el Cluster de Kubernetes

  1. Agregue el repositorio HELM 
    helm repo add aqua https://aquasecurity.github.io/helm-charts/
  2. Actualizar el repositorio Helm 
    helm repo update
  3. Ingresar al cluster de Kubernetes por medio de KUBECONFIG: 
    export KUBECONFIG=$HOME/devcluster/kube_config_cluster.yml
  4. Verificar que ha ingresado correctamente 
    kubectl version
    Lo anterior debe mostrar una salida como la siguiente: 
    Client Version: v1.28.9
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.9
  5. Instalación del Operador por medio del paquete Helm 
    helm install trivy-operator aqua/trivy-operator \
     --namespace trivy-system \
     --create-namespace \
     --version 0.21.4
    La salida del comando anterior debera ser como la siguiente: 
    NAME: trivy-operator
LAST DEPLOYED: Tue May 28 18:17:49 2024
NAMESPACE: trivy-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
You have installed Trivy Operator in the trivy-system namespace.
It is configured to discover Kubernetes workloads and resources in
all namespace(s).
Inspect created VulnerabilityReports by:
    kubectl get vulnerabilityreports --all-namespaces -o wide
Inspect created ConfigAuditReports by:
    kubectl get configauditreports --all-namespaces -o wide
Inspect the work log of trivy-operator by:
    kubectl logs -n trivy-system deployment/trivy-operator
  6. Instalacion de binario de trivy 
    curl -LO https://github.com/aquasecurity/trivy/releases/download/v0.51.1/trivy_0.51.1_Linux-64bit.tar.gz
tar -xzf ./trivy_0.51.1_Linux-64bit.tar.gz 
sudo mv ./trivy /usr/local/bin/

Objetivos

  • Escanear un cluster , obtener y analizar las vulnerabilidades obtenidas.
  • Conocer los diferentes tipo de Escaneos que existen para un cluster de kubernetes.

Antes de comenzar

  • Contar con el acceso al ambiente del laboratorio.

  • Haber completado "Instalación de binario Trivy".

Conexión hacia cluster

  1. Ingrese al cluster asignado con las credenciales proporcionadas.

  2. Obtenga el archivo kubeconfig posicionando sobre la carpeta a trabajar y cambiando su nombre a config.

    mv /path/to/kubeconfig ~/.kube/config

  3. Configure la variable KUBECONFIG.

    export KUBECONFIG=~/.kube/config

  4. Verifique el acceso mediante comandos.

    kubectl get namespaces
kubectl config set-context --current --namespace=userx

Inicio de laboratorio

  1. Crear una carpeta nueva llamada benchmarks e ingresar a la misma. 
    mkdir benchmarks
cd benchmarks
  2. Vamos a revisar nuestra version de trivy con el siguiente comando. 
    trivy version
  3. Para empezar a ver el funcionamiento de trivy vamos a descargar una imagen de contenedor basica y la vamos a analizar. 
    docker pull nginx:alpine
trivy image nginx:alpine --output result.json
  4. Nuestro scan ha sido guardado en el archivo result.json, en formato de tabla, en este archivo podemos ver todas las vulnerabilidades que posee la imagen, ademas de eso podemos ver que version tenemos y en que version fue arreglada esta vulnerabilidad, en el caso de que si se haya arreglado, como se ve a continuacion. 
    cat result.json
    Scan nginx

  5. Ahora que ya nos familiarizamos un poco con trivy vamos a ejecutar un analisis de nuestro cluster de kubernetes, este analisis se hara tomando como base el benchmark de CIS. 

    trivy k8s --compliance=k8s-cis --report summary --timeout 1800s -o cis.json

  6. Luego de pasados 5 a 10 minutos vamos a tener nuestro archivo de cis con un resumen de las pruebas que se realizaron y su estatus , es decir si pasaron o fallaron, en nuestro caso tenemos un par de pruebas fallidas como se ven a continuacion.

    Scan fail

  7. Uno de los puntos que es necesario conocer de trivy es que nos permite scanear namespace en especifico, esto nos sirve ya que hay namespace que estan fuera de nuestro control, como lo viene siendo el kube-system, en ese caso podemos scanear un namespace en especifico para , en nuestro caso vamos a escanear el namespace de cattle-system 

    trivy k8s --compliance=k8s-cis --report summary --timeout 1800s -o rancher.json --include-namespaces cattle-system
    Vemos primeramente que se tardo menos, y si revisamos el archivo, con el comando. 
    cat rancher.json
    observamos que se le realizaron las mismas pruebas que cuando se hizo a nivel de cluster.

  8. Por ultimo vamos a realizar un scan a nivel de cluster utilizando el compliance de k8s-pss-restricted y donde solo se nos muestren vulnerabilidades altas. 

    tv k8s --compliance=k8s-pss-restricted --report all --timeout 1800s -o critical.json --severity HIGH

  9. Al inicio de la practica se instalo el operador de trivy , lo que este operador hace es que esta constantemente scaneando el ambiente y guadas estos scans como CRD en el cluster. Vamos a obtener un par de CRDS y vamos a verificar su contenido.

  10. Vamos a crear un deployment que sea vulnerable con el comando. 

    kubectl create deployment nginx --image nginx:1.16

  11. Vamos a esperar un par de minutos y vamos a obtener el analisis con el comando. 

    kubectl get vulnerabilityreports -o wide
kubectl get configauditreports -o wide

  12. Limpiamos el ambiente:

    cd ~; rm-rf benchmarks
helm uninstall trivy-operator -n trivy-system
kubectl delete deployment nginx