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 ValueDescriptionExample
latestThe most recent product and content release version available.latest
product versionThe product release version.6.6.188
product and content versionThe 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 pointDescription
/opt/rapid7/nexpose/nse/scansThe 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/confThe 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/keystoresThe 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/logsThe 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 VariableDescription
CONNECT_TO_ADDRESSThis is the IP address where the Security Console will wait for connections from the Containerized Scan Engine.
CONNECT_TO_SHARED_SECRETIf 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_PORTThis listening port can be manually configured and requires exposure as it replaces the existing listening port number in the nsc.xml file.
ACCEPT_FROM_ADDRESSThis IP address will be used by the Security Console to connect to the Containerized Scan Engine.
ACCEPT_FROM_SHARED_SECRETIf 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:

CommandDescription
docker pull rapid7/insightvm_scan_engine:latestPulls the latest image
docker run --env CONNECT_TO_SHARED_SECRET=<SHARED_SECRET> --env CONNECT_TO_ADDRESS=<CONSOLE_ADDRESS> rapid7/insightvm_scan_engine:latestStarts 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:latestStarts 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:latestStarts 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
 
1
version: "3"
2
services:
3
  nse-1:
4
    image: rapid7/insightvm_scan_engine
5
    volumes:
6
      - /var/docker/nse-1/data/rapid7/nexpose/nse/conf:/opt/rapid7/nexpose/nse/conf
7
      - /var/docker/nse-1/data/rapid7/nexpose/nse/keystores:/opt/rapid7/nexpose/nse/keystores
8
      - /var/docker/nse-1/data/rapid7/nexpose/nse/logs:/opt/rapid7/nexpose/nse/logs
9
      - /var/docker/nse-1/data/rapid7/nexpose/nse/scans:/opt/rapid7/nexpose/nse/scans
10
    environment:
11
      - CONNECT_TO_ADDRESS=<CONSOLE_ADDRESS>
12
      - CONNECT_TO_SHARED_SECRET=<SHARED_SECRET>
Run a single container with accepting connections from the Security Console
 
1
version: "3"
2
services:
3
  nse-1:
4
    image: rapid7/insightvm_scan_engine
5
    ports:
6
      - "40814:40814"
7
    volumes:
8
      - /var/docker/nse-1/data/rapid7/nexpose/nse/conf:/opt/rapid7/nexpose/nse/conf
9
      - /var/docker/nse-1/data/rapid7/nexpose/nse/keystores:/opt/rapid7/nexpose/nse/keystores
10
      - /var/docker/nse-1/data/rapid7/nexpose/nse/logs:/opt/rapid7/nexpose/nse/logs
11
      - /var/docker/nse-1/data/rapid7/nexpose/nse/scans:/opt/rapid7/nexpose/nse/scans
12
    environment:
13
      - ACCEPT_FROM_ADDRESS=<CONSOLE_ADDRESS>
14
      - ACCEPT_FROM_SHARED_SECRET=<SHARED_SECRET>
Run multiple engines connecting to the Security Console
 
1
version: "3"
2
services:
3
  nse-1:
4
    image: rapid7/insightvm_scan_engine
5
    volumes:
6
      - /var/docker/nse-1/data/rapid7/nexpose/nse/conf:/opt/rapid7/nexpose/nse/conf
7
      - /var/docker/nse-1/data/rapid7/nexpose/nse/keystores:/opt/rapid7/nexpose/nse/keystores
8
      - /var/docker/nse-1/data/rapid7/nexpose/nse/logs:/opt/rapid7/nexpose/nse/logs
9
      - /var/docker/nse-1/data/rapid7/nexpose/nse/scans:/opt/rapid7/nexpose/nse/scans
10
    environment:
11
      - CONNECT_TO_ADDRESS=<CONSOLE_ADDRESS>
12
      - CONNECT_TO_SHARED_SECRET=<SHARED_SECRET>
13
  nse-2:
14
    image: rapid7/insightvm_scan_engine
15
    volumes:
16
      - /var/docker/nse-2/rapid7/nexpose/nse/conf:/opt/rapid7/nexpose/nse/conf
17
      - /var/docker/nse-2/rapid7/nexpose/nse/keystores:/opt/rapid7/nexpose/nse/keystores
18
      - /var/docker/nse-2/rapid7/nexpose/nse/logs:/opt/rapid7/nexpose/nse/logs
