Containerized Scan Engine

The Containerized Scan Engine is a form of Distributed Scan Engine that delivers the Scan Engine as a packaged or portable application that can easily be deployed to modern infrastructure. The Containerized Scan Engine ships as a single image and includes the Scan Engine software and all required dependencies, such as the Operating System, libraries, and associated files. Information about the Containerized Scan Engine is also maintained on Rapid7’s Docker Hub page .

Release schedule - The Containerized Scan Engine follows the regular product and content release schedule. Updates will be made on a continuous basis.
Supported architecture - The Containerized Scan Engine supports AMD64 architecture, specifically x86_64 architecture.

Requirements

macOS supportability restriction

M1 chips are not supported.

For information about the Containerized Scan Engine’s system requirements, refer to System Requirements.

Prerequisites

Before you begin, ensure that you have:

Access to the Security Console
The Console Shared Secret Key
The latest engine image - docker pull rapid7/insightvm_scan_engine:latest

Default TCP port

The default TCP port, 40814, is used by the Security Console to communicate with the Containerized Scan Engine. However, if the Containerized Scan Engine is connected to the Security Console it does not need to be exposed.

Image tags

We provide multiple tags to help users identify the Scan Engine and content versions. The Containerized Scan Engine is updated continuously and bundled with the latest available content at the time of release. Refer to the digest of the image in order to see the correlation between tags.

Tag Value	Description	Example
latest	The most recent product and content release version available.	`latest`
product version	The product release version.	`6.6.188`
product and content version	The content release version.	`6.6.188-content1.1.2837`

Running the Containerized Scan Engine

Existing mount points

These are the existing mount points associated with the Containerized Scan Engine:

Mount point	Description
`/opt/rapid7/nexpose/nse/scans`	The scans directory is where the Containerized Scan Engine temporarily writes logs and results to. The Security Console will ask the Containerized Scan Engine to remove scan data associated with completed scans when the data associated with it is transferred to the Security Console. Though, if the Containerized Scan Engine is upgraded before all the scan data is transferred to the Security Console, and the scans directory is not a persisted volume, the scan data will be lost. This directory is recommended. The file system performance of this directory can have an impact on scan performance.
`/opt/rapid7/nexpose/nse/conf`	The configuration directory stores the Containerized Scan Engine, logger configuration properties, and a list of trusted consoles. The configuration directory can be optional if auto-pairing environment variables are used, since the Containerized Scan Engine will auto-pair each time it starts. However, we do recommend that an external configuration directory be used.
`/opt/rapid7/nexpose/nse/keystores`	The keystores directory stores the private identity of the Containerized Scan Engine, and is used to establish trust with the Security Console. This directory is optional if you do not intend to keep the Containerized Scan Engine up to date or paired to the Security Console. Otherwise, the keystores directory must be mounted or the Containerized Scan Engine will generate a new private identity each time it is started.
`/opt/rapid7/nexpose/nse/logs`	The logs directory stores logs on an eternal volume. This directory is optional. The file system performance of this directory can have an impact on the performance of individual scans.

Environment variables

You may encounter the following environment variables:

Environment Variable	Description
CONNECT_TO_ADDRESS	This is the IP address where the Security Console will wait for connections from the Containerized Scan Engine.
CONNECT_TO_SHARED_SECRET	If a shared secret is provided, the Containerized Scan Engine will add itself to the Security Console. The shared secret must be the same as the one generated on the Containerized Scan Engine Management page in the Security Console’s UI. In the event that the shared secret is not provided the Containerized Scan Engine must be added on the Containerized Scan Engine Management page under the Administration tab in the Security Console’s UI.
CONNECT_TO_PORT	This listening port can be manually configured and requires exposure as it replaces the existing listening port number in the `nsc.xml` file.
ACCEPT_FROM_ADDRESS	This IP address will be used by the Security Console to connect to the Containerized Scan Engine.
ACCEPT_FROM_SHARED_SECRET	If a shared secret is provided, the Containerized Scan Engine will challenge the Security Console and will not trust the Security Console if the response from the Security Console is incorrect. The shared secret must be the same as the one generated on the Containerized Scan Engine Management page in the Security Console’s UI. In the event that the shared secret is not provided, the Containerized Scan Engine will not challenge the Security Console and will trust the first console that connects to it using the IP address.

