Home
The Black Duck OpsSight Connector (ose-scanner) automates the discovery of open-source components and security vulnerabilities in container images as they are instantiated in container-orchestration platforms. OpsSight helps you prevent known open source vulnerabilities from being deployed into production environments.
With OpsSight, you can:
- Scan and inventory open source in images as they are instantiated in a container-orchestration platform.
- Identify and highlight any images that contain known security vulnerabilities.
- Flag containers that violate open source security policies to prevent them from being deployed to production.
- Receive automated alerts when any newly discovered vulnerabilities may affect containers in your cluster.
The OpsSight Connector detects when new pods are added to a cluster environment (OpsSight on OpenShift also detects new images through ImageStreams), scans those containers, sends information back to the Black Duck Hub, then annotates and labels containers to indicate risks detected in the containers' open-source components. Detailed scan results are available in your Hub instance. Container annotations can be used to enforce security policies and ensure vulnerable containers are not deployed in production environments.
The end-to-end OpsSight solution therefore requires a Black Duck Hub with an OpsSight feature license.
The latest version of the OpsSight Connector supports both Kubernetes and Red Hat OpenShift.
For more information on the OpsSight Connector, see the:
- the ose-scanner README
- OpsSight Connector Installation Guide (Includes Release Notes and Supported Platforms)
- OpsSight Connector Security Disclosures
Three components comprise the OpsSight Connector (ose-scanner) solution, and each has an independent Makefile. Each is listed, below.
The arbiter operates as a singleton replica. This is one of three requisite containers in the solution. The arbiter's roles are to:
- update any security annotations created during scans,
- ensure duplicate scans aren't performed, and
- process Hub notifications. Each notification contains an indication of the policy state for the named Docker image.
The arbiter currently limits the number of concurrent Hub scans to seven.
The controller operates as a daemon set. It has three core functional elements and forms the main integration point with your orchestrated-container cluster. (Note: In OpenShift environments, the controller executes within the master role.) At startup, the controller first enumerates all Docker images present in the target environment on the specific node. Those images are queued for scanning by hub_scanner docker images. The controller will process concurrent scans as workers. Once image enumeration completes, the controller monitors for new images and as they are created, these new images are queued for the hub_scanner.
The hub_scanner is a Docker image responsible for extracting the Docker image layers from a Docker image and invoking a Hub scan engine. The version of the Hub scan engine is compiled in during the Docker image creation. Note that in production systems, the hub_scanner Docker image should be updated whenever the Hub server is updated. Doing so will ensure the hub_scanner operates at peak efficiency.
For information on building the OpsSight Connector from scratch, please see the compilation page.
For information on installing the OpsSight Connector (either one you have built from scratch, or from a tar file received from an authorized Black Duck customer success representative), go here.
If you are experiencing problems, either during compilation, or runtime, please see if these debugging steps help.