How to harden security for VSatellite¶

VSatellite is security-critical software that requires loading and processing secrets in memory at runtime. This guide will help you apply security hardening techniques to improve the security of VSatellite.

Prerequisites¶

• Access to a Unix-based system
• Sudo privileges

Step 1: Disable core dumps system-wide¶

Core dumps can be produced when a process crashes unexpectedly on a Unix system. While useful for debugging, they include the current state of memory, which can result in secret data being written to disk unencrypted. Disabling core dumps enhances security by preventing this.

1. Open a terminal.

2. Run the following command to disable core dumps:

   echo "kernel.core_pattern=|/bin/false" | sudo tee /etc/sysctl.d/50-coredump.conf
   sudo sysctl -p /etc/sysctl.d/50-coredump.conf
   

   • The kernel.core_pattern sysctl specifies how to name core dumps when they're created. If the pattern starts with a pipe (|) character, core dumps will be passed into a given program.
   • This pattern writes all core dumps to /bin/false, effectively ignoring them.
   • The first command creates a new file to ensure the sysctl is set correctly on boot.
   • The second command uses the sysctl command to apply the new pattern immediately.

Step 2: Avoid setting GOTRACEBACK in production¶

Much of the code in a VSatellite installation is written in Go. Go will not generally perform a core dump on a crash unless the GOTRACEBACK environment variable is set to crash. For added security, avoid setting GOTRACEBACK in any production environment.

Step 3: Secure the cluster credentials file¶

Only root users and members of the root group should have access to the VSatellite cluster credentials file, because a user with these credentials can connect to the VSatellite cluster and read all the Secret resources.

Among other things, the Secret resources contain the Data Encryption Key (DEK).

The credentials for the VSatellite cluster administrator are in: /etc/rancher/k3s/k3s.yaml. The file should be owned by root:root and the permissions (also known as the "mode") should be: 640 (owner: ReadWrite, group: ReadOnly).

To check the permissions, run:

ls -l /etc/rancher/k3s/k3s.yaml

Expected output:

-rw-r----- 1 root root 2957 Jun 1 09:00 /etc/rancher/k3s/k3s.yaml

-rw-r--r-- 1 root root 2957 Jun 1 09:00 /etc/rancher/k3s/k3s.yaml

K3S_KUBECONFIG_MODE='640'

# Add the recommended configuration
echo "K3S_KUBECONFIG_MODE='640'" | sudo tee /etc/systemd/system/k3s.service.env

# Restart the VSatellite cluster service
sudo systemctl restart k3s