Environment variable stipulations

You can use a CONNECT_TO_ADDRESS and an ACCEPT_FROM_ADDRESS at the same time, but it is not possible to use multiple addresses for CONNECT_TO_ADDRESS or ACCEPT_FROM_ADDRESS at the same time.

Running containers with Docker commands

You can run the following Docker commands:

Command	Description
`docker pull rapid7/insightvm_scan_engine:latest`	Pulls the latest image
`docker run --env CONNECT_TO_SHARED_SECRET=<SHARED_SECRET> --env CONNECT_TO_ADDRESS=<CONSOLE_ADDRESS> rapid7/insightvm_scan_engine:latest`	Starts a container connecting to the Security Console
`docker run --env ACCEPT_FROM_ADDRESS=<CONSOLE_ADDRESS> --env ACCEPT_FROM_SHARED_SECRET=<SHARED_SECRET> -p 40814:40814 rapid7/insightvm_scan_engine:latest`	Starts a container with accepting connection from the Security Console
`docker run --env CONNECT_TO_SHARED_SECRET=<SHARED_SECRET> --env CONNECT_TO_ADDRESS=<CONSOLE_ADDRESS> -v /var/docker/nse-container/data/rapid7/nexpose/nse/conf:/opt/rapid7/nexpose/nse/conf -v /var/docker/nse-container/data/rapid7/nexpose/nse/keystores:/opt/rapid7/nexpose/nse/keystores -v /var/docker/nse-container/data/rapid7/nexpose/nse/logs:/opt/rapid7/nexpose/nse/logs -v /var/docker/nse-container/data/rapid7/nexpose/nse/scans:/opt/rapid7/nexpose/nse/scans rapid7/insightvm_scan_engine:latest`	Starts a container with external mount points

Running containers with Docker Compose

You can run the following commands with Docker Compose:

Run a single container with Docker Compose connected to the Security Console


version: "3"
services:
  nse-1:
    image: rapid7/insightvm_scan_engine
    volumes:
      - /var/docker/nse-1/data/rapid7/nexpose/nse/conf:/opt/rapid7/nexpose/nse/conf
      - /var/docker/nse-1/data/rapid7/nexpose/nse/keystores:/opt/rapid7/nexpose/nse/keystores
      - /var/docker/nse-1/data/rapid7/nexpose/nse/logs:/opt/rapid7/nexpose/nse/logs
      - /var/docker/nse-1/data/rapid7/nexpose/nse/scans:/opt/rapid7/nexpose/nse/scans
    environment:
      - CONNECT_TO_ADDRESS=<CONSOLE_ADDRESS>
      - CONNECT_TO_SHARED_SECRET=<SHARED_SECRET>

Run a single container with accepting connections from the Security Console


version: "3"
services:
  nse-1:
    image: rapid7/insightvm_scan_engine
    ports:
      - "40814:40814"
    volumes:
      - /var/docker/nse-1/data/rapid7/nexpose/nse/conf:/opt/rapid7/nexpose/nse/conf
      - /var/docker/nse-1/data/rapid7/nexpose/nse/keystores:/opt/rapid7/nexpose/nse/keystores
      - /var/docker/nse-1/data/rapid7/nexpose/nse/logs:/opt/rapid7/nexpose/nse/logs
      - /var/docker/nse-1/data/rapid7/nexpose/nse/scans:/opt/rapid7/nexpose/nse/scans
    environment:
      - ACCEPT_FROM_ADDRESS=<CONSOLE_ADDRESS>
      - ACCEPT_FROM_SHARED_SECRET=<SHARED_SECRET>

