Secure your Kubernetes applications with Snyk Container

We wrote previously about implementing container security throughout the SDLC, and discussed the trade offs of testing locally, in your CI/CD pipeline, against your registry, and in your Kubernetes cluster. With the new Kubernetes integration in Snyk Container, we’re aiming to make that last part both easier to do, and bring that information closer to developers so you can more quickly fix vulnerabilities and enable Kubernetes security.

Finding vulnerable Kubernetes applications with Snyk

Snyk already supports scanning images in your continuous integration pipelines, and importing images directly from your container registries. Our new Kubernetes integration extends this to your cluster. To enable the integration, you install a controller on your cluster, using our Helm Chart. The controller has read access to the Kubernetes API and detects your workloads and the images they are using.

The controller sends the information to Snyk where you can import specific workloads for us to analyze and report on.

With some of your workloads imported, Snyk will now display vulnerability information about the images, along with some metadata (for instance which cluster the workload is running, and the type of workload).

Workload security, not just image security

For a specific Kubernetes workload you may have 10s or 100s of pods, and potentially even more individual containers. But from a developers perspective those are really an implementation detail of the platform. Focusing vulnerability data on individual containers ignores this, and doesn’t align with the abstraction the developer is using, most likely the Deployment, CronJob, ReplicationController, etc.

Looking just at images in the cluster also misses context, which might be important in understanding the risk and in knowing what applications are actually affected.

As an example of this, when Snyk imports your Kubernetes workloads we collect important security configuration information alongside the image vulnerabilities.

This information should, at a glance, help you understand which workloads would benefit from configuration changes to better secure them. We’ll detect workloads that don’t drop capabilities, are missing CPU and memory limits (which can help mitigate against denial of service attacks), those not using read-only file systems and more.

Conclusions

The Snyk Kubernetes integration is available for paying customers as part of the Snyk Container product. We have lots of ideas to build upon this initial feature including making the controller more configurable, expanding reporting capabilities, utilizing configuration information to prioritize vulnerabilities and more. Check out the documentation for all the details and let us know what you think!