-
Notifications
You must be signed in to change notification settings - Fork 9
Component Architecture
The OpsSight Connector is considered a “downstream” project, which means that the bulk of its content is implemented in several “upstream” open-source projects. Each upstream project is inherited to create one or more components (containers) in an OpsSight Connector deployment.
The OpsSight Connector consists of four containers on Kubernetes, and five on OpenShift. The OpsSight Connector comprises the following components:
- Core: from the "Perceptor" upstream project
- Image Getter: from the "Perceptor Scanner" upstream project
- Image Scanner: from the "Perceptor Scanner" upstream project
- Pod Processor: from the "Perceivers" upstream project
- Image Processor: from the "Perceivers" upstream project - OpenShift only
+---------------+
| |
| |
| core |
+--------------+----------+ | |
| | | | |
| image-getter | scanner | | |
| | +--------------> |
+--------------+----------+ +----+----+-----+
^ ^
| |
| |
+-------------------+ | | +---------------------+
| | | | | |
| pod-processor | | | | image-processor |
| +----+ +---+ |
| | | |
+-------------------+ +---------------------+
The Pod and Image Processor containers inform the Core container of events, and poll it for completed processing. The Image Scanner container polls the Core container for work to be done, and updates the Core container with the results of that work. The Pod and Image Processors are then able to resume their goal of annotating pods and images based on the events they originally submitted to the Core container. The Image Getter container and the Image Scanner container live together in the same Scanner pod. The Image Getter container can be replaced by a non-privileged implementation that is capable of getting docker image exports and saving them (see Custom Image Getters).
Provides the core API definition and coordinates receiving events and posting overall system status and progress. This container manages the OpsSight data model, which stores:
- what has been detected
- what has been scanned
- what still needs to be scanned
- what vulnerabilities were detected
It is the integration point between the Processors (called "Perceivers" upstream), Scanners, and Black Duck. It also handles the core logic and features such as scan throttling and error recovery. The core thinks in terms of Docker images, which are uniquely identified by SHAs. The atomic unit of work in OpsSight is a Docker image: it is what's scanned by the scanners and recorded in Black Duck. Since Kubernetes pods consist of one or more containers, each of which refer to a Docker image, each image can be scanned and combined annotations produced for the pod. However, the fundamental unit of scanning -- an image -- is unchanged.
Retrieves images using the Docker daemon on your host. It is, at its core, responsible for getting access to images as .tar files.
Scans images on your cluster using the Black Duck scan client. This scan client is then used to scan new images. The scanner is always up to date your Black Duck deployment's current version.
Sends pod events to opssight-core, and process security scan results for those pods once they are completed.
Sends cloud image events that occur on your cluster to opssight-core, and process security scan results for those pods once they are completed.
- Home
- Before You Begin
- Overview
- Component Architecture
- Release Notes
- Contact Us
- Official Customer Docs
- OpsSight Solution Installation Guide
- OpsSight Connector Installation Guide
- Pushing OpsSight Images to a Secure Registry
- Installing OpsSight Connector from a Secure Registry
- Image Registries with Rotating Authentication Tokens