Run multiple engines connecting to the Security Console


version: "3"
services:
  nse-1:
    image: rapid7/insightvm_scan_engine
    volumes:
      - /var/docker/nse-1/data/rapid7/nexpose/nse/conf:/opt/rapid7/nexpose/nse/conf
      - /var/docker/nse-1/data/rapid7/nexpose/nse/keystores:/opt/rapid7/nexpose/nse/keystores
      - /var/docker/nse-1/data/rapid7/nexpose/nse/logs:/opt/rapid7/nexpose/nse/logs
      - /var/docker/nse-1/data/rapid7/nexpose/nse/scans:/opt/rapid7/nexpose/nse/scans
    environment:
      - CONNECT_TO_ADDRESS=<CONSOLE_ADDRESS>
      - CONNECT_TO_SHARED_SECRET=<SHARED_SECRET>
  nse-2:
    image: rapid7/insightvm_scan_engine
    volumes:
      - /var/docker/nse-2/rapid7/nexpose/nse/conf:/opt/rapid7/nexpose/nse/conf
      - /var/docker/nse-2/rapid7/nexpose/nse/keystores:/opt/rapid7/nexpose/nse/keystores
      - /var/docker/nse-2/rapid7/nexpose/nse/logs:/opt/rapid7/nexpose/nse/logs
      - /var/docker/nse-2/rapid7/nexpose/nse/scans:/opt/rapid7/nexpose/nse/scans
    environment:
      - CONNECT_TO_ADDRESS=<CONSOLE_ADDRESS>
      - CONNECT_TO_SHARED_SECRET=<SHARED_SECRET>
  nse-3:
    image: rapid7/insightvm_scan_engine
    volumes:
      - /var/docker/nse-3/rapid7/nexpose/nse/conf:/opt/rapid7/nexpose/nse/conf
      - /var/docker/nse-3/rapid7/nexpose/nse/keystores:/opt/rapid7/nexpose/nse/keystores
      - /var/docker/nse-3/rapid7/nexpose/nse/logs:/opt/rapid7/nexpose/nse/logs
      - /var/docker/nse-3/rapid7/nexpose/nse/scans:/opt/rapid7/nexpose/nse/scans
    environment:
      - CONNECT_TO_ADDRESS=<CONSOLE_ADDRESS>
      - CONNECT_TO_SHARED_SECRET=<SHARED_SECRET>

Test the Containerized Scan Engine

If you want to start a Containerized Scan Engine to test how it works, you are able to run it in daemon mode. However, the Containerized Scan Engine will not be useful if it is not connected with the Security Console.

To test the Containerized Scan Engine without connecting to the Security Console:

Run the container: docker run --name first_engine rapid7/insightvm_scan_engine:latest.
Verify that the container is running: docker ps.

Run the Containerized Scan Engine and connect to the Security Console

You can choose to either standard pair or reverse pair the Containerized Scan Engine to the Security Console.

Configure a standard pair with your Security Console - docker run --env ACCEPT_FROM_ADDRESS=<CONSOLE_ADDRESS> --env ACCEPT_FROM_SHARED_SECRET=<SHARED_SECRET> -p 40814:40814 rapid7/insightvm_scan_engine:latest

You may need to use the gateway address as your CONSOLE_ADDRESS, depending on your Docker network configuration when standard pairing - docker inspect <container-id> | grep Gateway

Configure a reverse pair with your Security Console - docker run --env CONNECT_TO_SHARED_SECRET=<SHARED_SECRET> --env CONNECT_TO_ADDRESS=<CONSOLE_ADDRESS> rapid7/insightvm_scan_engine:latest

Run the Containerized Scan Engine using Kubernetes

To run the Containerized Scan Engine in Kubernetes, create the necessary infrastructure and permissions required.

Prerequisites

To run the Containerized Scan Engine using Kubernetes, you’ll need the following:

