mondoo.io with HashiCorp Packer in Gitlab CICD


Bicycle

What is mondoo

mondoo is brought to you by the team who gave you InSpec and the DevSec Project with a passion to make IT operations human readable and executable. With Mondoo, you can collect vulnerability information about your whole fleet. Instead of limiting your options, mondoo provides options to gather information. mondoo enables you to gather information from a local Linux OS, servers running on bare-metal, Docker containers, Kubernetes cluster or Cloud environments. Mondoo feels home in Build and Runtime. You can easily integrate Mondoo in your existing CI/CD workflow, run it as part of Packer or Terraform or verify all deployed instances and containers to ensure security as early as possible.

Disclaimer

This article is still referencing to the old implementation of mondoo packer which is not using packer init. A follow up article is in the line.

How to integrate Mondoo into Packer

We gonna just rebuild the official Ubuntu Focal 20.04 LTS Image and run the mondoo provisioner within this packer build. For the initial setup follow the mondoo Quickstart and the mondoo packer plugin setup.

When you got an agent registered you are ready for adding the mondoo provisioner to your packer builds.

data "amazon-ami" "ubuntu_focal" {
  filters = {
    name                = "ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"
    root-device-type    = "ebs"
    virtualization-type = "hvm"
  }
  most_recent = true
  owners      = ["099720109477"]
  region      = "us-east-1"
}

locals {
  timestamp = regex_replace(timestamp(), "[- TZ:]", "")
  ami_name = "mondoo-example ${local.timestamp}"
}

source "amazon-ebs" "ubuntu_focal" {
  ami_name      = "${local.ami_name}"
  instance_type = "t2.micro"
  region        = "us-east-1"
  source_ami    = "${data.amazon-ami.ubuntu_focal.id}"
  ssh_username  = "ubuntu"
}

build {
  sources = ["source.amazon-ebs.ubuntu_focal"]

  provisioner "shell" {
    inline = ["ls -al /home/ubuntu"]
  }

  provisioner "mondoo" {
    on_failure = "continue"
  }
}

The output of the packer build then contains the output of the mondoo plugin.

packer build aws_ubuntu.pkr.hcl
amazon-ebs.ubuntu_focal: output will be in this color.

==> amazon-ebs.ubuntu_focal: Prevalidating any provided VPC information
==> amazon-ebs.ubuntu_focal: Prevalidating AMI Name: mondoo-example 20210303131641
    amazon-ebs.ubuntu_focal: Found Image ID: ami-042e8287309f5df03
