Stratis 加密入门
加密 Stratis
![](/data/attachment/album/202104/19/094919orzaxwl5axiqqfiu.jpg)


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


Stratis 2.1 版本引入了对加密的支持。继续阅读以了解如何在 Stratis 中开始加密。


### 先决条件


加密需要 Stratis 2.1 或更高版本。这篇文章中的例子使用的是 Fedora 33 的预发布版本。Stratis 2.1 将用在 Fedora 33 的最终版本中。


你还需要至少一个可用的块设备来创建一个加密池。下面的例子是在 KVM 虚拟机上完成的，虚拟磁盘驱动器为 5GB（`/dev/vdb`）。


### 在内核密钥环中创建一个密钥


Linux 内核<ruby> 密钥环 <rt>  keyring </rt></ruby>用于存储加密密钥。关于内核密钥环的更多信息，请参考 `keyrings` 手册页（`man keyrings`）。


使用 `stratis key set` 命令在内核钥匙圈中设置密钥。你必须指定从哪里读取密钥。要从标准输入中读取密钥，使用 `-capture-key` 选项。要从文件中读取密钥，使用 `-keyfile-path <file>` 选项。最后一个参数是一个密钥描述。它将稍后你创建加密的 Stratis 池时使用。


例如，要创建一个描述为 `pool1key` 的密钥，并从标准输入中读取密钥，可以输入：



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

```

该命令提示我们输入密钥数据/密码，然后密钥就创建在内核密钥环中了。


要验证密钥是否已被创建，运行 `stratis key list`：



```
# stratis key list
Key Description
pool1key

```

这将验证是否创建了 `pool1key`。请注意，这些密钥不是持久的。如果主机重启，在访问加密的 Stratis 池之前，需要再次提供密钥（此过程将在后面介绍）。


如果你有多个加密池，它们可以有一个单独的密钥，也可以共享同一个密钥。


也可以使用以下 `keyctl` 命令查看密钥：



```
# keyctl get_persistent @s
318044983
# keyctl show
Session Keyring
 701701270 --alswrv      0     0  keyring: _ses
 649111286 --alswrv      0 65534   \_ keyring: _uid.0
 318044983 ---lswrv      0 65534   \_ keyring: _persistent.0
1051260141 --alswrv      0     0       \_ user: stratis-1-key-pool1key

```

### 创建加密的 Stratis 池


现在已经为 Stratis 创建了一个密钥，下一步是创建加密的 Stratis 池。加密池只能在创建池时进行。目前不可能对现有的池进行加密。


使用 `stratis pool create` 命令创建一个池。添加 `-key-desc` 和你在上一步提供的密钥描述（`pool1key`）。这将向 Stratis 发出信号，池应该使用提供的密钥进行加密。下面的例子是在 `/dev/vdb` 上创建 Stratis 池，并将其命名为 `pool1`。确保在你的系统中指定一个空的/可用的设备。



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

```

你可以使用 `stratis pool list` 命令验证该池是否已经创建：



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

```

在上面显示的示例输出中，`~Ca` 表示禁用了缓存（`~` 否定了该属性）。`Cr` 表示启用了加密。请注意，缓存和加密是相互排斥的。这两个功能不能同时启用。


接下来，创建一个文件系统。下面的例子演示了创建一个名为 `filesystem1` 的文件系统，将其挂载在 `/filesystem1` 挂载点上，并在新文件系统中创建一个测试文件：



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

```

### 重启后访问加密池


当重新启动时，你会发现 Stratis 不再显示你的加密池或它的块设备：



```
# stratis pool list
Name   Total Physical   Properties

```


```
# stratis blockdev list
Pool Name   Device Node   Physical Size   Tier

```

要访问加密池，首先要用之前使用的相同的密钥描述和密钥数据/口令重新创建密钥：



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

```

接下来，运行 `stratis pool unlock` 命令，并验证现在可以看到池和它的块设备：



```
# stratis pool unlock
# stratis pool list
Name                      Total Physical   Properties
pool1   4.98 GiB / 583.65 MiB / 4.41 GiB      ~Ca, Cr
# stratis blockdev list
Pool Name   Device Node   Physical Size   Tier
pool1       /dev/dm-2          4.98 GiB   Data

