If you're a developer building applications for Kubernetes, you've probably faced the dreaded "Well, it works in my cluster!" scenario where your components run perfectly in your local Kubernetes development environment; but, once pushed to the main code repository to be deployed, all sorts of problems arise, because the way you’ve configured your Kubernetes resources for local deployment wasn’t in line with whatever policies were being enforced.

Wouldn’t it have been nice to find (and fix) these issues to ensure a smooth deployment process before committing your code - potentially saving both you and your DevOps teams a heap of troubleshooting and root cause analysis?

Say hello to pre-commit Kubernetes configuration validation!

So, what is pre-commit validation?

Think of pre-commit validation for Kubernetes YAML configurations as your dedicated Kubernetes bodyguard. It's by your side every step of the way, ensuring your YAML files are in tip-top shape and ready to be introduced into your cluster. By incorporating this guardian into your development process, you shield your Kubernetes deployments from potential misconfigurations and issues. 

Validation of YAML resources comes in several flavors:

1. YAML Syntax Verification: Validation isn't just a bodyguard, it's also a friend who spots the spinach in your teeth before a big date. It checks your YAML files for correct indentation, appropriate key-value pairs, and other syntax nuances. No one wants a misconfigured Kubernetes deployment due to a misplaced tab or space!

2. Kubernetes Schema Validation: This step ensures your YAML is aligned with Kubernetes' expectations, like ensuring 'replicas' are defined for deployment or verifying the correct API version. Remember that the Kubernetes version you need to be validating against is that of your target environment, not of what your local Minikube might be running.

3. Policies for Best Practices: Beyond syntax and schema, Kubernetes validation tools (like Monokle) are your trusted advisors. They review your YAML configurations for best practices, suggesting enhancements and warning against suboptimal configurations. It's like having a seasoned Kubernetes mentor giving you pointers. Let’s not forget that security is paramount. With pre-commit validation, your bodyguard is inspecting every inch of your YAML's perimeter. This process checks for exposed secrets, overly permissive permissions, or other security missteps, ensuring your configurations don't unintentionally open the gates to malicious actors.

Once again, be aware that these policies can vary for different target environments - which is often solved with tools like Kustomize that “overlay” configuration traits specific for a target environment at build or deploy time.

Incorporating pre-commit validation for your Kubernetes YAML configurations ensures your deployments are not just functional, but also optimal, secure, and efficient.

Truly, the bodyguard you never knew your YAMLs needed! 

Next to consider, is how to actually perform these validation steps in your local development workflow.

There are a couple of options:

• Let an IDE Plugin/Extension do the work for you
• Use a CLI tool
• Automate pre-commit validation as part of your git-hooks
• (any combination of the above)

IDE Plugins: The Ultimate Co-Pilot for Kubernetes YAML Pre-Commit Validation

Integrated Development Environments (IDEs) have gone beyond just being code editors. They're now dynamic workspaces that augment a developer's capabilities. One of the marvels within modern IDEs is the plethora of plugins available, tailor-made to assist and automate various coding tasks. When it comes to pre-commit validation for Kubernetes YAML files, these plugins are the flight tower to your pilot, ensuring you're on the right path before taking off.

Take the Kubernetes VS Code extension, for example. It's not just an extension; it's having an expert right by your side. As you type, this extension continuously reviews your YAML configurations. It underlines errors, offers auto-completions, and provides instant feedback, ensuring you adhere to Kubernetes standards. It's akin to having real-time GPS navigation for your Kubernetes journey, guiding you away from potential pitfalls and ensuring a smoother ride. 

Notably though, this extension only solves for points 1 & 2 in our list above - for Policy enforcement, you’ll need a different plugin, like the Monokle VS-Code extension that automatically checks your YAML configurations against a configurable policy in regard to security, resource usage, conventions, etc. 

By integrating such plugins, you’ll be able to significantly reduce the margin for error, catch inconsistencies early, and streamline their workflow, all before the YAML even thinks about making its way to a repository or a cluster.  

Using a CLI for pre-commit validation

Using an IDE isn’t always an option - you might be in a headless environment, or just jumping in a temporary environment without having time to set up your preferred visual tool chain - in which case CLI tools for pre-commit validation can help you check your YAML configurations before committing them to source control. Once again tools like the Monokle CLI can help you - the Monokle CLI uses the same core validation engine as other tools in the Monokle ecosystem, ensuring consistent validation across the entire Policy Enforcement Pipeline. Other popular tools for CLI-based pre-commit validation include Kubeconform and kube-linter.

Quick Example with the Monokle CLI

1. Install the CLI as described at https://github.com/kubeshop/monokle-cli#installation
2. Navigate to a project/folder containing your Kubernetes resources
3. Run the “monokle validate .” command:

‍

This sounds great! So, How do I automate Pre-commitment Validation? 

I’m so happy you asked, hypothetical reader! 

To ensure nothing slips between the cracks while working locally, you can automate pre-commitment validation with tools like pre-commit hooks in git. Once configured, these hooks automatically run the checks before each commit, ensuring that your YAML configurations are safe and sound before they go into source-control.

In this guide, let’s assume you’re using a tool like Monokle CLI for policy validation, and git for managing your configuration repository:

1. First, make sure you have the monokle-cli installed - see https://github.com/kubeshop/monokle-cli#installation
   
   
2. Next, add a ‘.pre-commit’ file to the .git/hooks folder, with the following content:
   ```bash
   !/bin/sh
   monokle validate
   ```
   

(this is the same command we ran in the example above - replace this with the CLI command(s) for any other tool(s) you might want to use)

Now whenever you run a git commit command, git will run the above script to validate your resources prior to actually committing. If the validation fails you will get a corresponding error and the commit will be aborted:

‍

Ensuring everyone is using the same policy

If you’re working in a team you’ll probably want to make sure that everyone is using the same configuration policies - no matter what tool you’re actually using. The actual approach depends on the tool at hand:

• CLI arguments: some tools use CLI arguments to configure how they validate - these need to be encoded in the pre-commit hook and preferably pulled from an ENV variable to allow more flexibility in sharing and changing the configuration
• Configuration file: many tools use a configuration file that is part of the repository itself (like many linting tools do for source code). This makes it easy to ensure that the same validation is being run by all team members and also in corresponding CI/CD pipelines. One challenge can be if you have multiple projects/repos that you would like to ensure are using the same policy, perhaps as a baseline with project-specific rules/overrides. Another challenge is if you are using different validation tools across the policy enforcement pipeline (see Kubernetes YAML Policies 101), in which case ensuring that all are using the same rules can be a challenge.
• Centralized Policy Management: tools like Monokle Cloud allow you to define policies using a centralized Policy Mgmt Console and then connect to that from your IDE, CLI, CI/CD, etc to ensure the same policies are used consistently across all projects/workflows.

Avoiding “Policy Splurge” may not be top of mind when you’re getting started with policies - but as you adopt a more structured approach this will definitely be one of the hurdles to tackle, so giving it some consideration when evaluating policy tooling is definitely recommended. 

Recap

By engaging in pre-commitment validation, policy violations are caught early, before code is committed to the repository, “shifting-left” validation activities in the life-cycle of your application. It’s a powerful method of preventing misconfigurations or any other issues that may sneak into your production environment, shortening your time-to-successful deployment and saving you the need for troubleshooting later on in the application lifecycle.

There are many great tools out there to help, both for the individual developer and the enterprise that is seeking a consistent approach to policy enforcement across their Kubernetes projects - whatever you use it better than nothing at all - for the sake of your application's well-being and happiness of your end-users.

‍