A Kubernetes cluster with a node that meets the minimum requirements to run the Containerized Scan Engine
Access to the Scan Engine image egress access nodegroup to Docker Hub
kubectl configured and installed for cluster management
A persistent production driver volume, which can differ depending on the storage provider
To meet the necessary requirements for setup, as outlined in the AWS environment and GCP environment sections

Kubeconfig

A YAML file is used by Kubernetes to store cluster information for kubectl to refer to when running commands. Configure your Kubernetes environment to be able to run the Containerized Scan Engine:

Step 1: Create volumes

To quickly and easily deploy updates, create the persistent volume (PV) and persistent volume claim (PVC) by using the volume ID and the following configs:


apiVersion: v1
kind: PersistentVolume
metadata:
  name: ebs-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce # meaning this PV can only be claimed once in read-write mode by one Pod
  storageClassName: ""
  persistentVolumeReclaimPolicy: Retain # when PVC is deleted, the PV will be kept around in protection mode meaning no other PVC can claim it, and data in the volume is persisted
  csi:
    driver: <driver in this example it is ebs.csi.aws.com>
    volumeHandle: <reference to volume vol-08a88cac24536707e>


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ""
  resources:
    requests:
      storage: 5Gi


kubectl apply -f ./pvc.yaml
kubectl apply -f ./pv.yaml

Step 2: Create a deployment

Create the following deployment with the node that can run the Containerized Scan Engine:

Deployment is for reverse pairing

This deployment configuration is for an Engine-to-Console connection.


apiVersion: apps/v1
kind: Deployment
metadata:
  name: scan-engine
spec:
  selector:
    matchLabels:
      app: scan-engine
  template:
    metadata:
      labels:
        app: scan-engine
    spec:
      containers:
        - name: scan-engine
          image: rapid7/insightvm_scan_engine:latest
          volumeMounts:
          - name: persistent-storage
            mountPath: /opt/rapid7/nexpose/nse/conf
            subPath: engine1/conf
          - name: persistent-storage
            mountPath: /opt/rapid7/nexpose/nse/keystores
            subPath: engine1/keystores
          env:
          - name: CONNECT_TO_ADDRESS
            value: <ip-address>
          - name: CONNECT_TO_SHARED_SECRET
            value: <shared secret>
          ports:
          - containerPort: 40814
      volumes:
      - name: persistent-storage
        persistentVolumeClaim:
          claimName: ebs-claim


kubectl apply -f ./scan-engine-deployment.yaml

Step 3: Create a Service

This exposes the service to accept connections from consoles:


apiVersion: v1
kind: Service
metadata:
  name: scan-engine
  labels:
    app: scan-engine
spec:
  ports:
    - port: 40814
      targetPort: 40814
      protocol: TCP
  selector:
    app: scan-engine


kubectl apply -f ./scan-engine-service.yaml

Step 4: (Optional) Update the Scan Engine

Manually update the Scan Engine:


kubectl rollout restart deployment/scan-engine

Standard pairing

⚠️

Reverse pairing is recommended

Reverse pairing is recommended as standard pairing may pose a security concern due to the requirement to expose a port and IP address for the Containerized Scan Engine. If you choose to standard pair, make sure the ingress rule is restricted to only the listener port and the console IP address.

When standard pairing (Console-to-Engine), use the cluster IP address in order to add the Scan Engine and the NodePort as the port. The value for ACCEPT_FROM_ADDRESS should be the internal IP address within the node that is used to route traffic to the pod. The IP range assigned to a node should have the IP address as the second address in the range (the first should be the broadcast address). The valid IP address in the node pod CIFR can be retrieved by the command or in the console:


kubectl get node <node name> -o jsonpath="{.spec}"


apiVersion: apps/v1
kind: Deployment
metadata:
  name: scan-engine
