Policy-Based Decryption (Lesson 6 transcript from Upgrading to Red Hat Enterprise Linux (RHEL) 8 LiveLessons)
Understanding Policy-Based Decryption
Before we start configuring Policy-Based Decryption let's try to understand what it is about. Policy-Based Decryption, or PBD is a collection of technologies that enable unlocking encrypted root volumes in an automated way, so that you don't have to enter a pass phrase. In PBD, different unlocking methods can be combined. You can use user passwords or Trusted Platform Modules or PKCS#11 devices like smartcard readers or network servers. And a network server is what we are going to focus in this lesson. Different unlocking mechanisms can be combined in one policy, which makes it possible to unlock the same volume in different ways, depending on the availability of your unlocking methods. Policy-Based Decryption has been introduced in RHEL 8 and in order to work with it, you need the Clevis framework. The Clevis framework is using pins. These pins are really plug-in modules and every pin provides a separate unlocking capability.
There is tang, which allows volumes to be unlocked using a network server. And there is tpm2, which allows volumes to be unlocked using a tpm2 policy. And that's the current state of unlocking mechanisms in RHEL 8. There's also this thing called NDBE, now what is NBDE? That is Network Bound Disc Encryption, it's a subcategory of PBD and it allows binding encrypted volumes to a network server. The current implementation includes a Clevis pin for Tang server and the Tang server itself. And that is what I'm going to demonstrate. Before I'm going to demonstrate, let's try to understand Tang. So Tang is a network server that is used for decrypting LUKS devices. And Clevis is the framework that allows for decrypting LUKS volumes and connects the Tang server to do so. And when provisioning NBDE, the Clevis pin for Tang gets a list of Tang server advertised asymmetric keys. Alternatively, a list of Tang public keys can be distributed out-of-band so that clients don't require direct access to the Tang server. In the next video, I will show you have to set this up.
Managing Policy-Based Decryption
Okay let's have a look at the procedure for setting up policy-based decryption. First you need to set up Tang. That's pretty simple. You install the packet, you run the tangd.socket, and you open the firewall, and that's all.
The Clevis setup is a little bit more complicated. To start it, you need to install some packages. And then you need to register the password at the Tang server. One way of doing that is by echoing the password and piping the results to clevis encrypt tang. Followed by the name of the Tang server that you are using. Next you can test the connectivity with the Tang server. That will be something like curl-f http tangserver.example.com/adv. Which will show you the encrypted passphrase, basically. Then you use clevis luks bind -d followed by the name of your device. Tang followed by the URL to the Tang server, and that'll bind the device. But binding doesn't mean that it's unlocked. That's something we do later. At this point you can use systemctl enable clevis-luks-askpass.path, and if you are using LUKS on an encrypted root volume, you can use dracut -f. And next, you can use clevis luks unlock -d on dev nvme01n1p5 to unlock the device. Check for the availability in the device or in the dev map or directory and reboot to verify that all is working alright. Let me show you.
Okay, to start, you need to make sure that you can reach the Tang server by host name. I've already prepared my etc host where I am going to tang.example.com on its IP address. So let's ssh into that server. So that I can show you what should be happening there. So you need to install the Tang package, and you need to verify the availability of the Tang service. So if you use systemctl status on tangd.socket, now we can see that socket is active and listening. Let's also use firewall cmd -- list all to verify that port 80 tcp is open, and that's exactly what we need, and that's all as far as the Tang server is considered. And now we need to install packages on the client server. The client server is the server that is running the LUKS encrypted devices. So you use yum install clevis clevis luks and clevis dracut to install all of the packages that are required. Already installed, that's even better.
Now the most important part is that we make the password known to the Tang server. So as you can see, I'm using a very secret password and I'm sending that to the Clevis command, which is using clevis encrypt tang, followed by the Tang URL. So the advertisement contains the following signing keys. Do you want to trust these keys? Of course I want to trust them. Now we can test the connectivity with the Tang server. So curl -f on http://tang.example.com/adv, for advertisement, and you can see the payload that is getting back. So far so good. As we have reached this point, we can now use clevis luks bind -d on dev nvme0n2, and we need to bind with Tang. Which again, is going to use the URL. And there we can see the same advertisement again, and do we want to trust this key? Yes we want. So now the LUKS volume is known at the Tang server. So we can use systemctl enable clevis luks askpass.path. That will make sure that after a reboot, it's going to happen automatically. If you would be using LUKS encrypted to root volume, you need direct root -f. I'm not using LUKS encrypted root volume. I'm only using a normal root volume. So I can easily test it using clevis luks unlock -d on dev nvme0n2. And that is going to unlock the device for me. And to verify that the device is available, we can do an ls on dev mapper, and look, the device has been mounted, and that's all. If you want to, you can reboot to verify that the procedure is working alright and fine tune if you want to.