Validating Images with Gitlab CI / CD

Hello everyone, on the eve of the start of the course “CI / CD on AWS, Azure and Gitlab” we prepared a translation of interesting material.




In this article, we will talk about how to check container images on the Gitlab CI / CD platform using Sysdig Secure .

Container images that do not comply with the security policies defined in Sysdig Secure will not be published to the container registry and will stop the pipeline.



Vulnerability Finder with Gitlab CI / CD


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

After you configure Gitlab CI / CD for your repository, each time developers commit to the repository's tracked branches, pipeline scripts will run automatically.

Such pipelines can be used to automate many processes. For example, for QA testing, creation of software distribution artifacts (such as Docker images or Linux packages) or, for what we will talk about in this article - to verify the configuration, search for vulnerabilities and verify compliance.

Checking Images on the Gitlab CI / CD Pipeline: shift left security


As elsewhere in IT, the sooner you find a vulnerability in a container, the faster and easier you can fix it without consequences.

Embedding vulnerability checks in your pipeline assembly is a good practice for several reasons:

  • Existing vulnerabilities will never go to production;
  • «secure-by-default», , , .
  • , . , - .

Sysdig Secure offers a full-featured set of tools to check the containers of images along with many other container security inspection functions such as detection time threats performance profiling based on machine learning and extensible threat detection templates out of the box, forced Kubernetes PSPs , responding to incidents and expertise on compliance . Let's take a look at how the Sysdig Secure Image Validation service works with Gitlab.

Security Check Requirements on Gitlab


To complete the following steps, you will need:


Configuring Gitlab CI / CD Pipeline for Image Inspection with Sysdig Secure


We will see in practice how these two platforms can be integrated. With this guide, you will learn how to work with Sysdig Secure Image scanning in minutes.

Configure Access Credentials


The Gitlab CI / CD pipeline will need access credentials in order to communicate with the Sysdig Secure backend. In order to do everything right, copy the access token from Sysdig UI Settings> User profile .

Then set up a new global variable for your Gitlab project:

  1. In your project, go to Settings> CI / CD and select Variables .
  2. Create a new variable SYSDIG_SECURE_TOKENand add the Sysdig Secure API key in the value field .
  3. Click on the Masked button so that your API token is not printed in the pipeline logs.

Gitlab pipeline definition


First, we need a Docker file that defines the image that you will collect. You can upload any Docker file you want to your project, or simply use the following example:

FROM debian:stretch
RUN apt update && apt install python-pip python-numpy openssh-server -y && rm -rf /var/lib/apt
RUN pip install flask
COPY app.py /app.py
EXPOSE 5000 22
ENTRYPOINT ["python", "./app.py"]

Then you need to create a new file .gitlab-ci.ymlin the root of the project. This file will describe all the necessary steps (stages) of the assembly of our environment. He will determine all the necessary stages.

There are 3 stages in our pipeline:

  • Assembly of the container image;
  • Scanning an image for vulnerabilities or policy violations;
  • Moving the image to the destination repository.

variables:
  CI_REGISTRY_IMAGE: "sysdiglabs/dummy-vuln-app"
  SCAN_IMAGE_NAME: "sysdiglabs/secure_inline_scan:latest"
  SYSDIG_SECURE_ENDPOINT: "https://secure.sysdig.com"

docker-build-master:
  image: docker:latest
  stage: build
  services:
    - docker:dind
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    - docker build --pull -t "$CI_REGISTRY_IMAGE" .
    - docker run --rm -v /var/run/docker.sock:/var/run/docker.sock "$SCAN_IMAGE_NAME" /bin/inline_scan analyze -s "$SYSDIG_SECURE_ENDPOINT" -k "$SYSDIG_SECURE_TOKEN" "$CI_REGISTRY_IMAGE"
    - docker push "$CI_REGISTRY_IMAGE"
  only:
    - master

Build a container image


The assembly of the image occurs with docker build --pull -t "$CI_REGISTRY_NAME". It takes instructions from your Docker file and generates a new local image, which will be checked in the next step.

Scanning for Vulnerabilities


The next stage is checking the containers. Here we will check the image for vulnerabilities and check the configuration, storing the results on the Sysdig backend.

One of the advantages of Sysdig local scanning is that you do not lose control over your images, since the image does not need to be moved to another registry or exposed from the outside in order to perform the scan. It takes place inside the runner, and only results are sent to Sysdig Secure.

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock "$SCAN_IMAGE_NAME" /bin/inline_scan analyze -s "$SYSDIG_SECURE_ENDPOINT" -k "$SYSDIG_SECURE_TOKEN" "$CI_REGISTRY_IMAGE"

At this point, Sysdig Secure will return an error code if the image meets any of the stop conditions specified in your policy (for example, critical vulnerability). Stopping the pipeline will prevent the transfer of vulnerable images to the container registry.





In Sysdig Secure, we can look at additional information and understand why the security check failed to complete:



As you can see in the screenshot, the container leaves port 22 open, which is in the list of forbidden ports, and also contains some serious vulnerabilities in the Python library.

Move image to destination repository


After successfully checking for vulnerabilities, the pipeline will docker push and the image will be published to the container registry. If you do not specify any credentials or remote storage, Gitlab uses the default .

Conclusion


Using Sysdig Secure image scanning, you can check images on the Gitlab CI / CD pipeline without sending them from the infrastructure to the public or intermediate registry, check the configuration and prevent leakage of vulnerabilities to production.

Find known vulnerabilities and check the configuration for compliance with security recommendations, including Dockerfile instructions, white and black lists of packages or third-party libraries installed in the base image, such as JAR / WAR files in Java or language package managers such as npm for Javascript, pip for Python and gem for Ruby.

In the event of a failure, you can quickly report this to the container author to quickly solve the problem and create a secure-by-default container security policy. To try Sysdig Secure, you can requestdemo today!

That's all. Learn more about the course here .

All Articles