spec:
  selector:
    matchLabels:
      app: scan-engine
  template:
    metadata:
      labels:
       app: scan-engine
    spec:
      containers:
      - name: scan-engine
        image: rapid7/insightvm_scan_engine:latest
        ports:
        - containerPort: 40814
        volumeMounts:
          - name: persistent-storage
            mountPath: /opt/rapid7/nexpose/nse/conf
            subPath: engine1/conf
          - name: persistent-storage
            mountPath: /opt/rapid7/nexpose/nse/keystores
            subPath: engine1/keystores
        env:
        - name: ACCEPT_FROM_ADDRESS
          value: <Node Internal IP Address>
      volumes:
      - name: persistent-storage
        persistentVolumeClaim:
          claimName: ebs-claim


kubectl apply -f scan-engine-deployment.yaml

NodePort value must be within 30000-32767 range

The NodePort value must be within the 30000-32767 range. For more information on the default range, refer to Kubernetes’ documentation .


apiVersion: v1
kind: Service
metadata:
  name: scan-engine
  labels:
    app: scan-engine
spec:
  type: NodePort
  ports:
    - port: 40814
      targetPort: 40814
      protocol: TCP
      nodePort: 30001
  selector:
    app: scan-engine


kubectl apply -f ./scan-engine-service.yaml

Deploy and manage containers with Kubernetes StatefulSets

StatefulSet is the workload API object used to manage stateful applications. It manages the deployment and scaling of a set of pods and provides a persistent identity for each of its pods through any rescheduling. It is especially ideal for those that intend to deploy multiple scan engine containers as long-lived (non-ephemeral) containers, as their identities will continue to persist for later updates.

Creating Statefulsets

The three major components when creating a Statefulset are:

scan-engine-group-srv - a headless service that’s used for the network identity of the Pods.
scan-engine-group-srv - this StatefulSet configures three replicas that will be launched in unique pods .
VolumeClaimTemplates - for each VolumeClaimTemplate entry defined in a StatefulSet a pod receives one PersistentVolumeClaim, and a PersistentVolume and storage will be dynamically provisioned.

Here is an example of creating a StatefulSet using YAML:


apiVersion: v1
kind: Service
metadata:
  name: scan-engine-group-srv
  labels:
    app: scan-engine-group-srv
spec:
  ports:
  - port: 80
    name: scan-engine-group-web
  selector:
    app: scan-engine-group
 
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: scan-engine-group
spec:
  selector:
    matchLabels:
      app: scan-engine-group # has to match .spec.template.metadata.labels
  serviceName: "scan-engine-group"
  replicas: 3
  template:
    metadata:
      labels:
        app: scan-engine-group # has to match .spec.selector.matchLabels
    spec:
      containers:
      - name: scan-engine-container
        image: rapid7/insightvm_scan_engine:latest
        ports:
        - containerPort: 40814
        env:
          - name: CONNECT_TO_SHARED_SECRET
            value: <CONNECT_TO_SHARED_SECRET>
          - name: CONNECT_TO_ADDRESS
            value: <CONNECT_TO_ADDRESS>
        volumeMounts:
        - name: ajing-cluster-volume
          mountPath: /opt/rapid7/nexpose/nse/conf
          subPath: scan-engine-group/conf
        - name: ajing-cluster-volume
          mountPath: /opt/rapid7/nexpose/nse/keystores
          subPath: scan-engine-group/keystores
  volumeClaimTemplates:
  - metadata:
      name: ajing-cluster-volume
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "standard"
      resources:
        requests:
          storage: 1Gi

Executing StatefulSets in Kubernetes

After deploying the templates for all three components, three pods will be created named scan-engine-group-0, scan-engine-group-1, scan-engine-group-2.


kubectl apply -f scan-engine-statefulset.yaml


kubectl get pods NAME                  READY   STATUS    RESTARTS   AGE
scan-engine-group-0   1/1     Running   0          6m8s
scan-engine-group-1   1/1     Running   0          5m38s
scan-engine-group-2   1/1     Running   0          3m48s

Volumes with StatefulSets

Each pod receives a PersistentVolume with a StorageClass standard and 1GB of provisioned storage. When a pod is deployed, VolumeMounts mount the PersistentVolume associated with its PersistentVolumeClaim.

