Prevent Kubernetes Misconfigurations from Reaching Production with Datree

The problem

What are some of the challenges that Kubernetes admins might face? Let's say you have a few developers that made changes to K8s configurations files, to deploy their objects, and they are working with CI/CD and they push their configuration file on git repo. Let's say it caused a failure in production. Wouldn't it be cool to figure out these misconfigurations before the production? Comes into picture Datree.

About Datree

Datree is a CLI tool that supports Kubernetes owners in their roles and it helps by preventing developers from making errors in their Kubernetes configuration files before it reaches production and causing failure. It does so by providing a policy enforcement solution to run automatic checks for rule violations.
It can be used on the command line to run policies against Kubernetes manifests YAML files or Helm charts. You can include Datree's policy check as part of your CI/CD pipeline or run it locally before every commit.

How to sign up

You'll have to sign up in order to access the dashboard consisting your policy checks. Head over to the sign up page and you can choose to either continue to GitHub or Google.

Follow these steps:
1) Download and install Datree - $ curl https://get.datree.io | /bin/bash
2) Scan a k8s file or helm chart dir (with the plugin) - $ datree test [k8s-file] / helm datree test [chart-dir]
3) Click on the link in the CLI to access your dashboard - each user will have its own link with a unique token.
Here is a good example of this flow - check the "Datree analysis" section.

The token is what connects the policy checks to your Centralized policy to know which policies and rules to run. You can find your token by going to your profile settings in the dashboard.

You can also find it via Datree's config via, such as:
$ nano ~/.datree/config.yaml

More information about account tokens can be found here.

How to run

By default, datree offer's a demo Kubernetes configuration file for you to test out the tool. You can find it as:

  ~ cat ~/.datree/k8s-demo.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: rss-site  namespace: test  labels:    owner: --    environment: prod    app: webspec:  replicas: 2  selector:    matchLabels:      app: web  template:    metadata:      namespace: test      labels:        app: web    spec:      containers:        - name: front-end          image: nginx:latest          readinessProbe:            tcpSocket:              port: 8080            initialDelaySeconds: 5            periodSeconds: 10          resources:            requests:              memory: "64Mi"              cpu: "64m"            limits:              cpu: "500m"          ports:            - containerPort: 80        - name: rss-reader          image: datree/nginx@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2          livenessProbe:            httpGet:              path: /healthz              port: 8080              httpHeaders:              - name: Custom-Header                value: Awesome          readinessProbe:            tcpSocket:              port: 8080            initialDelaySeconds: 5            periodSeconds: 10          resources:            requests:              cpu: "64m"              memory: "128Mi"            limits:              memory: "128Mi"              cpu: "500m"          ports:            - containerPort: 88

You can run the following command in order to test Datree against the pre-compiled demo file:

$ datree test ~/.datree/k8s-demo.yaml

As you can see, it consists of 4 rules failing in the policy checks. You can also find the history of this in your Datree dashboard.

Out of the box, Datree offers 30 such rules for you to test out. These rules are spread across categories such as:

• Containers
• Workload
• CronJob
• Networking
• Deprecation
• and more

You can find these rules in the default policy on your dashboard.

Here, you can either change the error message of various rules, turn some of those on/off, and the changes will be visible in your command line instantly!

Since it's not connected to a cluster, you can also run it offline without needing to setup something like Minikube, Kubeadm, etc.

Schema validation

Datree also performs schema validation checks for your files before running the policy checks. For example, if I make an error in the structure of my YAML file and run a Datree check on it, it's going to give me the following error:

Here, you can see the order in which these checks are performed. YAML validation -> Kubernetes schema validation -> policy checks

Key features

Datree also allows you to create your own policies. This can useful for different stages of deployment. You can add policies with different rules configured, giving each policy its own use cases. In order to do so, you can head over to your Datree dashboard and click on + Create Policy. Here you can give it a name, and once the policy is created, you can apply rules to it.

Now, in order to select this policy instead of the default one when running checks, you can use the -p flag:

$ datree test ~/.datree/k8s-demo.yaml -p My_Policy

As you can see, this only failed on one of the rules that I added, as compared to 4 rules failing in the default one. You can also notice the custom error message that I have added.

Policy as code

But what if you want to collaborate with other people and share your policies with someone else? This includes following development best practices such as version controlling, automation, collaboration and more. For this, Datree offers something called policy as code. This is a declarative method to represent your policies. When this mode is enabled, the only way to change the policies in your account is by publishing a YAML configuration file. This file is going to contain all your defined policies.

In order to use this feature, you can turn it on from your profile settings and download the policies.yaml file.

The file is going to look something like this, with the inactive rules commented out:

apiVersion: v1customRules: nullpolicies:  - name: My_Policy    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_CPU_REQUEST_KEY        messageOnFailure: Missing property object `requests.cpu` - 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      # - identifier: CONTAINERS_MISSING_CPU_LIMIT_KEY      #   messageOnFailure: Missing property object `limits.cpu` - value should be within the accepted boundaries recommended by the organization      # - identifier: INGRESS_INCORRECT_HOST_VALUE_PERMISSIVE      #   messageOnFailure: Incorrect value for key `host` - specify host instead of using a wildcard character ("*")      # - identifier: SERVICE_INCORRECT_TYPE_VALUE_NODEPORT      #   messageOnFailure: Incorrect value for key `type` - `NodePort` will open a port on all nodes where it can be reached by the network external to the cluster      # - identifier: CRONJOB_INVALID_SCHEDULE_VALUE      #   messageOnFailure: 'Incorrect value for key `schedule` - the (cron) schedule expressions is not valid and, therefore, will not work as expected'      # - identifier: WORKLOAD_INVALID_LABELS_VALUE      #   messageOnFailure: Incorrect value for key(s) under `labels` - the vales syntax is not valid so the Kubernetes engine will not accept it      # - identifier: WORKLOAD_INCORRECT_RESTARTPOLICY_VALUE_ALWAYS      #   messageOnFailure: Incorrect value for key `restartPolicy` - any other value than `Always` is not supported by this resource      # - identifier: HPA_MISSING_MINREPLICAS_KEY      #   messageOnFailure: Missing property object `minReplicas` - the value should be within the accepted boundaries recommended by the organization      # - identifier: HPA_MISSING_MAXREPLICAS_KEY      #   messageOnFailure: Missing property object `maxReplicas` - the value should be within the accepted boundaries recommended by the organization

Working with CI

You can use Datree's policy check in your CI process. This way, every time the CI is triggered, it will also run datree test to verify the Kubernetes configuration files are always configured according to your needs. In order to use Datree, you'll be required your account's token as mentioned above.

Datree supports integrations with:

• Helm plugin
• Git hooks
• CircleCi
• Travis CI
• GitHub Actions
• GitLab CI/CD

You can find examples for these in the public repository.

Resources

• Tutorial
• Docs
• Website
• GitHub

Connect with me

• Twitter
• LinkedIn
• YouTube