CODEWITHSUNDEEP
gitlabgitlab-cikanikotrivy
Eladik
Eladik

Reputation: 94

How to Perform GitLab Container Scanning Before Pushing Images Using GitLab CI with Kaniko Without Using Artifacts?

I am currently working on setting up a GitLab CI/CD pipeline for building Docker images using Kaniko and scanning them for vulnerabilities using GitLab Container Scanning. However, I'm facing a challenge in performing the container scan before pushing the images to the registry, and I'm looking for alternatives to using artifacts.

Here's the issue:

Context: Our organization is focused on minimizing the size of our GitLab Enterprise instance, and saving the images as artifacts during the CI/CD process is discouraged due to space constraints.

Security Concerns: We are also concerned about security. We don't want to push Docker images to the registry if they have critical vulnerabilities. This poses a security risk, and we want to ensure that images are scanned for vulnerabilities before pushing.

GitLab recommends pushing the images first and then scanning them, but this goes against our security policies.

so basically i have 2 questions:

  1. Are there alternative approaches or best practices to integrate GitLab Container Scanning into our GitLab CI/CD pipeline with Kaniko so that we can perform the vulnerability scan before pushing the images to the registry without using artifacts?

  2. Additionally, is it possible to configure GitLab CI to run two jobs using the same storage, where one job builds the image and another scans it, without the need to save the image as an artifact in between?

Upvotes: 1

Views: 1196

Answers (1)

Davide Madrisan
Davide Madrisan

Reputation: 2310

I successfully tested this solution

stages:
  - prebuild
  - build

prebuild:
  stage: prebuild
  image:
    name: docker.io/curlimages/curl:8.3.0
    entrypoint: [""]
  script:
    - curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b $CI_PROJECT_DIR v0.45.1
    - curl -L --output - https://github.com/google/go-containerregistry/releases/download/v0.16.1/go-containerregistry_Linux_x86_64.tar.gz | tar -xz crane
  artifacts:
    paths:
      - crane
      - trivy

build image:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:v1.15.0-debug
    entrypoint: [""]
  variables:
    DOCKER_IMAGE: "${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHORT_SHA}"
    TRIVY_INSECURE: "true"
    TRIVY_NO_PROGRESS: "true"
    TRIVY_PASSWORD: "$CI_REGISTRY_PASSWORD"
    TRIVY_SERVER: "http://trivy-server.trivy-server.svc.cluster.local:4954"
    TRIVY_SEVERITY: "CRITICAL"
    TRIVY_TIMEOUT: "5m0s"
    TRIVY_USERNAME: "$CI_REGISTRY_USER"
  script:
    - kaniko_build
      --dockerfile $CI_PROJECT_DIR/Dockerfile
      --no-push
      --tar-path image.tar
    - ./trivy image
      --exit-code 1
      --input image.tar
      --scanners vuln
      --server $TRIVY_SERVER
    - ./crane auth login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - ./crane push image.tar $DOCKER_IMAGE

Note that the prebuild phase can be replaced by a container image that provides crane, kaniko and trivy and which you can use in the build image job.

ADDED after MrZorkiPongi's comment:

You can remove the prebuild job completely and add to build image:

  before_script:
    - wget https://github.com/google/go-containerregistry/releases/download/v0.16.1/go-containerregistry_Linux_x86_64.tar.gz
    - wget https://github.com/aquasecurity/trivy/releases/download/v0.46.1/trivy_0.46.1_Linux-64bit.tar.gz
    - tar -xz -f go-containerregistry_Linux_x86_64.tar.gz crane
    - tar -xz -f trivy_0.46.1_Linux-64bit.tar.gz trivy

Upvotes: 1

Related Questions