Deleting or scaling pods

When a pod is deleted or scaled down the associated PersistentVolumeClaim, PersistentVolume, and storage will remain; deletion must be done manually.

Verify that the PVCs and PV are dynamically provisioned:


kubectl get pvc
NAME                                       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
ajing-cluster-volume-scan-engine-group-0   Bound    pvc-44085d05-bea9-48f2-9753-0c2480db8867   1Gi        RWO            standard       3d1h
ajing-cluster-volume-scan-engine-group-1   Bound    pvc-44eb177c-3f50-4dfd-b8a6-c35823576c23   1Gi        RWO            standard       3d1h
ajing-cluster-volume-scan-engine-group-2   Bound    pvc-29bcabbb-437d-4a55-905c-a53093a59cc9   1Gi        RWO            standard       3d1h


kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                              STORAGECLASS   REASON   AGE
pvc-29bcabbb-437d-4a55-905c-a53093a59cc9   1Gi        RWO            Delete           Bound    default/ajing-cluster-volume-scan-engine-group-2   standard                3d1h
pvc-44085d05-bea9-48f2-9753-0c2480db8867   1Gi        RWO            Delete           Bound    default/ajing-cluster-volume-scan-engine-group-0   standard                3d1h
pvc-44eb177c-3f50-4dfd-b8a6-c35823576c23   1Gi        RWO            Delete           Bound    default/ajing-cluster-volume-scan-engine-group-1   standard                3d1h

Scaling StatefulSets

Scale the number of pods using the kubectl scale command:


kubectl scale statefulsets scan-engine-group --replicas=<replica_count>

Alternatively, you can update the number of replicas in the StatefulSet yaml and reapply.

Kubernetes Scan Engine AWS environment

Amazon Elastic Kubernetes Service (EKS) is a managed Kubernetes service that is used to deploy and operate containerized applications at scale using Amazon infrastructure. EKS is beneficial when working with Kubernetes as it manages many underlying components for you.

Set up cluster IAM role

This is the entry point for your cluster. You cannot create a cluster without this. Follow the AWS guide outlining how to create the IAM role. However, be sure to modify the permissions to include the same EKS permissions of the Nexpose target cluster. This ensures that the cluster has access to the AWS resources that it interacts with.

Create the cluster

You can create the cluster either on the AWS Console or the CLI. Refer to the AWS Guide for instructions. Ensure that the role has the ingress and egress roles required for asset access, otherwise you may not be able to scan everything you want to.

Create the Nodegroup IAM role

The nodegroup needs access permissions for the control plane to interact with it along with AWS. This is the simplest way to scale nodes for the cluster. It is recommended that you use the built-in AWS fargate to create the nodes. Refer to the AWS Guide for instructions. When creating nodes, be sure that they meet the minimum requirements to run the Containerized Scan Engine. Note that resources are shared between containers in the pod on nodes, so ensure that you scale the node requirements accordingly.

Create a volume

Volume needs to be allocated prior to mounting. Mount points require a PersistentVolumeClaim and a PersistentVolume. These abstraction layers allow for flexible mounting. Refer to the AWS Guide for more on EKS persistent storage. It is recommended that you use the CSI standard to retain flexibility. In the AWS examples EBS volumes are used to retain state. In order for the cluster to communicate with Amazon EBS, the EBS CSI driver is required.

Kubernetes Scan Engine GCP environment

The Google Kubernetes Engine (GKE) is a managed Kubernetes service that is used to deploy and operate containerized applications at scale using the Google infrastructure. GKE is beneficial when working with Kubernetes as it manages many underlying components (eg. control plane, nodes).

Prerequisites

Before you begin:

Create your Google Cloud project.
Ensure billing is enabled.
Enable the Artifact Registry and Google Kubernetes Engine APIs.
Create a VPC Network that will be used with the cluster you create.

Launch the Cloud Shell

