使用 Stratis 的网络绑定磁盘加密
Stratis NBDE
![](/data/attachment/album/202104/27/221704gyzyvyroyyrybany.jpg)


在一个有许多加密磁盘的环境中，解锁所有的磁盘是一项困难的任务。<ruby> 网络绑定磁盘加密 <rt>  Network bound disk encryption </rt></ruby>（NBDE）有助于自动解锁 Stratis 卷的过程。这是在大型环境中的一个关键要求。Stratis 2.1 版本增加了对加密的支持，这在《[Stratis 加密入门](/article-13311-1.html)》一文中介绍过。Stratis 2.3 版本最近在使用加密的 Stratis 池时引入了对网络绑定磁盘加密（NBDE）的支持，这是本文的主题。


[Stratis 网站](https://stratis-storage.github.io/) 将 Stratis 描述为一个“*易于使用的 Linux 本地存储管理*”。短视频《[使用 Stratis 管理存储](https://www.youtube.com/watch?v=CJu3kmY-f5o)》对基础知识进行了快速演示。该视频是在 Red Hat Enterprise Linux 8 系统上录制的，然而，视频中显示的概念也适用于 Fedora Linux 中的 Stratis。


### 先决条件


本文假设你熟悉 Stratis，也熟悉 Stratis 池加密。如果你不熟悉这些主题，请参考这篇 [文章](/article-13311-1.html) 和前面提到的 [Stratis 概述视频](https://www.youtube.com/watch?v=CJu3kmY-f5o)。


NBDE 需要 Stratis 2.3 或更高版本。本文中的例子使用的是 Fedora Linux 34 的预发布版本。Fedora Linux 34 的最终版本将包含 Stratis 2.3。


### 网络绑定磁盘加密（NBDE）概述


加密存储的主要挑战之一是有一个安全的方法在系统重启后再次解锁存储。在大型环境中，手动输入加密口令并不能很好地扩展。NBDE 解决了这一问题，允许以自动方式解锁加密存储。


在更高层次上，NBDE 需要环境中的 Tang 服务器。客户端系统（使用 Clevis Pin）只要能与 Tang 服务器建立网络连接，就可以自动解密存储。如果网络没有连接到 Tang 服务器，则必须手动解密存储。


这背后的想法是，Tang 服务器只能在内部网络上使用，因此，如果加密设备丢失或被盗，它将不再能够访问内部网络连接到 Tang 服务器，因此不会被自动解密。


关于 Tang 和 Clevis 的更多信息，请参见手册页（`man tang`、`man clevis`）、[Tang 的 GitHub 页面](https://github.com/latchset/tang) 和 [Clevis 的 GitHub 页面](https://github.com/latchset/clevis)。


### 设置 Tang 服务器


本例使用另一个 Fedora Linux 系统作为 Tang 服务器，主机名为 `tang-server`。首先安装 `tang` 包。



```
dnf install tang

```

然后用 `systemctl` 启用并启动 `tangd.socket`。



```
systemctl enable tangd.socket --now

```

Tang 使用的是 TCP 80 端口，所以你也需要在防火墙中打开该端口。



```
firewall-cmd --add-port=80/tcp --permanent
firewall-cmd --add-port=80/tcp

```

最后，运行 `tang-show-keys` 来显示输出签名密钥指纹。你以后会需要这个。



```
# tang-show-keys
l3fZGUCmnvKQF_OA6VZF9jf8z2s

```

### 创建加密的 Stratis 池


上一篇关于 Stratis 加密的文章详细介绍了如何设置加密的 Stratis 池，所以本文不会深入介绍。


第一步是捕获一个将用于解密 Stratis 池的密钥。即使使用 NBDE，也需要设置这个，因为在 NBDE 服务器无法到达的情况下，可以用它来手动解锁池。使用以下命令捕获 `pool1` 密钥。



```
# stratis key set --capture-key pool1key
Enter key data followed by the return key:

```

然后我将使用 `/dev/vdb` 设备创建一个加密的 Stratis 池（使用刚才创建的 `pool1key`），命名为 `pool1`。



```
# stratis pool create --key-desc pool1key pool1 /dev/vdb。

```

接下来，在这个 Stratis 池中创建一个名为 `filesystem1` 的文件系统，创建一个挂载点，挂载文件系统，并在其中创建一个测试文件：



```
# stratis filesystem create pool1 filesystem1
# mkdir /filesystem1
# mount /dev/stratis/pool1/filesystem1 /filesystem1
# cd /filesystem1
# echo "this is a test file" > testfile

```

### 将 Stratis 池绑定到 Tang 服务器上


此时，我们已经创建了加密的 Stratis 池，并在池中创建了一个文件系统。下一步是将你的 Stratis 池绑定到刚刚设置的 Tang 服务器上。使用 `stratis pool bind nbde` 命令进行。


当你进行 Tang 绑定时，需要向该命令传递几个参数：


* 池名（在本例中，`pool1`）
* 钥匙描述符名称（本例中为 `pool1key`）
* Tang 服务器名称（在本例中，`http://tang-server`）


记得之前在 Tang 服务器上，运行了 `tang-show-keys`，显示 Tang 输出的签名密钥指纹是 `l3fZGUCmnvKQF_OA6VZF9jf8z2s`。除了前面的参数外，还需要用参数 `-thumbprint l3fZGUCmnvKQF_OA6VZF9jf8z2s` 传递这个指纹，或者用 `-trust-url` 参数跳过对指纹的验证。


使用 `-thumbprint` 参数更安全。例如：



```
# stratis pool bind nbde pool1 pool1key http://tang-server --thumbprint l3fZGUCmnvKQF_OA6VZF9jf8z2s

```

### 用 NBDE 解锁 Stratis 池


接下来重启主机，并验证你可以用 NBDE 解锁 Stratis 池，而不需要使用密钥口令。重启主机后，该池不再可用：



```
# stratis pool list
Name Total Physical Properties

```

要使用 NBDE 解锁池，请运行以下命令：



```
# stratis pool unlock clevis

```

注意，你不需要使用密钥口令。这个命令可以在系统启动时自动运行。


此时，Stratis 池已经可以使用了：



```
# stratis pool list
Name Total Physical Properties
pool1 4.98 GiB / 583.65 MiB / 4.41 GiB ~Ca, Cr

```

你可以挂载文件系统，访问之前创建的文件：



```
# mount /dev/stratis/pool1/filesystem1 /filesystem1/
# cat /filesystem1/testfile
this is a test file

```

### 轮换 Tang 服务器密钥


最好定期轮换 Tang 服务器密钥，并更新 Stratis 客户服务器以使用新的 Tang 密钥。


要生成新的 Tang 密钥，首先登录到 Tang 服务器，查看 `/var/db/tang` 目录的当前状态。然后，运行 `tang-show-keys` 命令：



```
# ls -al /var/db/tang
total 8
drwx------. 1 tang tang 124 Mar 15 15:51 .
drwxr-xr-x. 1 root root 16 Mar 15 15:48 ..
-rw-r--r--. 1 tang tang 361 Mar 15 15:51 hbjJEDXy8G8wynMPqiq8F47nJwo.jwk
-rw-r--r--. 1 tang tang 367 Mar 15 15:51 l3fZGUCmnvKQF_OA6VZF9jf8z2s.jwk
# tang-show-keys
l3fZGUCmnvKQF_OA6VZF9jf8z2s

```

要生成新的密钥，运行 `tangd-keygen` 并将其指向 `/var/db/tang` 目录：



```
# /usr/libexec/tangd-keygen /var/db/tang

```

如果你再看看 `/var/db/tang` 目录，你会看到两个新文件：



```
# ls -al /var/db/tang
total 16
drwx------. 1 tang tang 248 Mar 22 10:41 .
drwxr-xr-x. 1 root root 16 Mar 15 15:48 ..
-rw-r--r--. 1 tang tang 361 Mar 15 15:51 hbjJEDXy8G8wynMPqiq8F47nJwo.jwk
-rw-r--r--. 1 root root 354 Mar 22 10:41 iyG5HcF01zaPjaGY6L_3WaslJ_E.jwk
-rw-r--r--. 1 root root 349 Mar 22 10:41 jHxerkqARY1Ww_H_8YjQVZ5OHao.jwk
-rw-r--r--. 1 tang tang 367 Mar 15 15:51 l3fZGUCmnvKQF_OA6VZF9jf8z2s.jwk

```

如果你运行 `tang-show-keys`，就会显示出 Tang 所公布的密钥：



```
# tang-show-keys
l3fZGUCmnvKQF_OA6VZF9jf8z2s
iyG5HcF01zaPjaGY6L_3WaslJ_E

```

你可以通过将两个原始文件改名为以句号开头的隐藏文件，来防止旧的密钥（以 `l3fZ` 开头）被公布。通过这种方法，旧的密钥将不再被公布，但是它仍然可以被任何没有更新为使用新密钥的现有客户端使用。一旦所有的客户端都更新使用了新密钥，这些旧密钥文件就可以删除了。



```
# cd /var/db/tang
# mv hbjJEDXy8G8wynMPqiq8F47nJwo.jwk   .hbjJEDXy8G8wynMPqiq8F47nJwo.jwk
# mv l3fZGUCmnvKQF_OA6VZF9jf8z2s.jwk   .l3fZGUCmnvKQF_OA6VZF9jf8z2s.jwk

```

此时，如果再运行 `tang-show-keys`，Tang 只公布新钥匙：



```
# tang-show-keys
iyG5HcF01zaPjaGY6L_3WaslJ_E

```

下一步，切换到你的 Stratis 系统并更新它以使用新的 Tang 密钥。当文件系统在线时， Stratis 支持这样做。


首先，解除对池的绑定：



```
# stratis pool unbind pool1

```

接下来，用创建加密池时使用的原始口令设置密钥：



```
# stratis key set --capture-key pool1key
Enter key data followed by the return key:

```

最后，用更新后的密钥指纹将 Stratis 池绑定到 Tang 服务器上：



```
# stratis pool bind nbde pool1 pool1key http://tang-server --thumbprint iyG5HcF01zaPjaGY6L_3WaslJ_E

```

Stratis 系统现在配置为使用更新的 Tang 密钥。一旦使用旧的 Tang 密钥的任何其他客户系统被更新，在 Tang 服务器上的 `/var/db/tang` 目录中被重命名为隐藏文件的两个原始密钥文件就可以被备份和删除了。


### 如果 Tang 服务器不可用怎么办？


接下来，关闭 Tang 服务器，模拟它不可用，然后重启 Stratis 系统。


重启后，Stratis 池又不可用了：



```
# stratis pool list
Name Total Physical Properties

```

如果你试图用 NBDE 解锁，会因为 Tang 服务器不可用而失败：



```
# stratis pool unlock clevis
Execution failed:
An iterative command generated one or more errors: The operation 'unlock' on a resource of type pool failed. The following errors occurred:
Partial action "unlock" failed for pool with UUID 4d62f840f2bb4ec9ab53a44b49da3f48: Cryptsetup error: Failed with error: Error: Command failed: cmd: "clevis" "luks" "unlock" "-d" "/dev/vdb" "-n" "stratis-1-private-42142fedcb4c47cea2e2b873c08fcf63-crypt", exit reason: 1 stdout: stderr: /dev/vdb could not be opened.

```

此时，在 Tang 服务器无法到达的情况下，解锁池的唯一选择就是使用原密钥口令：



```
# stratis key set --capture-key pool1key
Enter key data followed by the return key:

```

然后你可以使用钥匙解锁池：



```
# stratis pool unlock keyring

```

接下来，验证池是否成功解锁：



```
# stratis pool list
Name Total Physical Properties
pool1 4.98 GiB / 583.65 MiB / 4.41 GiB ~Ca, Cr

```



---


via: <https://fedoramagazine.org/network-bound-disk-encryption-with-stratis/>


作者：[briansmith](https://fedoramagazine.org/author/briansmith/) 选题：[lujun9972](https://github.com/lujun9972) 译者：[wxy](https://github.com/wxy) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
In an environment with many encrypted disks, unlocking them all is a difficult task. Network bound disk encryption (NBDE) helps automate the process of unlocking Stratis volumes. This is a critical requirement in large environments. Stratis version 2.1 added support for encryption, which was introduced in the article “[Getting started with Stratis encryption](https://fedoramagazine.org/getting-started-with-stratis-encryption/).” Stratis version 2.3 recently introduced support for Network Bound Disk Encryption (NBDE) when using encrypted Stratis pools, which is the topic of this article.

The [Stratis website](https://stratis-storage.github.io/) describes Stratis as an “*easy to use local storage management for Linux*.” The short video [“Managing Storage With Stratis”](https://www.youtube.com/watch?v=CJu3kmY-f5o) gives a quick demonstration of the basics. The video was recorded on a Red Hat Enterprise Linux 8 system, however, the concepts shown in the video also apply to Stratis in Fedora Linux.

## Prerequisites

This article assumes you are familiar with Stratis, and also Stratis pool encryption. If you aren’t familiar with these topics, refer to this [article](https://fedoramagazine.org/getting-started-with-stratis-encryption/) and the [Stratis overview video](https://www.youtube.com/watch?v=CJu3kmY-f5o) previously mentioned.

NBDE requires Stratis 2.3 or later. The examples in this article use a pre-release version of Fedora Linux 34. The Fedora Linux 34 final release will include Stratis 2.3.

## Overview of network bound disk encryption (NBDE)

One of the main challenges of encrypting storage is having a secure method to unlock the storage again after a system reboot. In large environments, typing in the encryption passphrase manually doesn’t scale well. NBDE addresses this and allows for encrypted storage to be unlocked in an automated manner.

At a high level, NBDE requires a Tang server in the environment. Client systems (using Clevis Pin) can automatically decrypt storage as long as they can establish a network connection to the Tang server. If there is no network connectivity to the Tang server, the storage would have to be decrypted manually.

The idea behind this is that the Tang server would only be available on an internal network, thus if the encrypted device is lost or stolen, it would no longer have access to the internal network to connect to the Tang server, therefore would not be automatically decrypted.

For more information on Tang and Clevis, see the man pages (man tang, man clevis) , the [Tang GitHub page](https://github.com/latchset/tang), and the [Clevis GitHub page](https://github.com/latchset/clevis).

## Setting up the Tang server

This example uses another Fedora Linux system as the Tang server with a hostname of tang-server. Start by installing the tang package:

dnf install tang

Then enable and start the tangd.socket with systemctl:

systemctl enable tangd.socket --now

Tang uses TCP port 80, so you also need to open that in the firewall:

firewall-cmd --add-port=80/tcp --permanent

firewall-cmd --add-port=80/tcp

Finally, run *tang-show-keys* to display the output signing key thumbprint. You’ll need this later.

# tang-show-keys l3fZGUCmnvKQF_OA6VZF9jf8z2s

## Creating the encrypted Stratis Pool

The previous article on Stratis encryption goes over how to setup an encrypted Stratis pool in detail, so this article won’t cover that in depth.

The first step is capturing a key that will be used to decrypt the Stratis pool. Even when using NBDE, you need to set this, as it can be used to manually unlock the pool in the event that the NBDE server is unreachable. Capture the pool1 key with the following command:

# stratis key set --capture-key pool1key Enter key data followed by the return key:

Then I’ll create an encrypted Stratis pool (using the pool1key just created) named pool1 using the */dev/vdb* device:

# stratis pool create --key-desc pool1key pool1 /dev/vdb

Next, create a filesystem in this Stratis pool named filesystem1, create a mount point, mount the filesystem, and create a testfile in it:

# stratis filesystem create pool1 filesystem1 # mkdir /filesystem1 # mount /dev/stratis/pool1/filesystem1 /filesystem1 # cd /filesystem1 # echo "this is a test file" > testfile

## Binding the Stratis pool to the Tang server

At this point, we have the encrypted Stratis pool created, and also have a filesystem created in the pool. The next step is to bind your Stratis pool to the Tang server that you just setup. Do this with the *stratis pool bind nbde* command.

When you make the Tang binding, you need to pass several parameters to the command:

- the pool name (in this example, pool1)
- the key descriptor name (in this example, pool1key)
- the Tang server name (in this example, http://tang-server)

Recall that on the Tang server, you previously ran *tang-show-keys* which showed the Tang output signing key thumbprint is *l3fZGUCmnvKQF_OA6VZF9jf8z2s*. In addition to the previous parameters, you either need to pass this thumbprint with the parameter *–thumbprint l3fZGUCmnvKQF_OA6VZF9jf8z2s*, or skip the verification of the thumbprint with the *–trust-url* parameter. ** **

It is more secure to use the *–thumbprint* parameter. For example:

# stratis pool bind nbde pool1 pool1key http://tang-server --thumbprint l3fZGUCmnvKQF_OA6VZF9jf8z2s

## Unlocking the Stratis Pool with NBDE

Next reboot the host, and validate that you can unlock the Stratis pool with NBDE, without requiring the use of the key passphrase. After rebooting the host, the pool is no longer available:

# stratis pool list

Name Total Physical Properties

To unlock the pool using NBDE, run the following command:

# stratis pool unlock clevis

Note that you did not need to use the key passphrase. This command could be automated to run during the system boot up.

At this point, the pool is now available:

# stratis pool list Name Total Physical Properties pool1 4.98 GiB / 583.65 MiB / 4.41 GiB ~Ca, Cr

You can mount the filesystem and access the file that was previously created:

# mount /dev/stratis/pool1/filesystem1 /filesystem1/ # cat /filesystem1/testfile this is a test file

## Rotating Tang server keys

Best practices recommend that you periodically rotate the Tang server keys and update the Stratis client servers to use the new Tang keys.

To generate new Tang keys, start by logging in to your Tang server and look at the current status of the /var/db/tang directory. Then, run the *tang-show-keys* command:

# ls -al /var/db/tang total 8 drwx------. 1 tang tang 124 Mar 15 15:51 . drwxr-xr-x. 1 root root 16 Mar 15 15:48 .. -rw-r--r--. 1 tang tang 361 Mar 15 15:51 hbjJEDXy8G8wynMPqiq8F47nJwo.jwk -rw-r--r--. 1 tang tang 367 Mar 15 15:51 l3fZGUCmnvKQF_OA6VZF9jf8z2s.jwk # tang-show-keys l3fZGUCmnvKQF_OA6VZF9jf8z2s

To generate new keys, run tangd-keygen and point it to the /var/db/tang directory:

# /usr/libexec/tangd-keygen /var/db/tang

If you look at the /var/db/tang directory again, you will see two new files:

# ls -al /var/db/tang total 16 drwx------. 1 tang tang 248 Mar 22 10:41 . drwxr-xr-x. 1 root root 16 Mar 15 15:48 .. -rw-r--r--. 1 tang tang 361 Mar 15 15:51 hbjJEDXy8G8wynMPqiq8F47nJwo.jwk -rw-r--r--. 1 root root 354 Mar 22 10:41 iyG5HcF01zaPjaGY6L_3WaslJ_E.jwk -rw-r--r--. 1 root root 349 Mar 22 10:41 jHxerkqARY1Ww_H_8YjQVZ5OHao.jwk -rw-r--r--. 1 tang tang 367 Mar 15 15:51 l3fZGUCmnvKQF_OA6VZF9jf8z2s.jwk

And if you run *tang-show-keys*, it will show the keys being advertised by Tang:

# tang-show-keys

l3fZGUCmnvKQF_OA6VZF9jf8z2s

iyG5HcF01zaPjaGY6L_3WaslJ_E

You can prevent the old key (starting with l3fZ) from being advertised by renaming the two original files to be hidden files, starting with a period. With this method, the old key will no longer be advertised, however it will still be usable by any existing clients that haven’t been updated to use the new key. Once all clients have been updated to use the new key, these old key files can be deleted.

# cd /var/db/tang # mv hbjJEDXy8G8wynMPqiq8F47nJwo.jwk .hbjJEDXy8G8wynMPqiq8F47nJwo.jwk # mv l3fZGUCmnvKQF_OA6VZF9jf8z2s.jwk .l3fZGUCmnvKQF_OA6VZF9jf8z2s.jwk

At this point, if you run *tang-show-keys* again, only the new key is being advertised by Tang:

# tang-show-keys iyG5HcF01zaPjaGY6L_3WaslJ_E

Next, switch over to your Stratis system and update it to use the new Tang key. Stratis supports doing this while the filesystem(s) are online.

First, unbind the pool:

# stratis pool unbind pool1

Next, set the key with the original passphrase used when the encrypted pool was created:

# stratis key set --capture-key pool1key

Enter key data followed by the return key:

Finally, bind the pool to the Tang server with the updated key thumbprint:

# stratis pool bind nbde pool1 pool1key http://tang-server --thumbprint iyG5HcF01zaPjaGY6L_3WaslJ_E

The Stratis system is now configured to use the updated Tang key. Once any other client systems using the old Tang key have been updated, the two original key files that were renamed to hidden files in the /var/db/tang directory on the Tang server can be backed up and deleted.

## What if the Tang server is unavailable?

Next, shutdown the Tang server to simulate it being unavailable, then reboot the Stratis system.

Again, after the reboot, the Stratis pool is not available:

# stratis pool list Name Total Physical Properties

If you try to unlock it with NBDE, this fails because the Tang server is unavailable:

# stratis pool unlock clevis Execution failed: An iterative command generated one or more errors: The operation 'unlock' on a resource of type pool failed. The following errors occurred: Partial action "unlock" failed for pool with UUID 4d62f840f2bb4ec9ab53a44b49da3f48: Cryptsetup error: Failed with error: Error: Command failed: cmd: "clevis" "luks" "unlock" "-d" "/dev/vdb" "-n" "stratis-1-private-42142fedcb4c47cea2e2b873c08fcf63-crypt", exit reason: 1 stdout: stderr: /dev/vdb could not be opened.

At this point, without the Tang server being reachable, the only option to unlock the pool is to use the original key passphrase:

# stratis key set --capture-key pool1key

Enter key data followed by the return key:

You can then unlock the pool using the key:

# stratis pool unlock keyring

Next, verify the pool was successfully unlocked:

# stratis pool list Name Total Physical Properties pool1 4.98 GiB / 583.65 MiB / 4.41 GiB ~Ca, Cr

## Mark

Thanks. Haven’t seen the youtube videos you linked to before.

The changing the tang server keys seems like a lot of manual effort on all the client servers, so somebody has probably written an ansible playbook do update multiple servers at once :-).

Is there any advantage to using stratis over brtfs as the later is the default in fedora now and handles pools/snapshots/raid quite well anyway ?. Apart from the obvious that RedHat have “depreciated” brtfs, and removed it entirely from rhel8. As it’s fedoramagazine and all new fedora users will probably use the default install of brtfs the question is what would be the justification for users to also install stratis ?. I think this post is more aimed at enterprise users of redhat systems than fedora users.

Encryption on a stratis filesystem and the use of a tang server seems a needless overhead. The manual unlocking needed if the tang server is unavailable is probably the last thing anybody needs in the middle of the night when things have broken.

Having said that I have not investigated using a tang server so assume something so critical can be configured in a replicated way and the clients have a pool of tang servers they can check in with which would be needed in a large environment.

Personally I just use LUKS encryption on all removable disks and have /etc/crypttab unlock them using keyfiles at boot time. Before anyone mentions it yes of course a major disadvantage of that method is a keyfile is not encrypted and has to be on an unencrypted filesystem (like /boot) in order to be read at boot time it you want the disks automatically online at boot time. But the system will come up even if the network around it is dead.

And stratis can use luks encrypted devices anyway (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_file_systems/managing-layered-local-storage-with-stratis_managing-file-systems) so its adding an extra layer not really needed ?.

And that doc also mentions stratis supports md-raid devices; so I guess stratis does not support its own software raid like brtfs and zfs (yet).

The comment in the post on disks lost or stolen not being able to be unencrypted if they cannot contact the tang server also applies to the simple keyfile method as lost or stolen disks cannot be unencrypted unless the system boot disk containing the keyfiles is also taken :-).

But the advantages of something like a tang server are obvious in that no keys are in clear text. Except the ‘origional key passphrase’ for unlocking when the tang server is unavailable would have to be written down somewhere for every client server pool.

However I thank you for the post as while I don’t see any point in moving to stratis it did encourage me start googling the tang server, which looks like it isn’t bound to stratis but will manage native luks volumes as well( https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening ) so NBDE is something worth a look for all those like me than were not aware of it.

## Brian Smith

Hi Mark, in my opinion one of the main advantages is Stratis is its ease of use, and that it is built on top of very stable technologies like XFS (Stratis is a control plane, not a filesystem). BRTFS has some very nice features that Stratis lacks, and I’m glad that Fedora offers different options in this area.

I think the main concern with having the keyfile unencrypted in something like the /boot filesystem is that if the encrypted disks are lost/stolen, it is likely that the disk with the /boot filesystem containing the unencrypted key was lost/stolen as well. Especially if you consider something like a laptop.

Yes, you are correct that NBDE can be used with LUKS as well. NBDE is easy to get started with and to setup, so hopefully you can give it a try.

## Mark

Thanks, you have definately inspired me, even if my focus was on luks encrypted disks.

Using it on external USB luks encrypted devices is easy after installing clevis-udisk2, but less secure. In a gnome desktop environment the visible change is instead of prompting for the luks key and mounting it tang decrypts it ok then prompts for the gnome logged on user password to bump up to authority to use the mount command for it. So anyone can take a disk from one desktop to their own and use it if they know their own password; so I guess removable media while supported is a bad idea.

Most of the tutorials on youtube show examples of clevis binding to a named server, such as your example of http://tang-server.

I assume that in most use cases clevis/tang is only used well after boot or if the server(s) is configured to get its own ip-addresses and dns server lists from a dhcp server when it boots.

At boot time for servers that have static ip-addresses configured its a bit of a mess, found the answer in redhat documentation, you have to use dracut not just to install the clevis-dracut code but to also configure your server network settings using dracut (and that overrides anything customised in /etc/sysconfig/network-scripts or networkmanager; and selinux does not like a network built by dracut at all)… but fiddling with dracut does allow luks boot disks to be unlocked by a tang server.

The doc for later viewers is https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-policy-based_decryption

So this reply is not directly related to your post on stratis but specificaly to the reply of NDBE is easy to get started with. As your post was very informative I hope it ranks high in google searches, but playing with clevis/tang/luks it is not easy so just wanted to correct that for the millions of viewers who may hit the page because comments have luks in them.

Once again thanks for the post Brian. Last week I didn’t know tang/clevis existed; now I am determined to make it work for me, although it may take a while. Nice to read a post that triggers the I must learn this response.

## Brian Smith

Hi Mark,

If it helps, here is a short video I made that covers using NBDE at boot with LUKS:

https://www.youtube.com/watch?v=y_9_iWNUBug

## Natxo

I hope you don’t mind if I chip in.

There is to my knowledge a more recent piece of official documentation for rhel8: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening

The probably incorrect assumption for your use case is that I guess (I am not the developer, so take it with a grain of salt) clevis-udisks2 is meant for laptops. Those systems have usually just one user, so this is what one normally wants, it automatically decrypts the disk. If this is not your situation, you are very right to point this and the documentation should warn about this, and one should take measures to not let other users but the ones allowed to decrypt the disk log on to the workstation.

Dracut is …, special, yes. It’s super flexible, but it comes at a price. It’s not something most people usually require to modify. For fixed ips you can add the plugin omit_dracutmodules+=”ifcfg” to the dracut configuration, and dracut will not try to be helpful and will not overwrite your network configuration. Believe me, it can get messier if the host is multihomed and you need to boot from a specific network interface, or if you have ipv6 in the picture, or if you have several disks in the equation. If you are new to the technology I understand completely it can be overwhelming at first. You do need to be ready to fix stuff if it breaks, that is always fun (so what do you do if you tried to set up a fixed ip address, and someone messes up the dracut configuration with a typo, and the system halts during its boot process – yes, this happens)

All in all, for the simplest use case (automatically boot in single network with dhcp enabled in a wired network) it works out of the box. In other use cases, it does require some more leg work, but it is worth it if you require the luks encryption and you manage a fleet of linux hosts.

There are new things for automatically decrypting disks coming up like this one: http://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html which could be better suited to your use case. They are not available on rhel 8 I think, maybe in fedora 34 they are. To me being able to decrypt with a yubikey is very helpful and I look forward to using it.

## Natxo

In our case we required that systems only can boot if they are in an accept list in firewalls to contact the tang servers. So if systems go to customers they cannot boot (if they are intercepted by a third party, they will not reach our tang servers, so they do not boot). This is what we required, and it’s quite easy to do. Decryption using the key in a tpm chip for instance will have a booting system everytime, even if the system has been hijacked by a third actor, we did not want this.

You can use several tang servers at the same time, and using the sss pin you can even set policies (like, you need to contact 3 of the 5 tang servers in order to decrypt the luks container).

using tang + nbde in combination with kickstarts from the foreman/satellite is really simple, you can replace the first luks key (the get out of jail card, so to speak) using automation. In practice, you only need to contact the tang server(s) during the boot process, so it really is stable (having it in production for the last three years, no problems at all).

The question is, for me, why to encrypt? but rather why not to encrypt? 😉

## Natxo

the main advantage of nbde is that it makes luks encryption easy.

Using automation we save luks keys in hashicorp vault, and rotate those (autogenerated) every now and then. Every system one different key, and a copy of the old key is archived in vault in case something goes wrong. So in fact, you just need to know how to get to hashicorp vault and set the right acls for the key/values (this is something you can easily set up and delegate).

Very happy with this solution.