Encryption at rest for Instances

Ensuring the security of sensitive information is a top priority for any organization, particularly when it involves storing data on a server. In this regard, implementing encryption at rest for partitions containing application data can serve as a highly effective solution to safeguard valuable data against both external threats and internal breaches.

By combining encryption at rest with a secret manager, organizations can significantly enhance the security of their server-stored data. Encryption at rest provides an additional layer of protection by encrypting data at the storage level, while a secret manager facilitates centralized and secure storage and management of encryption keys.

This article aims to explain the numerous benefits of implementing encryption at rest for partitions housing application data on a server. We will emphasize the critical role played by a secret manager in effectively managing encryption keys. We will guide you through the process of implementing this solution on a server and how to seamlessly integrate it within an application environment.

How to protect your files on Instances

To ensure that no unauthorized agents can access your files, it is crucial to have a clear understanding of your specific threat model. In this scenario, our primary objectives are to safeguard your data and mitigate potential risks, such as:

a. Protecting data against theft or loss.
b. Ensuring compliance with security rules.
c. Minimizing the risk of sensitive data disclosure.

Securing your data with encryption can be a daunting task, particularly when you lack built-in tools and resources. However, this article aims to showcase a straightforward approach to encrypting your data disk with minimal hassle. In this guide, we will walk you through the process of encrypting a data volume on an instance using Luks, ensuring your data remains protected. To enhance security further, we will securely store the encryption key in the Scaleway Secret Manager. By following these steps, you can establish a robust encryption solution without unnecessary complications.

Before we start, you'll need to understand how to create your Access Key, which we covered in our Eight essentials to make your account's security a priority article.

We need an instance and a data drive attached to it. We will encrypt this disk, not the boot one. We will also need a secret. For this hands-on demonstration, we will use the Scaleway CLI and some shell command lines.

The secret part

Generate your Secret

For optimal secret management that aligns with your organization's security standards, it is advisable to consult your CISO first. They can provide valuable insights and guidance on creating a secret solution tailored to your specific requirements.
There are multiple ways to generate a secret; here are some examples:

Generate a key using openssl

openssl rand -base64 32
dd bs=32 count=1 if=/dev/random > keyfile
Copy code

Use a password generator

curl -s --request POST   --url https://vspg.tools.sa-scw.fr/v1/password   --header 'content-type: application/json'   --data '{
"number_of_words":"6",
"number_of_numbers":"14",
"separator":"0",
"language":"fr"
}' | jq ".result" -r > keyfile
Copy code

Send the secret to the secret manager

To make your life simpler (and mine), I will use the name “encypted_drive” but you can use the disk ID as a Secret name, this will help you to automate the process.

% scw secret secret create name=encypted_drive
ID            8a55eea4-e989-4138-88a6-1c1457931702
ProjectID     f04db921-03a2-48b3-99f0-105110e77db6
Name          ba02dae4-a149-4e86-bea1-e30ae32993de
Status        ready
CreatedAt     now
UpdatedAt     now
Region        fr-par
VersionCount  0
Description   -
Copy code

Then, add a new version of the secret that contains the secret generated in the first step.

% scw secret version create secret-id=8a55eea4-e989-4138-88a6-1c1457931702 data="$(cat keyfile)"              
SecretID     8a55eea4-e989-4138-88a6-1c1457931702
Revision     1
Status       enabled
CreatedAt    now
UpdatedAt    now
Description  -
Copy code

The base64 version of the secret is now stored securely in the secret manager. Let’s check it using the API

% curl -s --request GET \
  --url 'https://api.scaleway.com/secret-manager/v1alpha1/regions/fr-par/secrets/8a55eea4-e989-4138-88a6-1c1457931702/versions/latest/access' \
  --header 'X-Auth-Token: 19b78691-35fb-40b6-b51f-658d22a701d7' \
  | jq -r '.data' \
  | base64 -d

UnmysticalnessDubbeltjeBasinasialAustralioidHarquebuseYobboes,7838909742353
Copy code

We now have a secret stored securely and we know how to retrieve it.

Don’t forget to delete the keyfile

Retrieve the secret

Create the script

In order to provide the encryption key to the system, We will create a script that will take care of retrieving the secret. The script will be implemented in Bash for simplicity here. However, feel free to choose any programming language that best suits your specific needs and requirements.

First, we will create the file /etc/luks/data-key.sh

#!/bin/sh
set -e
# Request the secret from Scaleway Secret Manager
curl -s --request GET \
  --url 'https://api.scaleway.com/secret-manager/v1alpha1/regions/fr-par/secrets/8a55eea4-e989-4138-88a6-1c1457931702/versions/latest/access' \
  --header 'X-Auth-Token: 19b78691-35fb-40b6-b51f-658d22a701d7' \
  | jq -r '.data' \
  | base64 -d
Copy code

Ensure the owner of this file is "root"
chown root:root /etc/luks/data-key.sh

Allow only root to read and execute the script
chmod 0500 /etc/luks/data-key.sh

Once again, follow your security best practices.

Let’s encrypt the volume

Install the mandatory packets

Depending of the systeme you are using, the package can be differents

On the CentOS, Fedora, family
yum install -y cryptsetup

On Ubuntu, Debian, …
apt install -y cryptsetup

Find the disk and create the system partition

Using lsblk , we will find the data disk

# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0 0  9.3G  0 disk
├─sda1   8:1    0   1M  0 part
├─sda2   8:2    0 1000M  0 part /boot
├─sda3   8:3    0  100M  0 part /boot/efi
├─sda4   8:4    0   4M  0 part
└─sda5   8:5    0  8.2G  0 part /home
                                /
