Page Comparison

...

• The container must be able to perform DNS lookups of, and be able to connect to, the APIs that will be scanned. For simple deployments, if the host system for a container can resolve hostnames in the private network, so can the container.

• The container must be able to resolve and connect to private-network-proxy1.securetheorem.com, on port 20422 to set up the tunnel/port forwarding.

• The container must be configured with an SSH private key and a port assigned to the connector by Data Theorem. The sections below discuss coordinating this configuration with Data Theorem.

• A particular instance’s container should only exist once – it should not be scaled or replicated across a cluster (eg, Docker Swarm or Kubernetes). A deployed container represents where network traffic from Data Theorem will originate within the private network.

• If you have multiple isolated private networks where there you have APIs to scan, then each network will need its own Private Network Proxy configured with Data Theorem.

• The container currently logs all output to STDOUT and STDERR.

• The container should have 2 vCPUs, 2GB memory, and 2GB disk

The container image is available at: gcr.io/datatheorem-public-images/private-network-proxy-client-v1

...

The following ENV variables should not be explicitly set unless you want to change the behavior of the container.

• RETRYWORKSPACE_AFTER_DISCONNECT – Whether the container should automatically reconnect if something happens to the connection to the server. Defaults to yes. If it is set to no the container will exit if SSH ever disconnects.VERBOSITY – DIR – Specify a directory where dynamically generated files will be written to. The SSH private key and other files will be created/copied here. It defaults to /app, but you can set it to /dev/shm (if available) or to your own tmpfs mount if you want the container itself to write files to ephemeral storage.

• RETRY_AFTER_DISCONNECT – Whether the container should automatically reconnect if something happens to the connection to the server. Defaults to yes. If it is set to no the container will exit if SSH ever disconnects instead of reconnecting automatically.

• VERBOSITY – How verbose the container’s output is. Defaults to 1. Set this to 0 for almost no output, or 1, 2, or 3 for increasingly verbose levels of output. Only set it to a higher level if you need to do some sort of low-level debugging of the SSH connection.

• SERVER_HOST – Override the host that the container tries to connect to. By default, the container connects to private-network-proxy1.securetheorem.com.

• SERVER_PORT – Override the server port that the container tries to connect to. By default, the container initiates an SSH connection to port 20422 on the remote server.

• SERVER_PUBKEY – Override the public key of the remote server. The image contains the remote server’s key already, and it will refuse to connect to other server keys. Setting this overrides the server key that it trusts.

...

PRIVATE_KEY_FILE="/path/to/private_key"
PROXY_PORT=10123

# Replace newline characters with a \n character sequence:
PRIVATE_KEY_DATA=`cat ${PRIVATE_KEY_FILE}| while read line ; do echo -n "${line}\\n" ; done`

docker run -it \
    -e "PROXY_PORT=${PROXY_PORT}" \
    -e "SSH_PRIVATE_KEY_DATA=${PRIVATE_KEY_DATA}" \
    gcr.io/datatheorem-public-images/-e "WORKSPACE_DIR=/dev/shm" \
    gcr.io/datatheorem-public-images/private-network-proxy-client-v1:latest

...

PRIVATE_KEY_FILE="/path/to/private_key"
PROXY_PORT=10123

# bind-mount the private key into the container. The private key file must be
# readable by the low-rights user within the container -- the service within the
# container does not run as root. Eg, you may have to chmod the private key file,
# or grant access to the container-user's group/gid from on the host system.
docker run -it \
    -e "PROXY_PORT=${PROXY_PORT}" \
    -e "SSH_PRIVATE_KEY_FILE=/private_key" \
    --mount "type=bind,src=${PRIVATE_KEY_FILE},dst=/private_key,readonly=true" \
    -e "WORKSPACE_DIR=/dev/shm" \
    gcr.io/datatheorem-public-images/private-network-proxy-client-v1:latest

...

PROXY_PORT=10123
SSH_PRIVATE_KEY_DATA=-----BEGIN OPENSSH PRIVATE_KEY-----\n...\n-----END OPENSSH PRIVATE KEY-----
WORKSPACE_DIR=/dev/shm

Then create the VM using GCP’s gcloud command line tool:

...

• The Docker image is based on Alpine Linux, which is known for having a significantly smaller footprint compared to other popular distributions. It also relies on Linux hardening features like PIE, and it uses MUSL as its libc instead of GNU’s libc.

• The service that runs in the container does not run as root. The Docker image runs commands as a normal, non-root user, minimizing what code running in the container can modify, and minimizing concerns about root processes running within containers.

• The SSH client is configured to only trust a specific server key, instead of the default of prompting or auto-trusting new keys for a new host (via a UserKnownHostsFile and the StrictHostKeyChecking option). The trusted server key can be overridden using the SERVER_PUBKEY ENV variable.

• The private key used by the client currently must not be encrypted with a password. However, it must also be written to a filesystem for SSH to use it. If you want to ensure that the container itself doesn’t write the key to some kind of persistent storage, you can set point WORKSPACE_DIR to some sort of ephemeral storage. Docker usually provides a /dev/shm shared memory filesystem, but you could also point it to your own tmpfs mount as well.

Server Security

The server component is also run in a container in a VM on GCP.

...