A recap of our Kubernetes configuration security announcement and webinar

Thank you to all who attended our release announcement webinar on Kubernetes configuration security on Wednesday, April 8. We’re excited to get this new feature in your hands and hear what you think and what you want us to build to help keep your Kubernetes applications secure.

We had some great questions during the webinar and we know many folks couldn’t attend live, so we wanted to provide you with a quick recap and answers to the questions we couldn’t get to during the event. Click here if you want to jump straight to the Q&A or skip all the way to the “How do I turn this on?” section if you’re eager to just get started.

Workloads and applications are increasingly deployed via code

These days, nearly everything gets configured by some sort of code. For infrastructure, you’re probably using Terraform, AWS CloudFormation, Azure Resource Manager, or a number of other formats and tools. But in the world of containers, the de facto standard is Kubernetes and that means YAML, JSON, or perhaps a higher-level tool like Helm. It’s all code of some sort, created by developers and DevOps practitioners, and used to deploy applications as fast as you can make changes.

From a security standpoint that’s scary. Not the YAML (that’s scary for different reasons), but the idea that Kubernetes doesn’t really have many security gates — if the code is valid, Kubernetes will do its best to run it, which means it’s up to the application teams to ensure the right controls are implemented in the code. Tools that provide security for these configurations typically look at your running Kubernetes workloads and clusters and identify problems; but catching problems after deployment is too late, especially when you might deploy multiple times per week or even per day.

Find and fix Kubernetes configuration issues at the source

One of our core goals at Snyk is to make it easier for developers to independently handle security issues and this new realm of configuration security is an area we believe we can make a difference. Our new Kubernetes configuration security feature integrates with your source code manager(s), where we can detect Kubernetes YAML, JSON, and Helm charts and check them for security issues.

Developer-focused fixes for Kubernetes configurations

When issues are detected, we highlight those issues directly in the context of your configuration files, so you can quickly see where changes are recommended. In addition, we provide explanations for the issues we detect, to help users understand the implications of each setting, so you don’t have to go searching through Kubernetes reference docs for each issue. Our risk categorization settings are configurable, including the ability to ignore particular configuration checks if you want.

Webinar Q&A

We had great questions on the webinar and wanted to make sure we provided answers to all of them.

Q. Does this work with any Kubernetes environment?

Currently, we’re scanning Kubernetes configuration files (YAML, JSON, and Helm) from source code repositories, so the Kubernetes distribution you use for running the workloads does not matter. All of our recommendations are part of the Kubernetes specifications, so any Kubernetes distribution should be able to apply the suggested controls.

Q. Does this work with anything other than Kubernetes YAML files?

We currently detect and scan for issues in YAML, JSON, and Helm Charts. If you use YAML generators or tooling that does templating the feature should generally work with most of those as well, as long as one of the supported file types is available for us to detect and scan.

Q. What kinds of configuration problems will this detect?

There are a number of configuration issues and we will be adding more over time. You can currently see which issues we detect by looking in the product settings in your Snyk console. Click the “Settings” item from the top horizontal menu and then look for “Infrastructure as code” on the left side sub-menus and that will show you the various detections and allow you to customize the severity or whether to ignore. The screen below shows the steps:

Q. Do I need to have a paid Snyk plan to use this feature?

No! This feature is available to ALL Snyk users on free and paid plans. We are rolling out the feature steadily and the plan is to have it enabled on every account in a week or so. If you are an on-premises Snyk customer, please contact your account team to discuss our on-prem support options.

Q. When will the feature be available?

The feature is enabled on most accounts and if it’s not available in your account today it should show up within the next week. You may need to enable the feature in your account and details for doing so are given below (hint: look for “Infrastructure as code” under your main “Settings” menu).

Getting started

It’s easy to get started with the Kubernetes configuration security feature. The most up-to-date information about the feature and how to use it is in our Snyk documentation, but here’s a brief overview:

Enable the feature in your account.

For new Snyk accounts, the feature should be enabled by default. Existing users may need to enable the Kubernetes configuration scanning feature. You can check your settings by going to the main “Settings” menu in the Snyk web console, then selecting “Infrastructure as code” from the side menu, and then clicking the “Enabled” slider and “Save changes” button.

Scan and fix Kubernetes configuration files from SCM

Today, the Kubernetes configuration scanning integrates with your source code managers, so you’ll need to have an integration with one of our supported git repositories set up in your account as well. We will then detect Kubernetes configuration files in that repository and provide recommended fixes. Note that if you have already added a repository to your account and are using Snyk to scan it, you will need to import the repository again in order to detect the Kubernetes configuration files and create the relevant projects.

We’re eager to hear your feedback as we continue to develop this new Kubernetes security feature.

Stay secure!