The following solution uses the Cloud Shell provided on the Google Cloud platform. It is a shell environment that comes preinstalled with the Google Cloud cli as well as the kubectl command line. For more information about the Cloud Shell on Google Cloud.

Navigate to the Google Cloud console.
Click the Activate Cloud Shell button.
Before beginning the set-up of Kubernetes, ensure that you are in the correct project by running this command in the Cloud Shell:


gcloud config set project <PROJECT_ID>

Cluster Configuration

When creating a cluster in GKE there are one of two modes of operation and main cluster configuration choices - Standard and Autopilot. The method selected cannot be changed after the cluster is created. In order to make an informed decision it is necessary to understand the level of flexibility, responsibility and control that is required for the cluster. Refer to the official documentation on Cluster Configuration to make an informed decision when creating clusters.

Autopilot

GKE Autopilot is a mode of operation that ensures management of the cluster configuration is completed by Google. These configurations include nodes, scaling, security, and more.

Create an auto cluster:


gcloud container clusters create-auto <cluster-name> --location=<region> --network=<network-name>

If the network is excluded from the command it will be set to default instead.

Make authentications interact with the cluster:


gcloud container clusters get-credentials <cluster-name> --location <region>

Standard

Creating the cluster using the standard method allows for the choice of either a regional or zonal cluster. For more information, refer to Google’s About Regional Clusters and Creating Zonal Clusters documentation. For specifics on the requirements needed for the cluster to deploy the Containerized Scan Engine successfully, refer to the base requirements .

Create the cluster using GCP’s Create Kubernetes Engine.
After the cluster is created, navigate to the Cloud Shell.
Make authentications interact with the cluster:


gcloud container clusters get-credentials <cluster-name> --location <region>

Frequently Asked Questions

Why is the Containerized Scan Engine run as root?

The Containerized Scan Engine is running as root as this is required in order to perform some checks. The Containerized Scan Engine is able to run without root but this will skip some checks. For steps on how to mitigate risk, refer to Running in Rootless Mode and Linux Post-Installation Steps for Docker Engine which have been outlined by Docker.

How to connect the Containerized Scan Engine to the Security Console on a non-default port?

To connect the Containerized Scan Engine to the Security Console on a non-default port, use the CONNECT_TO_PORT environment variable when starting up the container. This port must be exposed as it replaces the existing listening port number in the nsc.xml file.

For example, run this Docker command while mapping the TCP port:

docker run --env CONNECT_TO_ADDRESS=127.0.0.1 CONNECT_TO_PORT=00000 --env CONNECT_TO_SHARED_SECRET=<shared-secret> rapid7/insightvm_scan_engine:latest

Refer to Container Networking for more information.

Troubleshooting

Confirm which address is needed to connect for “CONNECT_TO_ADDRESS”

List the Docker networks using docker network and ls.
Inspect the bridge network using docker inspect bridge.
Connect with the address listed under Gateway.

Configure log levels

Log levels can be changed using the docker exec command or using mount points.

Configure log levels using docker exec

This approach allows you to change log levels by opening the Containerized Scan Engine and manually changing the logging.xml file.

Run the container.
- docker run --env CONNECT_TO_ADDRESS=<address> --env CONNECT_TO_SHARED_SECRET=<shared_secret> rapid7/insightvm_scan_engine:latest
Navigate to a new terminal window and copy the container ID.
- docker ps
In another terminal window run these commands in order to run vi editor inside the Docker container:
- docker exec -it <container_id> sh -c "apt-get update && apt-get install -y vim"
- docker exec -it <container_id> sh -c "apt list --installed | grep vim"
Run the following docker exec command to open the Docker container’s interactive shell:
- docker exec -it <container_id> sh
Navigate to the conf directory in the container.
- cd /opt/rapid7/nexpose/nse/conf
Change the log level in the logging.xml file. The container logs will now output the logs at the level you want.
- vim logging.xml
To exit the interactive shell without interrupting the container’s process, enter Ctr + P > Ctr + Q.