Uploaded image for project: 'Clair'
  1. Clair
  2. CLAIRDEV-50

Windows container image scanning

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Minor Minor
    • None
    • None
    • indexer, matcher, updater
    • None
    • Windows content support
    • True
      1. Need clarification on data source licensing.
      2. Need clarification on layer licensing.
    • False
    • To Do

      Epic Goal

      • Allow customers to get CVE reports for Windows-based container images in regards to base image content

      Why is this important?

      • OpenShift is supporting Windows Containers
      • Customers want to have a comprehensive view of the security state of all their containerized content, including Windows
      • Currently Quay users and customers are required to bring third-party solutions to enable Windows image scanning, which is causing fragmentation and operational overhead
      • Customer desire a single scanning stack in their enterprise and currently Quay only ships with / support Clair
      • Customers desire to view Windows container image vulnerability reports right inside the registry and do not want to utilize an external, third-party scanning solution and Quay currently does not have pluggable scanner support

      Scenarios

      1. A customer uses 3rd party ISV software that leverages Windows Server container base images
      2. A customer leverages Windows Server container base images to build custom images
      3. A customer can use Quay with Clair to see the indexed content of a manifest that leverages Windows Server images as the base image
      4. A customer can use Quay with Clair to get vulnerability reports of a manifest that leverages Windows Server images as the base image

      Acceptance Criteria

      • Clair running on Linux systems can index Windows container base image content
      • Clair running on Linux systems can match vulnerabilities published by Microsoft against the indexed Windows container base image content
      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Dependencies (internal and external)

      1. Microsoft Security Response Center API: https://api.msrc.microsoft.com/cvrf/v2.0/swagger/index

      Open questions:

      1. How is authorization handled for nonredistributable layers?
      2. Are we allowed by license to handle Windows base layers?
      3. How will we do automated testing with layers with distribution restrictions?
      4. What data do we need to discover out of base layers, and how?

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

              Unassigned Unassigned
              DanielMesser Daniel Messer
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: