How to Gather Support Incident Information (Sensor 4.6.0+)

In Capsule8 sensors version 4.6.0 and above, a running sensor's monitoring subsystem can be used to export a full capture of support information collected from the host, the sensor's configuration, and the sensor's internal workings. Earlier sensor versions should instead collect the constituent components individually as specified in How to Gather Support Incident Information.

Package-based Installations

Installing curl

Accessing the monitoring subsystem requires an HTTP client. Most distributions package curl, which is used in this guide. It can be installed on Red Hat-based systems by running:

sudo yum install curl

It can be installed on Debian-based systems by running:

sudo apt-get install curl

Putting the Sensor in debug mode

Run the following from a root shell on the host in question to cause the sensor to enter debug mode:

sudo pkill -SIGUSR2 capsule8-sensor

This will cause any active sensors running on the system to temporarily enter a debug mode where support and debugging information is available on the monitoring endpoint for 60 seconds. After this time debug mode will revert to being off, since the support endpoint can include sensitive information.

Alternatively, sensors can be put in debug mode permanently by setting debug: true in the capsule8-sensor.yaml file or launching them with the CAPSULE8_DEBUG=true set as an environment variable.

Capturing a support archive

Run the following from a root shell on the host in question to cause the sensor to capture support information and write to a file:

curl -O http://localhost:9010/support.tar && gzip support.tar

This will have the locally running sensor spend 30 seconds gathering host information, sensor configuration, metrics, and profiles on the inner workings of the sensor and then have them written to support.tar.

Kubernetes-based Installations

Finding a pod to connect to

Run the following from a shell to list the capsule8-sensor pods running in your cluster:

kubectl get pods -o wide | grep capsule8-sensor

This lists all capsule8-sensor pods in the cluster and their status. Select a running pod identifier to gather support information on before proceeding.

Shelling into a capsule8-sensor pod

Run the following to launch a shell to the sensor pod in question (replacing $SENSOR_POD with the sensor pod identifier selected earlier):

kubectl exec -it $SENSOR_POD -- /bin/sh

This should have spawned an interactive shell inside the sensor's container and will grant the ability to interact with its monitoring subsystem.

Installing curl

Run the following from your pod shell to install curl:

apk add curl

curl is used later to fetch support information from the running sensor's monitoring endpoint.

Putting the Sensor in debug mode

Run the following from the pod shell to cause the sensor to enter debug mode:

pkill -SIGUSR2 capsule8-sensor

This will cause the sensor running inside the container to temporarily enter a debug mode where support and debugging information is available on the monitoring endpoint for 60 seconds. After this time debug mode will revert to being off, since the support endpoint can include sensitive information.

Alternatively, sensors can be put in debug mode permanently in the daemonset configuration by setting debug: true in the capsule8-sensor.yaml file or launching them with the CAPSULE8_DEBUG=true set as an environment variable.

Capturing a support archive

Run the following from the shell to cause the sensor to capture support information and write to a file inside the container:

curl -O http://localhost:9010/support.tar && gzip support.tar 

This will have the sensor running inside the pod spend 30 seconds gathering host information, sensor configuration, metrics, and profiles on the inner workings of the sensor and then have them written to support.tar. This file can then be copied out of the running container:

exit
kubectl cp $SENSOR_POD:/support.tar support.tar && gzip support.tar

Sending to Capsule8

This file can be sent to your Capsule8 support representative for further analysis over email, Slack, ServiceNow or other mechanisms that are capable of receiving attachments. It will not contain passwords, authentication keys, or data from the host. It does include metadata, kernel, operating system and other configuration information about the system it was captured on, which some may consider sensitive. The contents of the tar archive can be extracted by running the following:

tar -xvzf support.tar.gz