Certification Exams of Oracle Docker Compose with Podman Initialization scripts Managing stacks with pods Oracle and Linux Oracle Certifications Removing packages via AppStream Working directory

Setting up LUKS 2 – Keeping the Data Safe – Securing a System

We can now look at the LUKS key slots. You should see the key in the second slot now.
As seen in the following screenshot, slot 1: is populated with a key:

Figure 9.7 – LUKS with the second slot used

  1. Next, we need to configure the disk to decrypt the drive on boot. We first need to pull the new UUID of the encrypted drive:

[root
@clevis ~]# blkid -s UUID /dev/sdb

/dev/sdb: UUID=”218ec8bc-2508-4e34-a569-1e8d3783874e”

  1. Next, let’s enable the Clevis service:

systemctl enable clevis-luks-askpass.path

  1. Now, we need to add the device to the /etc/crypttab file. The crypttab file contains a list of all encrypted drives:

echo “encrypteddisk UUID=218ec8bc-2508-4e34-a569-1e8d3783874e – _netdev” | sudo tee -a /etc/crypttab

  1. Next, we will update the /etc/fstab file for the filesystem, changing the default to _netdev. This will allow the device to mount after the other non-encrypted filesystems.
  2. The /etc/fstab should look similar to the following screenshot, with the UUID of the encrypted drive mounting as a _netdev:

Figure 9.8 – fstab


How it works…
Clevis and Tang are both software tools that are used to unlock and decrypt disks automatically during the boot process of a Linux system.
Here is a brief overview of how they work:

  1. During the boot process, the system prompts the user for a passphrase to unlock and decrypt the disk.
  2. With Clevis and Tang, this prompt is replaced with an automated process that unlocks and decrypts the disk using a network-based key server.
  3. Clevis and Tang work together to create a binding between the encrypted disk and the key server. This binding is based on a policy that specifies the conditions under which the disk can be unlocked.
  4. When the system boots up, it contacts the key server and requests the decryption key for the encrypted disk. The key server checks the policy to determine whether the conditions for unlocking the disk have been met.
  5. If the policy conditions are met, the key server sends the decryption key to the system, which then uses it to unlock and decrypt the disk.
  6. If the policy conditions are not met, the key server denies the request for the decryption key, and the disk remains locked.
    There’s more…
    Optionally, you can also modify the system to allow an admin to manually enter the initial password when the system boots. To do this, install clevis-dracut:

dnf install -y clevis-dracut

Then, rebuild the boot files:

dracut -fv

When the system boots, you will have the opportunity to enter the passphrase manually:

Figure 9.9 – Manual passphrase entry
Now you have an encrypted filesystem with an automatic way to decrypt it, as well as a manual method for use in emergencies.

LEAVE A RESPONSE

Your email address will not be published. Required fields are marked *



Powered by keiarra.com