Mondoo 3.6.0 is out!

Announcing the 3.6 release of Mondoo, the security and compliance platform that prioritizes risks that matter most in your infrastructure.

3.6.0

🎉 FEATURES

new: add the --discover option and harmonize existing discovery methods

🧹 IMPROVEMENTS

improve: queries labels are more detailed and better reflecting its state
improve: updated the Kubernetes Benchmark and Windows 2019 Benchmark
improve: added experimental env variable MONDOO_PROCFS to activate procfs use to read processes
improve: switch arista transport scheme from aristaeos to arista

🐛 BUG FIXES AND UPDATES

fix: fixes an issue with the k8s:// resolver where the images where not properly detected via mondoo scan -t k8s://
fix: fixes an issue where the Windows service start took too long
fix: fixes an issue with Linux control that checked the grub 1 and grub 2 bootloader configuration
fix: fixes an issue where container images and repositories from registries could not be scanned
fix: handle case where suse 15.0 was not properly detected as eol
fix: (part two) fallback to /etc/hostname for platform identifier if hostname command is missing e.g on Arch Linux

🗑 REMOVED:

removed: we removed SSH Server Policy, please replace it with the appropriate policy for your environment, eg. DIL

🥳 new --discover option

We introduce a new --discovery and --discover-filter option to mondoo scan and mondoo shell. This allows a more clean separation between transport options via --option and discovery options. As part of this change we also enabled the discovery of container and images for the local docker agent.

Nested Scan for vSphere

mondoo scan -t vsphere://root@192.168.87.7 --discover host-machines,instances --discover-filter moids="HostSystem-ha-host"

# previously this would have been:
mondoo scan -t vsphere://root@192.168.87.7 --option host-machines=true --option instances=true --option moids="HostSystem-ha-host"

Ability to discover all docker container and images

mondoo scan -t docker:// --discover all

Explicit fetch from Container Registry

When users run mondoo scan -t docker://centos:7.8.2003 we try to use the local image from docker engine and fall-back to fetch if from remote. Users can now skip the docker resolve step and tell mondoo to go directly to the registry:

mondoo scan -t cr://centos:7.8.2003

🧹 switch arista transport scheme from aristaeos to arista

# before
mondoo scan -t aristaeos://admin@192.168.178.154 --ask-pass --insecure
# after
mondoo scan -t arista://admin@192.168.178.154 --ask-pass --insecure

🧪 experimental procfs implementation

Allow Linux users to opt-into the procfs implementation for processes via:

MONDOO_PROCFS="on" mondoo shell -t ssh://root@$(minikube ip)

🎉 Kubernetes Server + Agent Scan

To run the mondoo service on each node do the following:

Activate the Kubernetes Benchmark in your space
Download agent credentials
Update the following config

---
# daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: mondoo-daemonset

spec:
  selector:
    matchLabels:
      name: mondoo-daemonset
  template:
    metadata:
      labels:
        name: mondoo-daemonset
    spec:
      tolerations:
        # this toleration is to have the daemonset runnable on master nodes
        # remove it if your masters can't run pods
        - key: node-role.kubernetes.io/master
          effect: NoSchedule
      containers:
        - name: mondoo-agent
          image: docker.io/mondoolabs/mondoo
          command: ['mondoo', 'serve', '--config', '/etc/opt/mondoo/mondoo.yml']
          volumeMounts:
            - name: root
              mountPath: /mnt/host/
              readOnly: true
            - name: config
              mountPath: /etc/opt/mondoo/
              readOnly: true
          env:
            - name: DEBUG
              value: 'false'
            - name: MONDOO_PROCFS
              value: 'on'
      terminationGracePeriodSeconds: 30
      volumes:
        - name: root
          hostPath:
            path: '/'
        - name: config
          configMap:
            name: mondoo-daemonset-config
            items:
              - key: config
                path: mondoo.yml

Use your agent credentials and add them to a config map:

---
# daemonset-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: mondoo-daemonset-config
data:
  config: |
    agentmrn: //agents.api.mondoo.app/spaces/{spaceid}/agents/{agentid}
    api-endpoint: https://api.mondoo.app
    certificate: |
      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----
    privatekey: |
      -----BEGIN PRIVATE KEY-----
      ...
      -----END PRIVATE KEY-----
    spacemrn: //captain.api.mondoo.app/spaces/upbeat-haslett-916671
    assets:
    - connection: "fs:///mnt/host"

kubectl apply -f daemonset-config.yaml
kubectl apply -f daemonset.yaml

# verify that the service runs
kubectl get pods
NAME                     READY   STATUS      RESTARTS   AGE
mondoo-daemonset-dgrrz   1/1     Running     1          3d10h

🎉 Equinix API support

This is the first iteration of our Equinix Metal integration. It adds the following:

New Equinix Metal transport
New resources to check for equinix content

We think it is best to use project-scoped API credentials. During development we ran into an issue with the API that we worked around.

To connect to equinix:

export PACKET_AUTH_TOKEN="your_token_here"
mondoo shell -t equinix://projects/aa123456-a11a-b22b-c33c-123ab1cd234

Here are some sample queries:

equinix.metal.project { id name}
equinix.metal.project.users
equinix.metal.project.users { fullName }
equinix.metal.project.sshKeys {id fingerPrint}
equinix.metal.project.devices { hostname }

3.6.0

On this page