Showing application vulnerabilities in Kubernetes-native tooling

Building on the new Kubernetes features in Snyk Container, we’ve been experimenting with integrating vulnerability data more closely into the Kubernetes ecosystem. Snyk has an extensive set of dashboards and reporting features, which are great if you’re focused just on security. But what about if you don’t want to switch context from what you’re doing with Kubernetes? Can we use the rich set of APIs in Snyk Container to bring vulnerability information closer to Kubernetes?

Kubectl and the Vulnerability CRD

One way of extending Kubernetes is with custom resources. This is a mechanism for adding new objects to Kubernetes, which can then be manipulated by tools that know how to work with the Kubernetes API. So as well as managing Deployments and CronJobs, Kubernetes can manage your new resource. Let’s use a custom resource definition (CRD) to describe a vulnerability.

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

You can check that the CRD has been correctly installed like so:

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

We now need to populate our CRD with data from Snyk. The Snyk Kubernetes integration automatically scans workloads in the cluster and determines vulnerabilities in the associated images. We can read that information from the Snyk API, and insert it into Kubernetes using some of the tools found in https://github.com/snyk-labs/ksnyk.

With information loaded, we can use any Kubernetes API client to list the vulnerabilities found in our namespace. Let’s see that in 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

The output shows brief details of the vulnerabilities, including severity, the affected workload, and which package in the image contains the vulnerability. You can get even more details, including a full description, by asking for a single vulnerability.

$ 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

Show vulnerability data in your Octant dashboards

Octant is a new Kubernetes dashboard from VMware. Although only recently released, Octant already covers a lot of the ground of the kubectl CLI and also features a powerful plugin model.

Instructions for installing the Snyk Octant plugin, and importing the relevant data into Kubernetes from the Snyk API can be found in https://github.com/snyk-labs/ksnyk. Note that you’ll need to be a Snyk Container customer to use the API.

Take a look at the Deployment dashboard below. You should see vulnerability data in the status pane, including how many high, medium, and low severity vulnerabilities the workload currently has.

Octant also does a great job of displaying information about Custom Resources too. So installing our Vulnerability CRD mentioned above results in Octant surfacing vulnerability information for each workload in the namespace you’re viewing.

This prototype really just scratches the surface of the information we can surface in Octant. It will also be interesting to see how the Octant plugin ecosystem grows, and how we can combine vulnerability data in Kubernetes with other custom resources.

Conclusions

As noted, the above are experiments rather than finished features, but we’re interested in early feedback. You can try them out now if you’re a Snyk Container customer, using the tooling at https://github.com/snyk-labs/ksnyk. These utilities demonstrate both the extensibility of the Kubernetes platform and the power of having a first-class API in Snyk we can build upon.