Blog Icon

Blog Post

Integrating Gitlab CI/CD with Sysdig Secure.

In this blog post we are going to cover how to perform Docker image scanning on the Gitlab CI/CD platform using Sysdig Secure. Container images that don’t meet the security policies that you define within Sysdig Secure will be stopped, breaking the build pipeline before being pushed to your production Docker registry.

Gitlab CI/CD and Sysdig Secure

What is Gitlab CI/CD?

Gitlab CI/CD is an open source continuous integration and delivery server integrated with the Gitlab software development and collaboration platform.

Once you have configured Gitlab CI/CD for your repo, every time a developer pushes a commit to the tracked repository branches, the pipeline scripts will be automatically triggered.

You can use these pipelines to automate many processes. Common tasks include QA testing, building software distribution artifacts (like Docker images or linux packages) or, as is the case for this article, checking compliance with security policies.

Container security in your Gitlab CI/CD pipeline: shift left your security and fail fast

Like most things in IT, the earlier you detect container security issues, the easier they are to fix without any further consequences.

Embedding container security in your build pipeline is a best practice for several reasons:

  • The vulnerabilities will never reach your production clusters, or even worse, a client environment.
  • You can adopt a secure-by-default approach when you know any image available in your Docker container registry has already passed all the security policies you have defined for your organization, as opposed to manually check compliance after-the-fact.
  • The original author will be (almost) instantly notified, when the developer still has all the domain context. The issue will be substantially easier to fix this way than if found by any other person months later…

Sysdig Secure offers a full featured container image scanning service, among many other container security features like run-time threat detection, forensics, compliance and auditing. Let’s see how we can make Sysdig Secure image scanning service work together with Gitlab.

Pre-requisites

So, you have a Gitlab repository with all the files required to build a Docker container. You would like to have a pipeline that automatically builds a fresh container image each time there is a new commit, and you also want that image to be automatically scanned following the security policies that are enforced in your organization.

To reproduce the steps in this post you will need:

Gitlab CI/CD pipeline image scanning with Sysdig Secure

Following a practical example we are going to demonstrate how to integrate these two platforms with a very straightforward process. This will get you up and running with Sysdig Secure Image scanning in minutes.

Configuring access credentials

The Gitlab CI/CD pipeline will require access credentials to communicate with the Sysdig Secure backend, to achieve this copy the API access token from the Sysdig UI Setting -> User profile

Then, configure a new global variable for your Gitlab project:

  • In your GitLib Project, view your project’s Settings > CI/CD and expand Variables.
  • Create a new variable named ANCHORE_CLI_USER, and paste your Sysdig Secure API key in the Input variable value field.
  • Toggle the Masked button to avoid printing your API token in the pipeline logs.

Gitlab CI/CD masked variable

Similarly, you need to add the Gitlab registry credentials to Sysdig Secure, so it can fetch and scan the images. From the Sysdig Secure UI access Scanning -> Registry credentials -> Add registry and enter your Gitlab account credentials:

Sysdig Secure registry credentials

Base files and pipeline definition

First, you will need a Dockerfile defining the image that you intend to build. You can upload any Dockerfile you want to your project, or just write a simple example:

FROM python:stretch
CMD python -c "print('Hello, I\'m a Docker container!')"

Then, you need to create a new .gitlab-ci.yml file in your project root. This file serves as the master build file which contains all the necessary build steps (stages) our environment. This file allows you to create as many stages you need for your builds.

You can download the Gitlab CI/CD file that we used for this post here.

We have three stages in this pipeline:

  • Building the container image
  • Scanning the image for vulnerabilities or policy violations
  • Pushing the image to the final repository


The first section of the file should be listed below. What we are doing is setting our variable for the image to be scanned based upon the project name and also setting up our build stages:

Next we will look at each individual stage.

Build stage


The build stage contains the necessary commands and functions to build and push our docker image from our project:

Scanning stage

The next stage is the container scan stage. At this stage we will be scanning the image for vulnerabilities and generating reports (artifacts) of the scan. These vulnerability reports will be available as artifacts after the build is run, whether it succeeds or fails.

Pay special attention to the variable:

ANCHORE_FAIL_ON_POLICY: "true"

If set to true, Sysdig Secure will return an error code for this stage if the image contains any of the stop conditions configured in your policy (for example, a critical vulnerability). Thus, stopping the pipeline and preventing the following tasks from running.

It is set to true by default, to avoid pushing vulnerable images to the final repository.

Here is the result of a successful container_scan stage:


Here is the same image scan but with a failed policy result:


Remember upon a container_scan failure or success, the artifacts (reports) will be viewable at the container_scan stage. Please note that some reports maybe empty, due to the image not containing any data (i.e. no java packages, etc.):


Gitlab CI/CD artifacts

Reports:

image-details.json - Details about Image scanned
image-gem.json - Details about ruby gems in scanned image
image-java.json - Details about java packages in scanned image
image-npm.json - Details about npm packages in scanned image
image-packages.json - List of packages contained in image
image-policy.json - Sysdig Secure Policy image used for image evaluation 
image-python.json - List of python packages contained in image
image-vulnerabilties.json - List of vulnerabilities contained in image

Publishing stage

After a successful vulnerability scan, this stage of the build pipeline will upload the image to your registry:

Here is an example of a successful push:

Conclusions

Thanks to the native Docker compatibility in Gitlab and the Sysdig Secure container image scanning API, making them both work together is a breeze.

Find any software vulnerabilities, check for container security best practices, Dockerfile contents, whitelist or blacklist specific packages or 3rd party libraries installed manually like Java JAR/WAR files, or package managers like npm, pip or gem, even for software licenses with Sysdig Secure.

Fail fast, inform the container author right away to address it quickly and create a secure-by-default container security policy.

Share This

Stay up to date

Sign up to recieve our newest.

Related Posts

Integrating Sysdig Secure with Atlassian Bamboo CI/CD.

33(+) Kubernetes security tools.

Docker scanning for Jenkins CI/CD security with the Sysdig Secure plugin.