19
      - /var/docker/nse-2/rapid7/nexpose/nse/scans:/opt/rapid7/nexpose/nse/scans
20
    environment:
21
      - CONNECT_TO_ADDRESS=<CONSOLE_ADDRESS>
22
      - CONNECT_TO_SHARED_SECRET=<SHARED_SECRET>
23
  nse-3:
24
    image: rapid7/insightvm_scan_engine
25
    volumes:
26
      - /var/docker/nse-3/rapid7/nexpose/nse/conf:/opt/rapid7/nexpose/nse/conf
27
      - /var/docker/nse-3/rapid7/nexpose/nse/keystores:/opt/rapid7/nexpose/nse/keystores
28
      - /var/docker/nse-3/rapid7/nexpose/nse/logs:/opt/rapid7/nexpose/nse/logs
29
      - /var/docker/nse-3/rapid7/nexpose/nse/scans:/opt/rapid7/nexpose/nse/scans
30
    environment:
31
      - CONNECT_TO_ADDRESS=<CONSOLE_ADDRESS>
32
      - 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:

  1. Run the container: docker run --name first_engine rapid7/insightvm_scan_engine:latest.
  2. 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​

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:

yaml
1
apiVersion: v1
2
kind: PersistentVolume
3
metadata:
4
  name: ebs-pv
5
spec:
6
  capacity:
7
    storage: 5Gi
8
  volumeMode: Filesystem
9
  accessModes:
10
    - ReadWriteOnce # meaning this PV can only be claimed once in read-write mode by one Pod
11
  storageClassName: ""
12
  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
13
  csi:
14
    driver: <driver in this example it is ebs.csi.aws.com>
15
    volumeHandle: <reference to volume vol-08a88cac24536707e>
yaml
1
apiVersion: v1
2
kind: PersistentVolumeClaim
3
metadata:
4
  name: ebs-claim
5
spec:
6
  accessModes:
7
    - ReadWriteOnce
8
  storageClassName: ""
9
  resources:
10
    requests:
11
      storage: 5Gi
yaml
1
kubectl apply -f ./pvc.yaml
2
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.

yaml
1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: scan-engine
5
spec:
6
  selector:
7
    matchLabels:
8
      app: scan-engine
9
  template:
10
    metadata:
11
      labels:
12
        app: scan-engine
13
    spec:
14
      containers:
15
        - name: scan-engine
16
          image: rapid7/insightvm_scan_engine:latest
17
          volumeMounts:
18
          - name: persistent-storage
19
            mountPath: /opt/rapid7/nexpose/nse/conf
20
            subPath: engine1/conf
21
          - name: persistent-storage
22
            mountPath: /opt/rapid7/nexpose/nse/keystores
23
            subPath: engine1/keystores
24
          env:
25
          - name: CONNECT_TO_ADDRESS
26
            value: <ip-address>
27
          - name: CONNECT_TO_SHARED_SECRET
28
            value: <shared secret>
29
          ports:
30
          - containerPort: 40814
31
      volumes:
32
      - name: persistent-storage
33
        persistentVolumeClaim:
34
          claimName: ebs-claim
yaml
1
kubectl apply -f ./scan-engine-deployment.yaml
Step 3: Create a Service

This exposes the service to accept connections from consoles:

yaml
1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: scan-engine
5
  labels:
6
    app: scan-engine
7
spec:
8
  ports:
9
    - port: 40814
10
      targetPort: 40814
11
      protocol: TCP
12
  selector:
13
    app: scan-engine
yaml
1
kubectl apply -f ./scan-engine-service.yaml
Step 4: (Optional) Update the Scan Engine​
​

Manually update the Scan Engine:

yaml
1
kubectl rollout restart deployment/scan-engine
Standard pairing​

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:

yaml
1
kubectl get node <node name> -o jsonpath="{.spec}"
yaml
1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: scan-engine
5
spec:
6
  selector:
7
    matchLabels:
8
      app: scan-engine
9
  template:
10
    metadata:
11
      labels:
12
       app: scan-engine
13
    spec:
14
      containers:
15
      - name: scan-engine
16
        image: rapid7/insightvm_scan_engine:latest
17
        ports:
18
        - containerPort: 40814
19
        volumeMounts:
20
          - name: persistent-storage
21
            mountPath: /opt/rapid7/nexpose/nse/conf
22
            subPath: engine1/conf
