DEV Community: Calvine Otieno

Improving your CI/CD Pipeline: Helm Charts Security Scanning with Trivy and GitHub Actions

Calvine Otieno — Fri, 02 Dec 2022 15:14:21 +0000

Originally published by me on Medium

DevOps has gained momentum over the past few years and it’s continuing to grow each day. Many organizations small, medium or big embrace DevOps processes. The automation of manual processes in the software development life cycle and faster release of features to customers are some of the key roles that DevOps culture brings to any organisation.

With growing automation and CI/CD tools in the market, security has become a major concern. The rise of Containers and IaC has led to major security issues and hence the rise of DevSecOps. DevSecOps is a concept where DevOps is augmented with security best practices early in the life of the Software Development Life Cycle (SLDC). Scanning the resultant artefacts be it docker images or Helm Charts for vulnerabilities is an essential part of that life cycle, especially for cloud-native environments.

In this article, I will demo how we can perform automated vulnerability scans for Helm Charts using GitHub Actions and Trivy.

Trivy and Github Actions Workflow

What is Trivy?

Trivy is an open-source project by Aqua Security. It’s a vulnerability/misconfiguration scanner for artefacts like container images, filesystems/rootfs, Helm Charts, and git repositories. It has a comprehensive detection for OS and language-specific packages, as well as Infrastructure as code files like Terraform. With Trivy, you can integrate this scanning with your CI/CD platform before you publish/deploy the artefacts to production.

Trivy supports table, json, and sarif outputs formats. Sarif scan output can be written to the GitHub repo Security tab(for private repositories, you need Github advanced license).

Prerequisites

You need to have some basic knowledge of working with Helm Charts and GitHub Actions.

Helm Charts installed in your local machine
Trivy installed in your local machine
A public GitHub Repository

And of course a code editor of your choice 😀.

Let’s start

Create a sample helm chart by running this command in your terminal:

helm create sample-helm-devsecops

This command will create a helm chart name sample-helm-devsecops.

For the sake of this quick demo, we will be concentrating much on deployment.yaml file.

Create a new folder name chart and move the sample-helm-devsecops folder and its content there.

Let us do a trivy scan of our just created chart by running this command:

trivy config charts/sample-helm-devsecops

You should see something like this:

**Here we have Tests: 79 (SUCCESSES: 67, FAILURES: 12, EXCEPTIONS: 0)

Failures: 12 (UNKNOWN: 0, LOW: 10, MEDIUM: 2, HIGH: 0, CRITICAL: 0)**

Nice. We are done with our first step.

Create A GitHub Repo and Github Action

Now that we have the chart set up, we can go ahead and push it to our GitHub repository.

Go ahead to your GitHub and create a repository, here I called mine sample-helm-devsecops. I will assume you know how to add a remote origin and push your code. This article will not cover Git and GitHub fundamentals.

After pushing your chart, let us create a workflow that will:

Run Trivy vulnerability scanner in IaC mode
Upload Trivy scan results to the GitHub Security tab

Create a folder named .github and inside it add another folder workflows. In the workflows folder, create a file trivy-secops.yaml with the following content:

name: trivy-security-scanning
on: push

permissions:
  security-events: write # To upload sarif files

jobs:
  chart-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8 # tag=v3.1.0
        with:
          fetch-depth: 0

      - name: Set up Helm
        uses: azure/setup-helm@f382f75448129b3be48f8121b9857be18d815a82 # tag=v3.4
        with:
          version: v3.6.3

      - name: Set up python
        uses: actions/setup-python@13ae5bb136fac2878aff31522b9efb785519f984 # tag=v4.3.0
        with:
          python-version: 3.7

      - name: Run Trivy vulnerability scanner in IaC mode
        uses: aquasecurity/trivy-action@9ab158e8597f3b310480b9a69402b419bc03dbd5 # tag=0.8.0
        with:
          scan-type: 'config'
          hide-progress: false
          format: 'sarif'
          scan-ref: 'charts/sample-helm-devsecops'
          output: 'trivy-results.sarif'
          exit-code: '1'
          ignore-unfixed: true

      - name: Upload Trivy scan results to GitHub Security tab
        uses: github/codeql-action/upload-sarif@312e093a1892bd801f026f1090904ee8e460b9b6 # v2.1.34
        with:
          sarif_file: 'trivy-results.sarif'

