CodeX
Published in

CodeX

Pre-Commit Hooks DevOps Engineer Should Know To Control Kubernetes

Photo by Liam Tucker on Unsplash

Generally speaking, what all companies are looking for is to increase their productivity at all levels: human, infrastructure, processes, etc. Often, this productivity is driven by the addition of automated processes to facilitate and increase the pace of production. This automation requires an evolution, an adaptation or even a complete transformation of the concepts historically used. This includes the implementation and control of security policies.

Indeed, since the emergence of new working methods based on agility and flexibility (such as DevOps), some security concepts have had to adapt to the pace of development and management of the components of the infrastructure. Today, one of the best safety practices is to move these control points as early as possible in the integration chain in order to detect as soon as possible any anomaly that deserves special attention.

Why Should You Shift Left Security?

The term “shift left” was introduced by the DevSecOps approach by increasing collaboration between development, security and operations teams. The idea is to guarantee the security of applications from the beginning of the development cycle by moving the security and test processes to the left on the traditional linear representation of the SDLC.

This method has been recognized as a best development practice for years and has since the emergence of the DevOps methodology, a strong adoption for its simplicity of use and configuration, and its incredible benefits in terms of team collaboration on complex projects such as infrastructure management with Terraform, Ansible, or Kubernetes.

Shift Left Security: Best Practices for Getting Started

Forcing the use of standards both at the level of YAML definition file development and at the level of their content and configuration facilitates their reading, adoption and maintenance. Three principles that any project should seek to implement today.

The purpose of shifting security left is to design software with integrated security best practices, and to detect and resolve potential security issues and vulnerabilities as early in the development process as possible. This makes it easier, faster, and more affordable to address security issues.

How To Shift Left?

Pre-commit is a command-line tool that is part of this range of tools used to shift-left certain security aspects by adding automatic control points after each commit.

This makes it possible to detect and control as early as possible in the integration pipeline any anomalies and therefore correct it before they are put into production.

To do this, three steps are required:

  • Pre-commit requires to be installed on your machine
  • A configuration file named “.pre-commit-config.yaml” must be created at the root of the Git project and configured with the hooks
  • The Git project needs to be configured locally to automatically execute the command on every commits

Important Considerations

As you may have understood in the previous section, the pre-commit command and the Git project must be configured locally to run automatically. This is not a configuration that can be forced from the remote source controller. This requires a project configuration step during the onboarding phase to ensure its application. Documentation is therefore required to disseminate the information and ensure its adoption.

Depending on the context, it is nevertheless possible to automate its use by developing an environment configuration script (in this case, the laptop of all team members) or even to create, share and encourage the team to use a common container image with all the necessary development tools. This practice has many advantages in particular in the onboarding of new people by minimizing the actions necessary to configure the development environment.

However, if this is not applicable or seems too complex, it is always possible to move these controls further down the integration chain and thus automate their use before deployment.

What Hooks Can You Use To Control Kubernetes Resources?

This section lists a set of hooks available for free and easily installable and usable via pre-commit. This is an opinionated list that can obviously be supplemented by other hooks depending on the context. For ease of reading, we have voluntarily reduced the list to a Kubernetes ecosystem.

Here is a list of a pre-commit extensions useful for checking the development and maintenance of Kubernetes resources as soon as possible in the integration pipeline:

  • Check-merge-conflict to check merge conflict before committing anything
  • Trailing-whitespace, to clean the code from useless white space
  • Check-added-large-files to control the size of the file stored in your repositories
  • End-of-file-fixer to ensure files end in a newline and only a newline
  • Yamllint to identify formatting errors of your code automatically before each commit, very important to standardize the code and facilitate its reading
  • Yamlfix to automate formatting correction
  • Checkov to check the compliance of Kubernetes definition files according to best development practices and custom rules
  • K8svalidate to check the compliance of Kubernetes definition files according to the version of Kubernetes used
  • Detect-secrets to detect any sensitive data and avoid their storage in the code

Most of these hooks are also applicable to other contexts. Depending on the nature of the project, several other hooks can be added to control the format of the files and their contents. However, keep a brief checklist to minimize the impact of these on your productivity.

Here is a pre-commit configuration file to quickly test these hooks on your Kubernetes projects:

---
repos:
- repo: https://github.com/adrienverge/yamllint.git
rev: v1.17.0
hooks:
- id: yamllint
args: [-c=.yamllint]
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.1.0
hooks:
- id: check-merge-conflict
- id: trailing-whitespace
- id: check-added-large-files
- id: end-of-file-fixer
args: [--no-ensure-ascii, --autofix]
- repo: https://github.com/bridgecrewio/checkov.git
rev: 2.0.975
hooks:
- id: checkov
args: [-d .]
- repo: https://github.com/Agilicus/pre-commit-hook-k8svalidate.git
rev: v0.0.8
hooks:
- id: k8svalidate
files: .yaml$
- repo: https://github.com/Yelp/detect-secrets
rev: v1.2.0
hooks:
- id: detect-secrets

Copy the content of this file and paste it in a file named “.pre-commit-config.yaml” in the root folder of your project. Then run the pre-commit command to get the result!

Example of successful pre-commit hooks

Next?

In this article, we have listed a set of pre-commit hooks useful on a daily basis for anyone administering one or more Kubernetes clusters. Of course, there are many others adapted to different contexts. A DevOps engineer for example will be interested in extensions to control Prometheus configuration and even formatting rules, or Vagrant file control, etc.

There is no limit to what can be controlled, but it is still necessary to measure the impact that the accumulation of these hooks can have on a person’s productivity vis-à-vis the benefits of them.

For more information on pre-commit, please refer to the following links:

About The Authors

Hicham Bouissoumer — Site Reliability Engineer (SRE) — DevOps

Nicolas Giron — Site Reliability Engineer (SRE) — DevOps

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store