Afficher les vulnérabilités des applications dans les outils natifs de Kubernetes

En nous appuyant sur les nouvelles fonctionnalités Kubernetes de Snyk Container, nous avons expérimenté différentes façons d’intégrer plus étroitement les données sur les vulnérabilités à l’écosystème Kubernetes. Snyk propose un vaste éventail de tableaux de bord et de fonctionnalités de reporting, très utiles si vous vous concentrez uniquement sur la sécurité. Mais que faire si vous ne voulez pas quitter votre contexte de travail dans Kubernetes ? Peut-on s’appuyer sur le riche ensemble d’API de Snyk Container pour rapprocher les informations sur les vulnérabilités de Kubernetes ?

Kubectl et la CRD Vulnerability

L’une des façons d’étendre Kubernetes consiste à utiliser des ressources personnalisées. Ce mécanisme permet d’ajouter de nouveaux objets à Kubernetes, que les outils compatibles avec l’API Kubernetes peuvent ensuite manipuler. Ainsi, Kubernetes peut gérer vos nouvelles ressources, en plus des déploiements et des tâches Cron. Utilisons une définition de ressource personnalisée (CRD) pour décrire une vulnérabilité.

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

Vous pouvez vérifier que la CRD a bien été installée à l’aide de la commande suivante :

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

Nous devons maintenant alimenter notre CRD avec les données de Snyk. L’intégration Kubernetes de Snyk analyse automatiquement les charges de travail du cluster et détecte les vulnérabilités dans les images associées. Nous pouvons récupérer ces informations depuis l’API Snyk et les insérer dans Kubernetes à l’aide de certains outils disponibles sur https://github.com/snyk-labs/ksnyk.

Une fois les informations chargées, nous pouvons utiliser n’importe quel client de l’API Kubernetes pour répertorier les vulnérabilités détectées dans notre espace de noms. Voyons ce que cela donne avec 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

Le résultat présente un résumé des vulnérabilités, notamment leur niveau de gravité, la charge de travail concernée et le paquet de l’image qui contient la vulnérabilité. Vous pouvez obtenir davantage de détails, y compris une description complète, en demandant une vulnérabilité spécifique.

$ 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

Afficher les données sur les vulnérabilités dans vos tableaux de bord Octant

Octant est un nouveau tableau de bord Kubernetes proposé par VMware. Bien qu’il soit sorti récemment, Octant couvre déjà une grande partie des fonctionnalités de l’interface en ligne de commande kubectl et offre également un puissant système de plug-ins.

Vous trouverez sur https://github.com/snyk-labs/ksnyk les instructions pour installer le plug-in Octant de Snyk et importer dans Kubernetes les données pertinentes depuis l’API Snyk. Notez que vous devez être client de Snyk Container pour utiliser l’API.

Observez le tableau de bord du déploiement ci-dessous. Le volet d’état devrait afficher les données sur les vulnérabilités, notamment le nombre de vulnérabilités de gravité élevée, moyenne et faible que présente actuellement la charge de travail.

Octant affiche également très bien les informations sur les ressources personnalisées. Ainsi, l’installation de la CRD Vulnerability mentionnée précédemment permet à Octant de présenter les informations sur les vulnérabilités de chaque charge de travail dans l’espace de noms consulté.

Ce prototype ne fait qu’effleurer la surface des informations que nous pouvons afficher dans Octant. Il sera également intéressant de voir comment l’écosystème de plug-ins Octant se développe et comment combiner les données sur les vulnérabilités dans Kubernetes avec d’autres ressources personnalisées.

Conclusion

Comme indiqué, il s’agit d’expérimentations et non de fonctionnalités abouties, mais nous sommes à l’écoute de vos premiers retours. Si vous êtes client de Snyk Container, vous pouvez les essayer dès maintenant grâce aux outils disponibles sur https://github.com/snyk-labs/ksnyk. Ces utilitaires illustrent à la fois l’extensibilité de la plateforme Kubernetes et la puissance d’une API Snyk de premier ordre, sur laquelle nous pouvons nous appuyer.