How to Start Left with Security Using Git Pre-Commit Hooks
Understand how you can shift security left by using pre-commit hooks in Git before committing to the code base.
There is a clear shift in development practices where engineers are taking on more and more responsibilities related to the underlying infrastructure. An example of this is the use of Kubernetes manifests to modify the structure of the application in a way that exposes ports or provides permissions that violate policy. Those considering how to start left with security can leverage the pre-commit hooks available in Git to validate these manifests prior to being committed to the code base.
Starting Left Just Feels Right
“Starting Left” is pretty simple in theory. In a typical CI/CD situation, security problems centered around permissions and surface area for attack are found after code has been compiled and deployed. If viewed as a physical pipeline that moves from left to right, these activities would show on the right side.
In contrast, to Start Left with security means that you would scan for these types of breaking changes long before being deployed. In the case of pre-commit hooks, code meant for inclusion in a repository will be flagged. Doing so not only keeps new security violations from being released, it prevents it from being committed to the code base at all.
Permissions Granted for More Surface Area
Manifests used in Kubernetes are a good example of objects checked into code that can have unwanted effects when deployed. A lot of information in these manifests control the underlying infrastructure and permissions of an application or service. In order to maintain a secure environment, organizations must constantly run tools designed to find issues “after the fact.”
Looking at the structure of the manifest, these extended permissions and other items have the ability to increase attack surface area. Starting Left using tools like git pre-commit hooks is the first line of defense against unwanted security risks. By requiring this small pre-check, many issues can be caught before being deployed to an environment. This method of using Git’s pre-commit hook function can be implemented in most any workflow.
What is a Git Pre-Commit Hook?
Simply put, a Git pre-commit hook allows for scanning of files for common issues. You may be used to using a tool called “lint” to check for code structure issues. This type of scanning as well as many others are included in the pre-commit hooks project. Syntax verification, file size restriction, and the ability to detect the use of private keys within code are all useful when using git pre-commit hooks to verify Kubernetes manifest files.
We are all used to committing our code and having a code review completed prior to merging into a release branch. At this point, much of CI/CD automation has already taken place. It is possible that the committed code has already made it to the development environment. While this may be harmless in most situations, it may be a case where additional access to resources or permissions that were not intended can surface.
In contrast, a pre-commit hook adds another step to the code commit process to do a few last-minute scans. These scans are meant to point out some of the more common issues as well as allow for custom rules to scan for newly introduced vulnerabilities. In the case of Kubernetes, these scans are completed against the manifest to keep things standardized and secure.
Git Pre-Commit Hooks Installation and Usage Example
In order to use this feature, the pre-commit framework needs to be installed. Using the instructions available at the pre-commit project homepage, we will install the package using the pip command line tool.
$ pip install pre-commit
Once installed, adding an initial configuration is simple. Go to your local project folder and run the following:
$ pre-commit sample-config > .pre-commit-config.yaml
This file contains the lines necessary to start using the pre-commit hooks listed here. There are a few entries by default. Note the correlation between the repo entry and the id of the hooks used. In this case, we are using hooks provided by pre-commit.
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v2.4.0
hooks:
- id: trailing-whitespace
- id: end-of-file-fixer
- id: check-yaml
- id: check-added-large-files
For our example, we are going to simulate a developer inserting a private certificate key. It is possible this would be used during development but is not something that should be committed to code. The git pre-commit hook for this scan is called detect-private-key. We will change the above .pre-commit-config.yaml file to include this by adding a new line.
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v2.4.0
hooks:
- id: trailing-whitespace
- id: end-of-file-fixer
- id: check-yaml
- id: check-added-large-files
- id: detect-private-key
After saving the file, running pre-commit install will set up the scripts for the hook in your project.
$ pre-commit install
pre-commit installed at .git/hooks/pre-commit
That’s it! Every time a commit occurs, the pre-commit scripts will run automatically. Since this is the first time we have included the detect-private-key hook, we will run the full scans on all the files in the solution. Otherwise, the pre-commit hooks will only run on changed files during a commit.
Example k8s_manifest.yaml (Note the RSA Private Key):
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: nginx
name: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
resources: {}
status: {}
When we run a scan against all files in the solution, this will cause a failure. The developer knows they must remove the offending code prior to being able to submit their work.
$ pre-commit run --all-files
Magalix Flawlessly Combines Automation with Policy-as-Code
Much of what we have discussed today involves using a variety of tools used to start left with security. To extend that further, implementing Policy-as-Code promises to catch issues long before seeing them execute in a live environment. Magalix has used DevOps know-how to master these tools and has taken steps to provide hundreds of built-in policies.
Have your own policies? Magalix integrates at any state of the CI/CD process to provide various checks you may already have employed. This, in addition to detailed analysis for compliance and policy adherence. Having all of this with the ability to provide detailed metrics and reporting will put teams far ahead of the game.
Whitepaper: Trusted Delivery with GitOps and Policy as Code
Download our latest whitepaper and learn how automated security and compliance checks, in the form of policy as code, make automated continuous deployments safe and secure.