sdb      8:16   0 39.1G  0 disk
zram0  252:0    0  7.7G  0 disk [SWAP]
Copy code

In this example the data disk is sdb, check carefully on your system, all the data will be whipped once you run the command below.

Let’s create the partition table
parted /dev/sdb mklabel gpt
parted -a opt /dev/sdb mkpart datadisk ext4 0% 100%

Encryption time

And go for the fun part we will secure the sdb1 partition, begin by encrypting it using LUKS. Next, create an ext4 volume within the encrypted partition and then securely close the encrypted volume.

During any commands that require a keyfile, make sure to use the /etc/luks/data-key.sh script that was previously created, and instruct cryptsetup to read the keyfile from stdin.

Don’t forget to replace sdb1 with the correct partition on your system!
/etc/luks/data-key.sh | cryptsetup -d - -v luksFormat /dev/sdb1

Then let’s open the encrypted volume, and use the name "data"
/etc/luks/data-key.sh | cryptsetup -d - -v luksOpen /dev/sdb1 data

Create a filesystem on the encrypted volume
mkfs.ext4 -F /dev/mapper/data

Let’s check the partitions

# lsblk
NAME     MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sda        8:0 0  9.3G  0 disk  
├─sda1     8:1 0   1M  0 part  
├─sda2     8:2 0 1000M  0 part  /boot
├─sda3     8:3 0  100M  0 part  /boot/efi
├─sda4     8:4 0   4M  0 part  
└─sda5     8:5 0  8.2G  0 part  /home
                                   /
sdb        8:16   0 39.1G  0 disk  
└─sdb1     8:17   0 39.1G  0 part  
  └─data 253:0    0 39.1G  0 crypt
zram0    252:0   0  7.7G  0 disk  [SWAP]
Copy code

And close the encrypted volume
cryptsetup -v luksClose data

Automate the decryption of the volume

We have now a successfully encrypted data volume that lives in sdb1.
It’s time to make it useful, by automatically un-encrypting and mounting it at the start of the server.

Found the disk UUID

We continue to use lsblk to find the volume uuid of sdb1

#lsblk --fs
sdb                                                                   └─sdb1 crypto_LUKS 2  fc916938-a5c4-4128-a4a4-1b108b066297                
Copy code

In this example the UUID of sbd1 is fc916938-a5c4-4128-a4a4-1b108b066297.

Create the systemD script

To establish a systemD unit that unlocks the encrypted device, save it as /etc/systemd/system/unlock-data-volume.service. Be sure to modify the UUID in the command provided below to match the correct one for your device.
In this example the UUID of sbd1 is fc916938-a5c4-4128-a4a4-1b108b066297.

[Unit]
Description=Open encrypted volume data
After=network-online.target
Wants=network-online.target
StopWhenUnneeded=true


[Service]
Type=oneshot
ExecStart=/bin/sh -c '/etc/luks/data-key.sh | /sbin/cryptsetup -d - -v luksOpen /dev/disk/by-uuid/fc916938-a5c4-4128-a4a4-1b108b066297 data'
RemainAfterExit=true
ExecStop=/sbin/cryptsetup -d - -v luksClose data
Copy code

We also need to create a systemD unit for the mountpoint /mnt/data, save it as /etc/systemd/system/mnt-data.mount.
Keep in mind that the name of the unit must correspond with the path of the mountpoint.

[Unit]
Requires=unlock-data-volume.service
After=unlock-data-volume.service

[Mount]
What=/dev/mapper/data
Where=/mnt/data
Type=ext4
Options=defaults,noatime,_netdev

[Install]
WantedBy=multi-user.target
Copy code

And the last step: enable the systemD unit /etc/systemd/system/mnt-data.mount

systemctl enable mnt-data.mount
systemctl start mnt-data.mount

By running lsblk, you should be able to see the new volume mounted /mnt/data

# lsblk
NAME     MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sda        8:0 0  9.3G  0 disk  
├─sda1     8:1 0   1M  0 part  
├─sda2     8:2 0 1000M  0 part  /boot
├─sda3     8:3 0  100M  0 part  /boot/efi
├─sda4     8:4 0   4M  0 part  
└─sda5     8:5 0  8.2G  0 part  /home
                                   /
sdb        8:16   0 39.1G  0 disk  
└─sdb1     8:17   0 39.1G  0 part  
  └─data 253:0    0 39.1G  0 crypt /mnt/data
zram0    252:0   0  7.7G  0 disk  [SWAP]
Copy code

Now to ensure that everything is working properly, reboot your server and check if your volume is properly decrypted.

What are the limitation

Now that we have provided you with the necessary setup instructions, it is essential to understand the limitations and flow of this implementation.

Firstly, please note that the key required to access your volume is stored in plain text within your boot volume. While it is only accessible by the root user, it is important to consider your specific threat model. Depending on your security requirements, this aspect may present a potential concern.

Additionally, it is important to mention that this approach is not applicable to your root filesystem. To retrieve the encryption key, network access is required. This ensures that the necessary encryption key can be obtained securely through network connectivity.

Being aware of these limitations and implementation considerations will allow you to make informed decisions and take appropriate measures to address any potential security concerns.

Conclusion

In conclusion, implementing data volume encryption in a server using a secret manager is a straightforward endeavor. By harnessing the power of a secret manager, the encryption process becomes seamless and easily manageable.

The secret manager's robust security features greatly simplify encryption key management and guarantee confidentiality of sensitive data. This approach empowers server administrators to effortlessly incorporate data encryption, effectively protecting valuable information with minimal effort.

By embracing encryption with a secret manager, organizations can fortify their data security posture and mitigate potential risks.