How to Harden Security for VSatellite
Table of Contents
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.
- Open a terminal.
- 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.
Tip (Defense in depth): Setting GOTRACEBACK to crash should be avoided in production to prevent core dumps, which can contain sensitive data.
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
Warning!
Older versions of vsatctl allow non-root users to access /etc/rancher/k3s/k3s.yaml.
If you installed your VSatellite cluster before 1 July 2024 (using vsatctl < v1.0.56) you may find that the file permissions on /etc/rancher/k3s/k3s.yaml are too permissive.
You will see the following output if you run ls -l /etc/rancher/k3s/k3s.yaml:
-rw-r--r-- 1 root root 2957 Jun 1 09:00 /etc/rancher/k3s/k3s.yaml
The file is managed by the k3s service so to modify the ownership and permissions you must change the k3s configuration file: /etc/system/k3s.service.env.
That file should contain the following line:
K3S_KUBECONFIG_MODE='640'
Run the following commands to update that file and then restart the VSatellite cluster:
# 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
