Starting with Kubernetes is relatively easy. What is hard is doing it the right way, applying all the best practices, and preventing misconfigurations to affect the security and reliability of your production environments.

Luckily, there is a tool that not only can do it for us, but it is also powerful, really easy to use, and you can start with it for free! Datree.

Today I'm going to tell you everything about it: how to install it, what it can do for us, how to use it locally and in our CI systems, and of course why we would want to use it.

About Shifting Left

If you've been following this blog or the YouTube Channel for a while, you know that I'm a big proponent of the shift-left strategy.

Whether it is testing, security, or validation, I believe we should do it as soon as possible in the development workflow.

When it comes to validation and security, however, there are just a handful of tools that are really designed with that "shif-left" in mind. And if we talk about Kubernetes-specific tools, then you can count them on the fingers of one hand.

Today we talk about one of those tools, which promises to be the one-stop-shop for Kubernetes and Helm configuration and best practices validation. And boy it delivers!

About Datree

The tool I'm talking about is called Datree. It's a CLI-based tool which works on Windows, Linux, and MacOS, and it is Open Source.

datreeio / datree

Prevent Kubernetes misconfigurations from reaching production (again 😤 )! From code to cloud, Datree provides an E2E policy enforcement solution to run automatic checks for rule violations. See our docs: https://hub.datree.io

Datree can do several things for us, and we will explore them in just a second, but the key point for me is that it works just the same on a local development environment, in any CI system, and anywhere else.

It can even be configured as a pre-commit git hook, allowing us to truly shift the Kubernetes validation left. (Take a look here for references on this)

At the time of writing, Datree uses some 30 predefined rules and policies based on best practices, but it allows you to customize those rules and, in the very near future, even define new custom rules to fit all your needs.

Video

As usual, if you are a visual learner, or simply prefer to watch and listen instead of reading, here you have the video with the whole explanation and demo, which to be fair is much more complete than this post.

Link to the video: https://youtu.be/aM7EVflmEt4

If you rather prefer reading, well... let's just continue :)

Installing Datree

Demo for this section in the video starts at minute 2:04

Alright, enough talking, let's install it and see it in action.

If you are on Linux or MacOS, you can just execute this command:

curl https://get.datree.io | /bin/bash

In Windows instead, you can use PowerShell:

iwr -useb https://get.datree.io/windows_install.ps1 | iex

There are also options to run this in Docker, or using Homebrew (see here)

As you can see, the installation is really quick, just one command, and it is also very fast.

There is one more step we should do for a proper configuration, but will see that in just a second. Let's first try and use the tool.

First Scan with Datree

Demo for this section in the video starts at minute 3:05

To start a scan with Datree, you use the datree test command, passing the file(s) you want to scan:

datree test myk8smanifest.yml

After just a few seconds, the tool will get you the output:

As you can see the tool does multiple things:

it validates the YAML, to make sure everything is ok (_so it is basically also a YAML linter)
it validates the Kubernetes-specific schema against a predefined version
it checks the manifest against the policies

At the bottom there is a summary table that also contains a link with a cliId, or token:

A new token is generated every time you execute the very first scan on a new system.

If you click on the link, the login page will show up and you have the choice to login (create a new account) using you GitHub or Google account.

After logging in, the Datree Dashboard appears.

This is the Centralized Policy Management dashboard, which is one of the key points of the service. In here you can see the rules that are applied to the scans (by default 21 over 30) and for each rule you can have additional information clicking on the i button.

This will take you to the documentation page relative to that rule, where you can find the complete information about it.

The interface is pretty minimal, but I appreciate it because it contains all and only the information you need and therefore it is not confusing.

Kubernetes Schema Version

Demo for this section in the video starts at minute 5:46

As mentioned before, Datree validates your manifests for a specific predefined version of the Kubernetes schema. There are 2 ways to change the version.

Via the Settings

The first way is to go to the settings (using the user icon in the upper right and selecting settings).

Here you have the dropdown for the version selection, from v1.15.0 to the latest one.

Be careful with this setting, though, because changing the version here will change it for each and every scan you perform with Datree.

Via the CLI

If you want to perform a one-off scan against a specific Kubernetes schema version, instead, you can override the value in settings using the --schema-version CLI flag:

datree test --schema-version 1.20.0 myk8smanifest.yml

This, for example, will run the schema validation against the version 1.20.0 of Kubernetes schema, no matter what the default selected version is.

Configuring Datree

Demo for this section in the video starts at minute 6:44

As I've mentioned before, there is a simple configuration change that we should make. But I wanted to show you the tool without doing that first, because it just works. Really easy and quick setup indeed.

The configuration I'm talking about is the Token. Before I said that Datree generates a new token every time you run the first validation on a new system. I've also said that the centralized policy management is of the key features of the service. But how can we centrally manage the policies and assign them to all our users and system if the token changes every time?

Well, the answer is the Account Token!

If you go again in the settings you will notice that you have a Token field. Just copy the value of the Token, and replace it in the Datree configuration file in your system. You can find the file with this path: ~/.datree/config.yaml

Once this is done, you can start managing your policies and rule effectively.

Also, thanks to the token, every time you run a validation with Datree you will see it in the History:

In here you not only have recorded all your scans, but also the results.

Policy Management

Demo for this section in the video starts at minute 8:35

Alright, let's finally talk about the Centralized Policy Management :)

With the token in place, we can use the dashboard to the fullest. We can of course enable and disable the rules, using the toggle next to the rule's name. As soon as you do it and re-scan your manifest files, you'll see the new rules being taken in consideration. The changes are automatically propagated to all the clients that use the same token.

You can also customize the output message of the rules.

This is very useful if you want to give additional information to your user regarding a specific exception or how to solve it.