```

接下来，挂载文件系统并验证是否可以访问之前创建的测试文件：



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

```

### 使用 systemd 单元文件在启动时自动解锁 Stratis 池


可以在启动时自动解锁 Stratis 池，无需手动干预。但是，必须有一个包含密钥的文件。在某些环境下，将密钥存储在文件中可能会有安全问题。


下图所示的 systemd 单元文件提供了一个简单的方法来在启动时解锁 Stratis 池并挂载文件系统。欢迎提供更好的/替代方法的反馈。你可以在文章末尾的评论区提供建议。


首先用下面的命令创建你的密钥文件。确保用之前输入的相同的密钥数据/密码来代替`passphrase`。



```
# echo -n passphrase > /root/pool1key

```

确保该文件只能由 root 读取：



```
# chmod 400 /root/pool1key
# chown root:root /root/pool1key

```

在 `/etc/systemd/system/stratis-filesystem1.service` 创建包含以下内容的 systemd 单元文件：



```
[Unit]
Description = stratis mount pool1 filesystem1 file system
After = stratisd.service

[Service]
ExecStartPre=sleep 2
ExecStartPre=stratis key set --keyfile-path /root/pool1key pool1key
ExecStartPre=stratis pool unlock
ExecStartPre=sleep 3
ExecStart=mount /stratis/pool1/filesystem1 /filesystem1
RemainAfterExit=yes

[Install]
WantedBy = multi-user.target

```

接下来，启用服务，使其在启动时运行：



```
# systemctl enable stratis-filesystem1.service

```

现在重新启动并验证 Stratis 池是否已自动解锁，其文件系统是否已挂载。


### 结语


在今天的环境中，加密是很多人和组织的必修课。本篇文章演示了如何在 Stratis 2.1 中启用加密功能。




---


via: <https://fedoramagazine.org/getting-started-with-stratis-encryption/>


