Visualización de vulnerabilidades de aplicaciones en herramientas nativas de Kubernetes

A partir de las nuevas funciones de Kubernetes en Snyk Container, hemos estado experimentando con formas de integrar los datos de vulnerabilidades más estrechamente en el ecosistema de Kubernetes. Snyk ofrece un amplio conjunto de paneles y funciones de generación de informes, ideales si solo te enfocas en la seguridad. Pero ¿qué pasa si no quieres cambiar de contexto mientras trabajas con Kubernetes? ¿Podemos usar el amplio conjunto de API de Snyk Container para acercar la información sobre vulnerabilidades a Kubernetes?

Kubectl y la CRD de vulnerabilidades

Una forma de ampliar Kubernetes es mediante recursos personalizados. Este mecanismo permite agregar nuevos objetos a Kubernetes, que luego pueden manipularse con herramientas compatibles con la API de Kubernetes. Así, además de administrar Deployments y CronJobs, Kubernetes puede administrar tu nuevo recurso. Usemos una definición de recurso personalizado (CRD) para describir una vulnerabilidad.

kubectl apply -f https://raw.githubusercontent.com/snyk-labs/ksnyk/master/ksnyk/commands/vulnerability.yaml

Puedes comprobar que la CRD se instaló correctamente de esta manera:

$ kubectl api-resources --api-group snyk.io                                                                            NAME SHORTNAMES APIGROUP NAMESPACED KIND
  vulnerabilities   vuln,vulns snyk.io    true Vulnerability

Ahora debemos completar nuestra CRD con datos de Snyk. La integración de Snyk con Kubernetes analiza automáticamente las cargas de trabajo del clúster y detecta vulnerabilidades en las imágenes asociadas. Podemos leer esa información desde la API de Snyk e insertarla en Kubernetes con algunas de las herramientas disponibles en https://github.com/snyk-labs/ksnyk.

Una vez cargada la información, podemos usar cualquier cliente de la API de Kubernetes para enumerar las vulnerabilidades detectadas en nuestro espacio de nombres. Veamos cómo hacerlo en kubectl.

$ kubectl get vulns

NAME                             TITLE       PATH                 PACKAGE SEVERITY

snyk-linux-coreutils-104909      Improper Input Validation       replicationcontroller/example-rc:nginx coreutils medium
snyk-linux-coreutils-114540      Race Condition       replicationcontroller/example-rc:nginx coreutils medium
snyk-linux-expat-107842          Access Restriction Bypass       replicationcontroller/example-rc:nginx expat/libexpat1 medium
snyk-linux-expat-450908          XML External Entity (XXE) Injection    deployment.apps/snyky:docker.io/garethr/garethr_snyky   expat high
snyk-linux-expat-460765          XML External Entity (XXE) Injection    replicationcontroller/example-rc:nginx expat/libexpat1 high
snyk-linux-gcc8-447557           Out-of-Bounds       replicationcontroller/example-rc:nginx gcc-8/libstdc++6 high
snyk-linux-git-175991            Untrusted Search Path       deployment.apps/snyky:docker.io/garethr/garethr_snyky git high
snyk-linux-glibc-107098          Improper Input Validation       replicationcontroller/example-rc:nginx glibc/libc-bin medium
snyk-linux-glibc-121839          Resource Management Errors       replicationcontroller/example-rc:nginx glibc/libc-bin medium

El resultado muestra información breve sobre las vulnerabilidades, como su gravedad, la carga de trabajo afectada y el paquete de la imagen que las contiene. Puedes obtener más detalles, incluida una descripción completa, si consultas una sola vulnerabilidad.

$ kubectl get vulns snyk-linux-coreutils-104909 -o yaml                                                              
apiVersion: snyk.io/v1
kind: Vulnerability
metadata:
creationTimestamp: "2019-09-24T14:05:57Z"
generation: 1
name: snyk-linux-coreutils-104909
namespace: default
resourceVersion: "28382"
selfLink: /apis/snyk.io/v1/namespaces/default/vulnerabilities/snyk-linux-coreutils-104909
uid: 6e305adb-ded4-11e9-9bf7-025000000001
spec:
cvssScore: 6.5
cvssV3: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N
description: |
## Overview
chroot in GNU coreutils, when used with --userspec, allows local users to escape to the parent session via a crafted TIOCSTI ioctl call, which pushes characters to the terminal's input buffer.
## References

- [ADVISORY](https://security-tracker.debian.org/tracker/CVE-2016-2781)

- [http://www.openwall.com/lists/oss-security/2016/02/28/2](http://www.openwall.com/lists/oss-security/2016/02/28/2)

- [http://www.openwall.com/lists/oss-security/2016/02/28/3](http://www.openwall.com/lists/oss-security/2016/02/28/3)

disclosureTime: "2017-02-07T15:59:00Z"
image: nginx
isUpgradable: false
kind: replicationcontroller
language: linux
package: coreutils
packageManager: linux
path: replicationcontroller/example-rc:nginx
publicationTime: "2017-02-07T15:59:00Z"
resource: example-rc
severity: medium
title: Improper Input Validation
url: https://dev.snyk.io/vuln/SNYK-LINUX-COREUTILS-104909
version: 8.30-3

Muestra los datos de vulnerabilidades en los paneles de Octant

Octant es un nuevo panel de Kubernetes de VMware. Aunque se lanzó hace poco, Octant ya ofrece muchas de las funciones de la CLI de kubectl y también cuenta con un potente modelo de complementos.

En https://github.com/snyk-labs/ksnyk encontrarás instrucciones para instalar el complemento de Snyk para Octant e importar en Kubernetes los datos pertinentes desde la API de Snyk. Ten en cuenta que necesitas ser cliente de Snyk Container para usar la API.

Echa un vistazo al panel de Deployment a continuación. Deberías ver los datos de vulnerabilidades en el panel de estado, incluidos los recuentos de vulnerabilidades de gravedad alta, media y baja que tiene actualmente la carga de trabajo.

Octant también muestra muy bien la información sobre recursos personalizados. Por eso, al instalar la CRD de vulnerabilidades mencionada anteriormente, Octant muestra la información de vulnerabilidades de cada carga de trabajo del espacio de nombres que estás viendo.

Este prototipo apenas explora la información que podemos mostrar en Octant. También será interesante ver cómo crece el ecosistema de complementos de Octant y cómo podemos combinar los datos de vulnerabilidades en Kubernetes con otros recursos personalizados.

Conclusiones

Como señalamos, lo anterior son experimentos, no funciones terminadas, pero nos interesa recibir comentarios desde las primeras etapas. Si eres cliente de Snyk Container, puedes probarlos ahora con las herramientas disponibles en https://github.com/snyk-labs/ksnyk. Estas utilidades demuestran tanto la capacidad de ampliación de la plataforma Kubernetes como el poder de contar con una API de primera clase en Snyk sobre la que podemos desarrollar.