Following our IaC support for Helm charts within Checkov, we’ve had many requests to support the second most common templating framework for Kubernetes, Kustomize.

If you missed the Helm announcement, check out our documentation.

First, what is Kustomize?

Kustomize is an alternative to Helm for packaging and making per-environment changes to Kubernetes infrastructure as code (IaC) files.

With Helm, a “chart” must be created with its own syntax and templates, allowing a user to provide their own variables to change the resulting Kubernetes deployment at deployment time. The variables that can be modified are chosen by the author of the Helm chart.

Kustomize takes a much more free-form approach. Each Kustomize configuration starts with a “base” set of normal Kubernetes manifests, which can be modified by creating an “environment” or “overlay” directory that includes just the changes you wish to make to the base. Both of these files are 100% regular Kubernetes syntax; Kustomize simply merges the YAML together to provide the resulting Kubernetes configuration for that overlay.

In this way, the barrier to entry for making a Kustomize deployment is way lower than a Helm chart. However, inversely, there are no controls by the base author as to what can and, more importantly, cannot be changed, unlike Helm, where accessible variables are defined in the chart.

How Kustomize is used in CI/CD

Because Kustomize never touches the “base” Kubernetes manifests, it can be easily used to create environments (such as development, test, and production) with Kustomize used to define differences from a base configuration for each of those environments.

For example, traditionally, dev and test environments will need fewer resources, replicas, and instances of deployed applications.

Kustomize, or the built-in Kustomize support in kubectl, can then be pointed to an overlay directory and will merge the base manifests with any changes in the overlay, producing a set of Kubernetes manifests to be deployed for that environment. These can be used to run the deployment or environment upgrade as normal.

Kustomize security considerations

At the end of the day, both Kustomize and Helm produce Kubernetes manifests. However, in this shift-left world, waiting until deployment is a little late in the game to be identifying issues from the resulting manifests. Furthermore, it adds to developers’ chore lists to work out where the runtime issue stemmed from in the original Helm or Kustomize files.

Like all IaC frameworks, being able to check for security issues right from the start of the process is the easiest, fastest, and most efficient way to find and resolve issues.

That’s why we’ve added first-class Kustomize support to Checkov so that you can answer questions such as:

• Is the security misconfiguration in the base or one of my overlays?
• Which issues are common across all of my overlays?
• What could I add to the base manifest to improve the overall security posture of all environments?

And the best part is you don’t have to manually template out the Kustomize file structure.

Checkov for Kustomize

Follow along to scan some Kustomize manifests!

This is optional, but I like to create pip environments to keep my tools and dependencies separate. These commands will create a virtual python environment based on Python 3.9:

pipenv --python 3.9
pipenv shell

Output:

Now let’s install Checkov and test by getting the version. Kustomize support was added in 2.0.752, so make sure you’re running that version or later. macOS fans can alternatively brew install checkov too. 

pip install checkov
checkov --version

Output:

Now let’s scan some Kustomize for security misconfigurations.

But wait, you don’t have any Kustomize templates handy… There’s a repo for that!

KustomizeGoat to the rescue!

Saving the day (and looking precarious on mountains) like only goats can, KustomizeGoat is an educational resource containing three different Kustomize overlays of various security postures.

Let’s take it for a spin with Checkov and find out where our security issues lie!

The easiest way to use Checkov is checkov -d. This will enable all frameworks and scan all IaC within all subdirectories, including Kustomize, Dockerfiles, secrets, Terraform, and a whole lot more.

This is super useful for continuous integration (CI) environments as a “catch-all” for any infrastructure misconfigurations, but since we know we’re dealing with Kustomize, let’s thin out the output a little and tell Checkov only to scan Kustomize templates:

git clone https://github.com/bridgecrewio/kustomizegoat.git
cd kustomizegoat
checkov -d . –-framework kustomize

We can clean up this output even more to just failed checks and hide the helpful code segments if we wish, with the following extra Checkov flags:

git clone https://github.com/bridgecrewio/kustomizegoat.git
cd kustomizegoat
checkov -d . –-framework kustomize --quiet --compact

Output:

Notice Checkov gives us a separate set of outputs for each Kustomize overlay and the base manifests themselves. This is because each overlay has the ability to introduce (or fix) security issues, so we provide information on each, with a useful overlay name and path to the kustomization.yaml file in question:

If we wanted to scan just a single overlay, that works too:

checkov -d kustomize/overlays/prod --framework kustomize --quiet --compact

Taking it to the next level

To visualize large outputs more efficiently, or to capture a log of all previous CI runs without digging through output logs, connect to the Bridgecrew platform by simply passing an API key to the same Checkov commands to see the results in the Bridgecrew dashboard:

git clone https://github.com/bridgecrewio/kustomizegoat.git
cd kustomizegoat
checkov -d . –-framework kustomize –bc-api-key <Your API Key from https://bridgecrew.cloud>

Each Checkov run will then output a link to display the output within Bridgecrew:

Following the link provides a much more visual exploration of issues within the Bridgecrew platform with filters for criticality and type:

Previous CI runs are catalogued on the Code Reviews page:

Kustomize makes templatizing and reusing Kubernetes manifests easier without recreating entire manifests. Now with Checkov, you can make those manifests and all of the resulting environments more secure from the start.

We’d love your feedback and to hear about your Kubernetes Checkov use cases! Shout us at @bridgecrewio or come and join our Slack community!