Here we are doing all the severity-level scans (LOW, MEDIUM, HIGH, and CRITICAL).

git add and push the changes to GitHub. Check the Actions tab and you should see a workflow running. It will fail because of the vulnerabilities we saw earlier.

Now go to the Security Tab and then click the Code scanning tab, you should see something like this:

You can see Trivy scanned our helm chart and uploaded the scan to Github Security Tab. From here we can create issues for these vulnerability scans and assign them to developers. Once the issue is fixed and the changes pushed, Trivy will run the scan again and the issue will be closed.

Demo: Create an issue for vulnerability number #1 — Process can elevate its own privileges

Click the issue and it should take you to a new window giving a description of the severity. There you can create a GitHub issue and it will automatically link the vulnerability with the issue. This helps you to track the vulnerability and automatically close them with a PR fixing the issue.

Create a GitHub Issue for the vulnerability

Once we merge the PR, the issue should be closed and vulnerability #1 should be solved.

You can see the issue has been resolved and in our recent scan it’s not there.

You can now repeat these steps to fix the remaining issues and once done, your scan results should be clean.

This is all for now. I hope you have learnt something and enjoyed reading the article. Next article we will focus on doing the same with Gitlab CI.

Here is the repo for this article. Follow me on GitHub for more about DevOps and DevSecOps.

Thanks for reading. Let’s connect on Twitter and LinkedIn 😁.

Multi-Container Pod Design Patterns in Kubernetes — Sidecar Pattern

Calvine Otieno — Tue, 22 Nov 2022 12:57:21 +0000

Kubernetes is an open-source major player container orchestration engine for automating deployments, scaling and management of containerized applications.

A pod is the basic building block of the kubernetes application. Pods encapsulate containers. A pod may have one or more containers, storage, IP Addresses and some other options that govern how containers should run inside the pod.

A pod that has one container is called a single-container pod. It’s the most common kubernetes use case. A pod that has multiple co-related containers is called a multi-container pod. You don’t always need multi-container pods. When do you need to use them is the question. Some of the cases where you may need to use them are:

When the containers have the exact lifecycle or when the containers must run on the same node. A scenario where you have a helper process that needs to be located and managed on the same node as the primary container.
For simpler communication between containers in the pod. These containers can communicate through shared volumes (writing to a shared file or directory) and through inter-process communication (semaphores or shared memory) When the containers have the exact same lifecycle, or when the containers must run on the same node. The most common scenario is that you have a helper process that needs to be located and managed on the same node as the primary container.
There are three common design patterns and use cases for combining multiple containers into a single pod:

Sidecar pattern (This article)
Adapter pattern
Ambassador pattern
Sidecar Pattern

This pattern consists of a main application i.e. a web application plus a helper container with a responsibility that is essential to the web application but it’s not necessarily part of the application itself. The common sidecar containers are logging utilities, sync services, watchers, and monitoring agents. It does not make sense if a logging container is running while the application itself isn’t running, so we create a multi-container pod that has the main application and the sidecar container (logging container in this case).

Example
Let's deploy a simple pod to understand this pattern. A pod that has primary and sidecar containers.

The main container is a simple Nginx application serving on port 80 that takes the index.html from the volume mount location. The Sidecar container uses a busybox image and writes the current date to a log file every five seconds. In practice, your sidecar is likely to be a log collection container that uploads to external storage.

For you to apply this example, you need to install Minikube as a prerequisite Apply the manifest

You can clone this repo:

GitHub

Apply the pod manifest.

kubectl apply -f sidecar-pod.yaml

Once the pod is running, connect to the sidecar pod:

kubectl exec -it  sidecar-container-example -c main-container -- /bin/sh

Install curl on the sidecar

apt-get update && apt-get install -y curl

Access the log file(index.html) via the sidecar

curl localhost

Originally published by me on Medium

In the next article we will be talking about Adapter pattern. Until next time, thank you.

That’s all for now. Thanks for reading. Let’s connect on Twitter and LinkedIn 😁.