23
          - name: persistent-storage
24
            mountPath: /opt/rapid7/nexpose/nse/keystores
25
            subPath: engine1/keystores
26
        env:
27
        - name: ACCEPT_FROM_ADDRESS
28
          value: <Node Internal IP Address>
29
      volumes:
30
      - name: persistent-storage
31
        persistentVolumeClaim:
32
          claimName: ebs-claim
yaml
1
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.

yaml
1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: scan-engine
5
  labels:
6
    app: scan-engine
7
spec:
8
  type: NodePort
9
  ports:
10
    - port: 40814
11
      targetPort: 40814
12
      protocol: TCP
13
      nodePort: 30001
14
  selector:
15
    app: scan-engine
yaml
1
kubectl apply -f ./scan-engine-service.yaml
Deploy and manage containers with Kubernetes StatefulSets

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:

yaml
1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: scan-engine-group-srv
5
  labels:
6
    app: scan-engine-group-srv
7
spec:
8
  ports:
9
  - port: 80
10
    name: scan-engine-group-web
11
  selector:
12
    app: scan-engine-group
13


14
apiVersion: apps/v1
15
kind: StatefulSet
16
metadata:
17
  name: scan-engine-group
18
spec:
19
  selector:
20
    matchLabels:
21
      app: scan-engine-group # has to match .spec.template.metadata.labels
22
  serviceName: "scan-engine-group"
23
  replicas: 3
24
  template:
25
    metadata:
26
      labels:
27
        app: scan-engine-group # has to match .spec.selector.matchLabels
28
    spec:
29
      containers:
30
      - name: scan-engine-container
31
        image: rapid7/insightvm_scan_engine:latest
32
        ports:
33
        - containerPort: 40814
34
        env:
35
          - name: CONNECT_TO_SHARED_SECRET
36
            value: <CONNECT_TO_SHARED_SECRET>
37
          - name: CONNECT_TO_ADDRESS
38
            value: <CONNECT_TO_ADDRESS>
39
        volumeMounts:
40
        - name: ajing-cluster-volume
41
          mountPath: /opt/rapid7/nexpose/nse/conf
42
          subPath: scan-engine-group/conf
43
        - name: ajing-cluster-volume
44
          mountPath: /opt/rapid7/nexpose/nse/keystores
45
          subPath: scan-engine-group/keystores
46
  volumeClaimTemplates:
47
  - metadata:
48
      name: ajing-cluster-volume
49
    spec:
50
      accessModes: [ "ReadWriteOnce" ]
51
      storageClassName: "standard"
52
      resources:
53
        requests:
54
          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.

yaml
1
kubectl apply -f scan-engine-statefulset.yaml
yaml
1
kubectl get pods NAME                  READY   STATUS    RESTARTS   AGE
2
scan-engine-group-0   1/1     Running   0          6m8s
3
scan-engine-group-1   1/1     Running   0          5m38s
4
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:

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

yaml
1
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:

  1. Create your Google Cloud project.
  2. Ensure billing is enabled.
  3. Enable the Artifact Registry and Google Kubernetes Engine APIs.
  4. 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.

  1. Navigate to the Google Cloud console.
  2. Click the Activate Cloud Shell button.
  3. Before beginning the set-up of Kubernetes, ensure that you are in the correct project by running this command in the Cloud Shell:
yaml
1
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.

  1. Create an auto cluster:
 
1
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.

  1. Make authentications interact with the cluster:
 
1
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.

  1. Create the cluster using GCP's Create Kubernetes Engine.
  2. After the cluster is created, navigate to the Cloud Shell.
  3. Make authentications interact with the cluster:
 
1
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"
  1. List the Docker networks using docker network and ls.
  2. Inspect the bridge network using docker inspect bridge.
  3. 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.

  1. Run the container.
    • docker run --env CONNECT_TO_ADDRESS=<address> --env CONNECT_TO_SHARED_SECRET=<shared_secret> rapid7/insightvm_scan_engine:latest
  2. Navigate to a new terminal window and copy the container ID.
    • docker ps
  3. 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"
  4. Run the following docker exec command to open the Docker container's interactive shell:
    • docker exec -it <container_id> sh
  5. Navigate to the conf directory in the container.
    • cd /opt/rapid7/nexpose/nse/conf
  6. 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
  7. To exit the interactive shell without interrupting the container's process, enter Ctr + P > Ctr + Q.