作者：[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
Stratis is described on its [official website](https://stratis-storage.github.io/) as an “*easy to use local storage management for Linux*.” See this [short video](https://www.youtube.com/watch?v=CJu3kmY-f5o) for a quick demonstration of the basics. The video was recorded on a Red Hat Enterprise Linux 8 system. The concepts shown in the video also apply to Stratis in Fedora.

Stratis version 2.1 introduces support for encryption. Continue reading to learn how to get started with encryption in Stratis.

## Prerequisites

Encryption requires Stratis version 2.1 or greater. The examples in this post use a pre-release of Fedora 33. Stratis 2.1 will be available in the final release of Fedora 33.

You’ll also need at least one available block device to create an encrypted pool. The examples shown below were done on a KVM virtual machine with a 5 GB virtual disk drive *(/dev/vdb*).

## Create a key in the kernel keyring

The Linux kernel keyring is used to store the encryption key. For more information on the kernel keyring, refer to the *keyrings* manual page (*man keyrings*).

Use the *stratis key set *command to set up the key within the kernel keyring. You must specify where the key should be read from. To read the key from standard input, use the *–capture-key* option. To retrieve the key from a file, use the *–keyfile-path <file>* option. The last parameter is a key description. It will be used later when you create the encrypted Stratis pool.

For example, to create a key with the description *pool1key*, and to read the key from standard input, you would enter:

#stratis key set --capture-key pool1keyEnter desired key data followed by the return key:

The command prompts us to type the key data / passphrase, and the key is then created within the kernel keyring.

To verify that the key was created, run *stratis key list*:

#stratis key listKey Description pool1key

This verifies that the *pool1key* was created. Note that these keys are not persistent. If the host is rebooted, the key will need to be provided again before the encrypted Stratis pool can be accessed (this process is covered later).

If you have multiple encrypted pools, they can have a separate keys, or they can share the same key.

The keys can also be viewed using the following *keyctl* commands:

#keyctl get_persistent @s318044983 #keyctl showSession Keyring 701701270 --alswrv 0 0 keyring: _ses 649111286 --alswrv 0 65534 \_ keyring: _uid.0 318044983 ---lswrv 0 65534 \_ keyring: _persistent.0 1051260141 --alswrv 0 0 \_ user: stratis-1-key-pool1key

## Create the encrypted Stratis pool

Now that a key has been created for Stratis, the next step is to create the encrypted Stratis pool. Encrypting a pool can only be done at pool creation. It isn’t currently possible to encrypt an existing pool.

Use the *stratis pool create* command to create a pool. Add *–key-desc* and the key description that you provided in the previous step (*pool1key*). This will signal to Stratis that the pool should be encrypted using the provided key. The below example creates the Stratis pool on */dev/vdb*, and names it *pool1*. Be sure to specify an empty/available device on your system.

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

You can verify that the pool has been created with the *stratis pool list* command:

#stratis pool listName Total Physical Properties pool1 4.98 GiB / 37.63 MiB / 4.95 GiB ~Ca, Cr

In the sample output shown above, *~Ca *indicates that caching is disabled (the tilde negates the property). *Cr *indicates that encryption is enabled. Note that caching and encryption are mutually exclusive. Both features cannot be simultaneously enabled.

Next, create a filesystem. The below example, demonstrates creating a filesystem named *filesystem1*, mounting it at the */filesystem1* mountpoint, and creating a test file in the new filesystem:

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

## Access the encrypted pool after a reboot

When you reboot you’ll notice that Stratis no longer shows your encrypted pool or its block device:

# stratis pool listName Total Physical Properties

# stratis blockdev listPool Name Device Node Physical Size Tier

To access the encrypted pool, first re-create the key with the same key description and key data / passphrase that you used previously:

# stratis key set --capture-key pool1keyEnter desired key data followed by the return key:

Next, run the *stratis pool unlock* command, and verify that you can now see the pool and its block device:

#stratis pool unlock#stratis pool listName Total Physical Properties pool1 4.98 GiB / 583.65 MiB / 4.41 GiB ~Ca, Cr #stratis blockdev listPool Name Device Node Physical Size Tier pool1 /dev/dm-2 4.98 GiB Data

Next, mount the filesystem and verify that you can access the test file you created previously:

#mount /stratis/pool1/filesystem1 /filesystem1/#cat /filesystem1/testfilethis is a test file

## Use a systemd unit file to automatically unlock a Stratis pool at boot

It is possible to automatically unlock your Stratis pool at boot without manual intervention. However, a file containing the key must be available. Storing the key in a file might be a security concern in some environments.

The systemd unit file shown below provides a simple method to unlock a Stratis pool at boot and mount the filesystem. Feedback on a better/alternative methods is welcome. You can provide suggestions in the comment section at the end of this article.

Start by creating your key file with the following command. Be sure to substitute *passphrase *with the same key data / passphrase you entered previously.

# echo -n passphrase > /root/pool1key

Make sure that the file is only readable by root:

# chmod 400 /root/pool1key # chown root:root /root/pool1key

Create a systemd unit file at */etc/systemd/system/stratis-filesystem1.service* with the following content:

[Unit] Description = stratis mount pool1 filesystem1 file system After = stratisd.service [Service] ExecStartPre=sleep 2 ExecStartPre=stratis key set --keyfile-path /root/pool1key pool1key ExecStartPre=stratis pool unlock ExecStartPre=sleep 3 ExecStart=mount /stratis/pool1/filesystem1 /filesystem1 RemainAfterExit=yes [Install] WantedBy = multi-user.target

Next, enable the service so that it will run at boot:

# systemctl enable stratis-filesystem1.service

Now reboot and verify that the Stratis pool has been automatically unlocked and that its filesystem is mounted.

## Summary and conclusion

In today’s environment, encryption is a must for many people and organizations. This post demonstrated how to enable encryption in Stratis 2.1.

## Sheogorath

A very nice article, I wasn’t aware of stratis at all. But I have one question: how is stratis relationship to LVM, cryptsetup and alike? Is stratis a daemon working on top of these or is it managing an entire own implementation of the storage management? Do they interfere with each other?

Also, one minor remark: in the key management part during automated unlock, the proper order would be:

touch /root/pool1key

chown root:root /root/pool1key

chmod 400 /root/pool1key

echo “secret password” > /root/pool1key

This would eliminate the possible race condition where the previous owner, given that the file already exist and was owned by a non-root user, could modify the permissions of the file before its ownership is changed, resulting in unexpected access to the file for the previous owner.

Hope that helps and looking forward to the next article!

## Brian Smith

Hi Sheogorath,

The Stratis design document at https://stratis-storage.github.io/StratisSoftwareDesign.pdf should answer your questions about how Stratis works.

## Oscar

Why Fedora has choosen btrfs (deprecated by RedHat) instead of Stratis? I can’t understand.

## Brian Smith

Hi Oscar,

This link might help answer your question about btrfs and Red Hat: https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Red_Hat_doesn.27t_support_Btrfs.3F_Can_Fedora_do_this.3F

## Oscar

Thanks a lot. Very interesting!!

## Felipe

Great post! Shouldn’t all hashtags be a dollar sign?

## Brian Smith

Hi Felipe,

The commands in the article were run as the root user, indicated by the “# ” prompt.

## Gregory Bartholomew

Hi Felipe. The hashtags would be dollar signs for unprivileged commands. The commands being demonstrated in this article require super user privileges. The hashtag indicates that super user mode has been locked on by entering “sudo -i” so that every command does not need to be prefixed with sudo individually.

## Ross

There are no hashtags in this post. A hashtag is a hash (#) followed by a tag (one or more non-whitespace characters) — ‘#’ alone is just called a hash (or octothorpe, number sign, etc).

## T

If you wrote the password in a file on the hard drive anyway, what’s the point of encryption in the first place? Or am I missing something.

For a bad guy sitting with the hard drive connected to his system or your laptop booted into single mode in front of him, it’s not rocket science to figure out how it gets mounted at boot time.

## Brian Smith

Hi, as I mentioned in the article there are some security concerns with storing the key in a file. It is not required that you store it in file, you can always follow the steps in the “Access the encrypted pool after a reboot” section to manually re-create the key after each reboot.

Also keep in mind that in the example in this article, the key file is stored in the root filesystem. If the Stratis device was a removable storage drive, if the removable drive was lost/stolen by itself it would not have the key file on it (it would be on the systems root filesystem). So in other words, if you had a USB drive with encrypted Stratis on it, and lost the USB drive and not the laptop (root filesystem), the Stratis USB drive would not have the key file on it.

Also, your root filesystem could be encrypted (with LUKS). In that case, your laptop and the Stratis USB drive could be stolen, and without the LUKS password they couldn’t get to the Stratis key file in the root filesystem.

## Christian Horn

This depends on the scenario, I think.

If the storage is local, and you have the passphrase in a file, then the benefit of encryption might indeed come down to “instead of zeroing the device for removing the data, I can remove the passphrase file”.

If your volumes are backed by iSCSI devices provided by some remote system, then even having the passphrase in the local file can help you: then you “just” have to trust/secure the local system and not the system providing the iSCSI devices.

## T

Yours and Brian’s replies are all valid, and highlight how the proposed solution might still be viable in some cases.

The article as it stands does not reflect this. It still says “in some cases this might be a security concern”.

Quite the opposite is true at best; “in a few special scnearios this might be a meaningful approach” sounds more right.

For the likely reader of this article putting the pass phrase in a clear text file on the local hard drive would negate all security benefits that come with encr.yption in the first place.

If you access centralized storage that needs to be decrypted before accessing, you are likely not the kind of guy who needs to be told that you can put your passphrase in a clear text file on the local hard drive to mount it on boot using systemd.

Removable storage is a valid case, and reading on how to mount your encrypted usb device seemlessly when you plug it in, would make for a nice read. Though currently you need to dig deep down into the comments to figure that out. And in the same time un-learn the first impression you got from reading the article.

## Federico Chiacchiaretta

What about Clevis TPM integration with Stratis? Is there a roadmap?

## Dennis Keefe

Stratis has been working on this feature. Here are some links to the work.

Clevis support

https://github.com/stratis-storage/project/issues/192

Prototype of clevis integration from CLI

https://github.com/stratis-storage/stratis-cli/pull/657

## Dmitri Pal

Yes integration with clevis will give you also the option of automatically unlocking the keys using tang server which is already used with LUKS encryption.

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

## ket bilietai nemokamai

Thank you, I have recently been looking for information about this subject for

a while and yours is the best I have discovered so far.

But, what about the bottom line? Are you positive about the

source?

my website ket bilietai nemokamai