Again, the changes are automatically propagated so you will see the new message as soon as you execute a new validation scan.

This is already pretty cool by itself because it assures you have uniformity across environments. But it is not all, we can do more.

We can in fact create multiple set of rules, or policies using the Datree naming.

The creation is done directly from the UI, just click on the "Create Policy +" button, give it a name, and start enabling the rules you want. You can also __clone an existing policy_ and customize it, as well as deleting existing policies.

Once you have a new policy created, you can use it for your validation instead of the default policy using the --policy flag:

datree test --policy MyNewPolicyName manifest.yaml

About deleting a policy, remember that if you try to use a policy that doesn't exist anymore Datree won't fall back to the default one, will give you an error message.

Policy as Code

Demo for this section in the video starts at minute 11:29

There is one more thing about policies and rule I want to show you. It's been very recently introduced in the product, and it will make all of you code-enthusiast very happy: Policy as Code.

As we have seen, by default Datree uses the UI to manage policies and rules. If we want to use Policy as Code, we have to enable it.

Remember that once the Policy as Code mode is enabled, the only way to change the policies in your account is by publishing a YAML configuration file (policies.yaml) with the defined policies.

We can either create a policy file from scratch or, as I'd recommend, download the default file and customize it.

The Policy file, as you can see in an extract below, is just a normal yaml file that contains the definition of the rules, and other metadata for the policy:

apiVersion: v1
policies:
  - name: Default
    isDefault: true
    rules:
      - identifier: CONTAINERS_MISSING_IMAGE_VALUE_VERSION
        messageOnFailure: Incorrect value for key `image` - specify an image version to avoid unpleasant "version surprises" in the future
      - identifier: CONTAINERS_MISSING_MEMORY_REQUEST_KEY
        messageOnFailure: Missing property object `requests.memory` - value should be within the accepted boundaries recommended by the organization
      - identifier: CONTAINERS_MISSING_MEMORY_LIMIT_KEY
        messageOnFailure: Missing property object `limits.memory` - value should be within the accepted boundaries recommended by the organization
    [...]

You can disable a rule by commenting the line with #

    [...]
      # - identifier: CONTAINERS_MISSING_IMAGE_VALUE_VERSION
      #   messageOnFailure: Incorrect value for key `image` - specify an image version to avoid unpleasant "version surprises" in the future
      - identifier: CONTAINERS_MISSING_MEMORY_REQUEST_KEY
        messageOnFailure: Missing property object `requests.memory` - value should be within the accepted boundaries recommended by the organization
    [...]

And once again you can change the output message by editing the messageOnFailure field.

You can also create one or more new policies, simply copy/paste the same structure, change the name, set the default, and you are done.

apiVersion: v1
policies:
  - name: Default
    isDefault: true
    rules:
      # - identifier: CONTAINERS_MISSING_IMAGE_VALUE_VERSION
      #   messageOnFailure: Incorrect value for key `image` - specify an image version to avoid unpleasant "version surprises" in the future
      - identifier: CONTAINERS_MISSING_MEMORY_REQUEST_KEY
        messageOnFailure: Missing property object `requests.memory` - value should be within the accepted boundaries recommended by the organization
    [...]
  - name: AnotherPolicy
    isDefault: false
    rules:
      - identifier: CONTAINERS_MISSING_IMAGE_VALUE_VERSION
        messageOnFailure: Incorrect value for key `image` - specify an image version to avoid unpleasant "version surprises" in the future
      # - identifier: CONTAINERS_MISSING_MEMORY_REQUEST_KEY
      #   messageOnFailure: Missing property object `requests.memory` - value should be within the accepted boundaries recommended by the organization
    [...]

Once you are satisfied with your policy file, it's time to make it available to the service by publishing it.

datree publish policyfile.yaml

Once a new policy configuration file is published, it will override the existing policies set up in your account.

That's it, now you can start using your new policies as we have seen before.

Using Policy as Code is super interesting, because then as we do with any normal source code and the different "as code" models like IaC, CaC, etc, we can version them, store them in our source control platform, and even use Pull Requests, Code Review, etc to make sure they are exactly as we want them to be and to keep them under control.

Datree for Helm

Demo for this section in the video starts at minute 18:04

So far we talked about validating Kubernetes manifests. Datree, however, supports also the validation of Helm charts!

Datree provides a Helm plugin, so the validation can be run directly from the Helm CLI.

helm plugin install https://github.com/datreeio/helm-datree

Once installed using the command above, you can just run the helm datree test command passing the folder containing your helm charts as a parameter.

After the scan is completed, you'll have the same results as you do running the datree CLI directly.

Datree Pricing

Cool right? I have one more thing for you: let's talk about pricing.

As I've said before, Datree is free to start with... and actually it's totally free to use for a number of scenarios. You get in fact 1000 free policy scans per month, every month, and it doesn't matter if you scan a single file or a hundred... one "datree test" execution counts as one policy scan.

If you need more than 1000 scans per month, there are paid options.

You can get 2000 policy scans a month and additional support with the Pro Plan, and customizable amount of policy scans and dedicated support with the Enterprise Plan.

Even better, you can get 1 month of the Premium plan for FREE is you use this link: https://app.datree.io/?utm_source=coder-dave&medium=youtube

Conclusions

So, what do you think about Datree? Is it something you will adopt as part of your workflow? Let me know in the comment section below, I'd really like to know it.

You may also want to watch this video in which show you how to deploy to Kubernetes in Azure Pipelines starting from scratch.

Like, share and follow me 🚀 for more content:

📽 YouTube
☕ Buy me a coffee
💖 Patreon
📧 Newsletter
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱‍💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast

AVOID Problems with Kubernetes: Best Practices Enforcement with Datree