...
==> amazon-ebs.ubuntu_focal: Running mondoo (Version: 1.1.0, Build: 96bf459)
==> amazon-ebs.ubuntu_focal: activated continue on detected issues
==> amazon-ebs.ubuntu_focal: Executing Mondoo: [mondoo scan]
    amazon-ebs.ubuntu_focal:                         .-.
    amazon-ebs.ubuntu_focal: → loaded configuration from /home/m/.mondoo.yml
    amazon-ebs.ubuntu_focal:                         : :
    amazon-ebs.ubuntu_focal: → resolve assets
    amazon-ebs.ubuntu_focal: ,-.,-.,-. .--. ,-.,-. .-' : .--.  .--.
    amazon-ebs.ubuntu_focal: → discover related assets for 1 assets
    amazon-ebs.ubuntu_focal: : ,. ,. :' .; :: ,. :' .; :' .; :' .; :
    amazon-ebs.ubuntu_focal: → resolved 1 assets
    amazon-ebs.ubuntu_focal: :_;:_;:_;`.__.':_;:_;`.__.'`.__.'`.__.'
    amazon-ebs.ubuntu_focal:
    amazon-ebs.ubuntu_focal: → execute policies
    amazon-ebs.ubuntu_focal: → establish connection to asset 34.203.240.185 (baremetal)
    amazon-ebs.ubuntu_focal: → verify platform access to 34.203.240.185
    amazon-ebs.ubuntu_focal: → gather platform details build= platform=ubuntu release=20.04
    amazon-ebs.ubuntu_focal: → synchronize asset name=ip-172-31-24-155
    amazon-ebs.ubuntu_focal: → run policies for asset asset=//assets.api.mondoo.app/spaces/beautiful-matsumoto-174617/assets/1pFSj47di9ALLhJM7QE33zsNrGq
    amazon-ebs.ubuntu_focal: → marketplace> fetched policy bundle from usptream policy=//assets.api.mondoo.app/spaces/beautiful-matsumoto-174617/assets/1pFSj47di9ALLhJM7QE33zsNrGq
    amazon-ebs.ubuntu_focal: → send all results asset=//assets.api.mondoo.app/spaces/beautiful-matsumoto-174617/assets/1pFSj47di9ALLhJM7QE33zsNrGq
    amazon-ebs.ubuntu_focal: → generate report asset=//assets.api.mondoo.app/spaces/beautiful-matsumoto-174617/assets/1pFSj47di9ALLhJM7QE33zsNrGq
    amazon-ebs.ubuntu_focal: → scan complete asset=//assets.api.mondoo.app/spaces/beautiful-matsumoto-174617/assets/1pFSj47di9ALLhJM7QE33zsNrGq
    amazon-ebs.ubuntu_focal: → render report asset=//assets.api.mondoo.app/spaces/beautiful-matsumoto-174617/assets/1pFSj47di9ALLhJM7QE33zsNrGq
    amazon-ebs.ubuntu_focal:
    amazon-ebs.ubuntu_focal: ip-172-31-24-155
    amazon-ebs.ubuntu_focal: ================
    amazon-ebs.ubuntu_focal:
    amazon-ebs.ubuntu_focal: +----------------------------+
    amazon-ebs.ubuntu_focal: |   ___                      |
    amazon-ebs.ubuntu_focal: |  / __|   Fair 41/100       |
    amazon-ebs.ubuntu_focal: | | (__    75% complete      |
    amazon-ebs.ubuntu_focal: |  \___|   == ==             |
    amazon-ebs.ubuntu_focal: +----------------------------+
    amazon-ebs.ubuntu_focal:
    amazon-ebs.ubuntu_focal: Url: https://mondoo.app/space/assets/1pFSj47di9ALLhJM7QE33zsNrGq?spaceId=my-test-space
    amazon-ebs.ubuntu_focal:
    amazon-ebs.ubuntu_focal: Asset Policy 1pFSj47di9ALLhJM7QE33zsNrGq
    ...

This report is also uploaded to the mondoo.app and can be accessed within the UI. The default ubuntu aws image is not so well configured based on the report of mondoo.

a sample mondoo report

How to run Mondoo within Gitlab CI/CD

Now we also want to run this job within our Gitlab CICD. We can use the configuration dialog of the mondoo.app and generate a base64 encoded configuration string:

mondoo cicd configuration

Afterwards you can create a CICD variable on Gitlab and paste this string into this variable. On the before_script of the build stage the mondoo app is downloaded and also the mondoo packer provisioner gets in its place.

 1stage: packer
 2image:
 3    name: hashicorp/packer:1.7.0
 4    entrypoint:
 5        [
 6        "/usr/bin/env",
 7        "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
 8        ]
 9variables:
10    MONDOO_CONFIG_PATH: "/tmp/mondoo.json"
11before_script:
12    - apk add --no-cach --quiet jq aws-cli gettext bash curl
13    - echo "$MONDOO_AGENT_ACCOUNT" | base64 -d > "$MONDOO_CONFIG_PATH"
14    - curl -sSL https://mondoo.io/download.sh | bash && mv mondoo /usr/local/bin/
15    - mkdir -p ~/.packer.d/plugins
16    - curl https://releases.mondoo.io/packer-provisioner-mondoo/latest.json | jq -r '.files[] | select (.platform=="linux").filename' | xargs -n 1 curl | tar -xz > ~/.packer.d/plugins/packer-provisioner-mondoo
17    - chmod +x ~/.packer.d/plugins/packer-provisioner-mondoo
18script:
19    - packer build aws_ubuntu.pkr.hcl

Final thoughts

Mondoo is very easy to use and you get a user friendly UI to browse through the assets and configurations. Also the initial setup is an uncomplicated process and well documented. Just with a view clicks you can customize the ruleset on the WebUI to your custom needs e.g. you cannot turn off root logins completly, but just want to force passwordless root logins.

I got 2 major issues or feature requests:

  • I want to see if there are/were any changes in the classification of an asset - either caused by updates from the OS or caused by updates in the provisioning. So you would be able to detect changes which were made without any notification.

  • In the use case of packer builds i would love to get a view on the a build definition based on its runs. At the moment also a packer build is treated as infrastructure instance, even when labels are already available and mondoo also knows that this asset is generated by a packer run. So you get many assets generated where you cannot distinct between each packer run because the asset is identified by its IP/hostname.

Go Back explore our courses

We are here for you

You are interested in our courses or you simply have a question that needs answering? You can contact us at anytime! We will do our best to answer all your questions.

Contact us