Feature: container security scanning - cockpit-project/cockpit GitHub Wiki

Notes

Previous art

Stories

Sarah Manning is a part-time backend developer, part-time sysadmin at her company. The company she in charge of two atomic systems. One staging server for internal testing and one public, production server that hosts their web service. She wants to know as soon as possible when a vulnerability shows up in any of her containers. The public one is more critical than the internal one.

Robert Paulsson is a developer at a small IT company. He's a senior engineer, but got tossed the sysadmin hat at the company. The company have 3 internal servers that runs various services that the R&D unit needs for their day to day basis. He checks in on the servers maybe once a week to make sure everything is running all right. The company has a contract with Cyberduck, so they use that for his vulnerability scan.

Simon Legree is the security officer for large company XYZ. He hears about a new vulnerability Sledgehammer, and gets his scanning containers updated that can discover sledgehammer. He wants to run an on demand scan of all of his containers.

Phillip J Fry is a junior sysadmin at a company that sells office materials. He has been tasked with setting up a e-commerse system in a container running on a Atomic host. He needs to make sure that the container is PCI-DSS compliant so the webshop on their company website can allow their customers to do card payments.

Workflows

Sarah logs in to the staging server. At the dashboard she's notified that there are 5 vulnerabilities that has been found across 3 of the running containers. She navigates to the container page. She does another manual scan to make sure nothing new has come up since the last scan. It has, and there are now 7 vulnerabilities across 4 containers. All of the affected containers are based on the same base image. She updates the image and the affected containers. Everything is now up to date and safe and everything runs as expected. She pushes all the changes to the production server.

Robert logs in to one of the servers. At the multi-machine dashboard he gets notified that there are several vulnerabilities, affecting several containers across 2 of the machines. He selects the machines and hit a button to update them both. Everything is now updated.

Simon logs in to the server running the containers and runs a scan across all the containers. A couple of vulnerabilities comes up. Since he's particularly concerned about the "Sledgehammer" vulnerability, he searches for the CVE number for that. One of the containers does indeed contain that vulnerability. He updates it to a newer version that contains a fix against "Sledgehammer".

Phillip Installs the system, and then logs in to the system via Cockpit and goes to the containers page. He runs the compliance scan and notice that it passes all the checks but one. He fixes that issue and runs the scan again, and this time the compliance scan passes. After some additional testing, he pushes to production. The office supplier is now able to take card payments in their webshop.

Wireframes

mockup

Implementation

  • There are more than one scanning backend to choose from.

    • Each container backend can run one or more scan types
    • Each container backend has a default scan type

  • There is a default scanning backend for a host.

    • A user will not be forces to choose every time.

  • We have an DBus API to list of all scanner backends and the scanner types available, including the default scanner and scan types.

  • Scanning information is cached on by date as JSON information, based on scan/scan type.

    • Need to add DBUS API that will bring back json data based on image id for the last scan/scantype results for this particular image .

  • One can choose between different targets/scan-types/profiles to target.

    • For example one can search for anything that has a CVE. Or one can be stricter.
    • We would need a new API to return vulnerabilties for all containers. IE Give back a list of container images which have a particular vulnerability. Probably use a simple search.

  • Currently, a call to the scan will return a JSON dictionary with all the information related to the scan such as vulnerabilities.

  • Users should be able to schedule certain scans or run scans on demand on all containers/images/both as well as run scans on particular container images, and even on a rootfs.

Feedback

Please give feedback on the above!

  • It feels like especially Robert, but also Sarah really needs some timer that periodically scans the systems for vulnerabilities. - Andreas
  • The UI needs filtering - Stef
  • The UI needs to be able to dive into scan details for an image - Stef
  • What happens when I click the 'Scan Again' button? Is there a Dialog shown? What does it look like. - Stef
  • Where do I schedule periodic scans? - Stef
  • Scanning for configuration compliance is missing. Or is it part of scan type? - Martin