Write secure Kubernetes configuration with help from Snyk

Last week we launched Snyk Container and today we have an exciting followup to that news.  We are releasing a beta of a new Snyk feature to help you find and fix issues with your Kubernetes configuration as part of your development process.

The configuration problem

As we discussed in the From Image Security to Workload Security blog post, configuration is both:

1. Shifting from being an operator concern to a developer one, and

2. Has the potential to introduce security issues, or make vulnerabilities easier to exploit

At the same time, most tools designed to help with this problem don’t take into account modern developer workflows. They might help you catch issues in production, but what about fixing them? Or catching them before you deploy the changes?Kubernetes is a good example of the above. Kubernetes is powerful, but that comes with a certain level of complexity. The Kubernetes API contains lots of objects, and each of those has lots of properties. Too often developers are managing all of that by hand in YAML files.  As a general purpose platform, Kubernetes also doesn’t have the most secure defaults. It’s easy to forget to set all of the security properties all of the time.

Automatically surfacing configuration issues in Snyk

Snyk started focused on package manifest files like project.json, pom.xml, or requirements.txt. Snyk integrates with your source control system like GitHub or GitLab, and we will detect those manifest files and help you secure your applications. With the new beta functionality we’re shipping today, we’ll also detect Kubernetes configuration files in your repositories. When we find a Kubernetes config file, we’ll scan it for common configuration issues, and surface them in Snyk.

Whether you have a single repository with all of your configuration in one place, or have configuration spread across different repositories, we can check for things like containers running as root, missing CPU or memory limits, readable file systems and more. We’ll also be expanding the number of checks we perform as we go.

Fixing issues with pull requests

For each of the issues we identify, we’ll provide the context, as well as let you know why this is potentially an issue. As with vulnerabilities in Snyk, you can choose to ignore specific problems or automatically create issues in Jira to track fixing them. The issues are also available in the Snyk API for integration into other systems.

More importantly, we also want to help you fix them, where the issue has an obvious and safe resolution. Similar to how we help developers fix issues with vulnerabilities, we’re integrating directly into your source control system and issuing pull requests to your configuration. This not only helps you find issues as you write the configuration, but fixing them is as simple as merging a pull request. Especially with the scale of configuration in microservice environments and in growing teams, this level of automation isn’t just a nice-to-have, it’s required if you’re going to move quickly and stay secure.

Conclusions

We’re releasing this feature as a private beta today, for a small number of interested users. We would like to gather more feedback, and we have lots of features left to add, before making it available to everyone. If you are interested in trying this functionality out you’ll need to sign up for the beta.