HashiCorp Nomad and Vault: Dynamic Secrets
In a cloud-native environment, secrets management is a critical aspect of security. HashiCorp Vault is a popular tool for managing secrets and protecting
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.
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.
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.
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:
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
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.
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