Cisco Panoptica works upstream in the CI/CD pipeline to identify workloads that are ready to be deployed in your clusters. In this way, you can identify bonafide workloads upfront, and authorize only these workloads when they are deployed to your Kubernetes clusters. The workload authorization will verify that only workloads that came from the CI/CD pipeline will be deployed, while unknown workloads - those without a Panoptica identity - will be blocked or detected (deployed, but marked as "unknown").
In addition to the workload identity, Panoptica also performs vulnerabilities scanning when the images are built in the CI stage. You can define the vulnerabilities thresholds that are required, in order to permit workloads to pass the CI stage.

This is all done using the Panoptica plugin that you can include in your CI toolsets. The Docker plugin works at the docker level and is invoked when a docker push or docker image push command is made.

The plugin sends information to Panoptica about the workload, which Panoptica uses to generate an identity.

Install the Plugin

On the Panoptica console, create a user with the Service role. This user will be used by plugin. Copy the value of the Access Token; it will be used by the plugin (see below).
Navigate to the CI/CD page, and select the PLUGINS tab. Scroll to DOCKER.
Download the plugin using the link on the page.

Use the plugin

basic usage

example:

securecn_deployment_cli run-vulnerability-scan --access-key XXXXXXX --secret-key XXXXXXX --image-name=myRegistry/myImage:myTag

The scannner will search for vulnerabilities and test CIS benchmarks. The results can be found in the images screen.

Panoptica credentials

The access_key and secret_key values are from the Access token, created on Panoptica, in the preceding step. Alternatively, you can store those credentials as env variables (PORTSHIFT_CLI_ACCESS_KEY, PORTSHIFT_CLI_SECRET_KEY) and remove it from the command.
example:

export PORTSHIFT_CLI_ACCESS_KEY=XXXXXXX
export PORTSHIFT_CLI_SECRET_KEY=XXXXXXX
securecn_deployment_cli run-vulnerability-scan --image-name=myRegistry/myImage:myTag

Private registries

The scanner can scan private registries if you will provide credentials. The credentials for the private registries will be provided be --username and --password flags. alternatively you can store those credentials as env variables. (PORTSHIFT_CLI_DOCKER_USERNAME, PORTSHIFT_CLI_DOCKER_PASSWORD).
example:

securecn_deployment_cli run-vulnerability-scan --access-key XXXXXXX --secret-key XXXXXXX --username username --password XXXXXX --image-name=myPrivateRegistry/myImage:myTag

Local images

The scanner can scan local images which are built but not yet pushed to the registry. This option is also useful to prevent pushing vulnerable images into the registry. In order to scan a local image, specify the --local flag. Then, after the scan is completed successfully, the image can be pushed into the registry. In order to mark the image as identified in Panoptica, need to upload the results using the --upload-local-scan flag.
example:

export PORTSHIFT_CLI_ACCESS_KEY=XXXXXXX
export PORTSHIFT_CLI_SECRET_KEY=XXXXXXX
securecn_deployment_cli run-vulnerability-scan --image-name=myLocalImage:myLocalTag --local

docker push myLocalImage:myLocalTag

securecn_deployment_cli run-vulnerability-scan --image-name=myLocalImage:myLocalTag --upload-local-scan

There is also an option to scan a local image and push it to the registry using the CLI in one command (if it will pass the policy checks), by specifying the --local and --push-local flags. In this case, invoking the CLI again with --upload-local-scan is not needed.
example:

export PORTSHIFT_CLI_ACCESS_KEY=XXXXXXX
export PORTSHIFT_CLI_SECRET_KEY=XXXXXXX
securecn_deployment_cli run-vulnerability-scan --image-name=myLocalImage:myLocalTag --local --push-local

Fail on scan results

In some cases you will want the scanner to fail, according to its findings. You can set this in the CI/CD Scan Policy in the Panoptica console, and with flags in the scan command. If a policy is configured and the flags exists in the command, the scanner will fail according to the policy.

highest vulnerability severity flag: --highest-severity-allowed The highest vulnerability severity allowed. Valid values: CRITICAL, HIGH, MEDIUM, LOW, or UNKNOWN
highest docker file severity flag: --df-highest-severity-allowed value Dockerfile scan highest vulnerability severity allowed. Valid values: FATAL, WARN, INFO

Example:

securecn_deployment_cli run-vulnerability-scan --access-key XXXXXXX --secret-key XXXXXXX --image-name=myRegistry/myImage:myTag --highest-severity-allowed HIGH --df-highest-severity-allowed WARN