加密静态数据¶
问题描述¶
OpenStack 云为云用户提供多种类型的存储，包括实例临时磁盘（通常附加到虚拟机管理程序）、Cinder 块设备（通常由 Ceph 等存储解决方案提供支持）和 Swift 对象存储。
默认情况下，驻留在这些虚拟设备上的数据未加密；PCI-DSS 和 GPDR+ 等法规要求静态数据必须加密存储，以便在设备从数据中心移除时，未经适当加密密钥的访问无法恢复数据。
提议的变更¶
底层存储设备将使用 dm-crypt/LUKS 保护，加密密钥直接存储在 Hashicorp Vault 中。在加密过程或启动时的解密过程中，不会创建密钥的本地副本。
将使用新的工具 ‘vaultlocker’ 来 LUKS 格式化块设备，直接将加密密钥存储在 Vault 中。密钥使用底层块设备的 UUID 引用（在为使用准备磁盘时生成）。
在（重新）启动时，将为每个加密块设备执行一个 vaultlocker-decrypt systemd 单元，从 Vault 检索加密密钥并打开 LUKS 格式化的块设备以供使用。
vaultlocker 将通过 https 访问 vault，使用作为部署过程的一部分发出的 approle。approle 将通过 charm 关系从 vault 传递到消耗服务，并且将限定为只能从参与与 vault 关系的单元访问。
approle 将特定于参与关系的每个单元，其策略仅允许对
<kv-backend>/<hostname>/*
进行读取/写入/删除/更新/列表操作，来自该单元提供的网络地址。其他单元的 approle 将在关系数据中可见，但将无法使用，因为 CIDR ACL 不允许访问。
除了特定于单元的 approle 以及对 /32 的访问限制外，secret_id 也将用于验证 approle 的使用。
secret_id 不会通过 vault charm 到消耗应用程序的关系传递。相反，vault charm 将生成一个 secret_id 并使用 Vault 的响应包装功能对其进行包装。生成的单次性令牌将通过关系传递到消耗应用程序单元，然后该单元可以使用该令牌直接从 Vault 提取 secret_id。这确保了只有 Vault 和消耗应用程序单元知道 secret_id。
单次性令牌的 ttl 为 1h（允许复杂的部署，具有大量的 hook 执行来完成于融合的虚拟机/存储机器上）。
初始支持范围将包括
ceph-osd：OSD 设备加密。
swift-storage：块设备加密。
nova-compute：临时存储块设备加密；请注意，这要求虚拟机管理程序配置了特定的存储设备集，供 Nova 用于实例的临时块设备。
块设备准备¶
加密的块设备将使用 charmhelper 生成的 UUID 进行标记。该 UUID 将在加密期间以及服务器重新启动期间的解密期间使用。
设备将使用密钥存储在 Vault 中进行加密
vaultlocker encrypt --uuid $UUID $BLOCK_DEVICE
生成的 dm-crypt 块设备将打开并准备好使用。
swift-storage 和 nova-compute¶
块设备将与“块设备准备”内联准备；charm 的现有 fstab 管理将被更新为使用 /dev/mapper/crypt-<UUID> 条目，并带有 x-systemd.requires 选项 - 例如
/dev/mapper/crypt-$UUID /mnt auto defaults,x-systemd.requires=vaultlocker-decrypt@$UUID.service,comment=vaultlocker 0 2
这确保了在尝试挂载 mapper 设备之前，vaultlocker-decrypt 任务已完成。
ceph-osd/ceph-volume¶
集成到 ceph-osd charm 需要 charm 切换到使用新的 ceph-volume 工具来管理 OSD 的创建和激活。这要求在传递到 ceph-volume 之前，块设备需要使用 LVM 卷准备；为了镜像现有的 ceph-disk 功能
filestore¶
使用块设备作为日志和数据；日志 lv (osd-journal-<OSD-FSID>) 在 vg ceph-<OSD-FSID> 上创建，使用配置的日志大小，数据 lv (osd-data-<OSD-FSID>) 在 vg ceph-<OSD-FSID> 上创建，使用剩余容量。
pv /dev/sdb
vg /dev/ceph-<OSD-FSID>
lv /dev/ceph-<OSD-FSID/osd-journal-<OSD-FSID>
lv /dev/ceph-<OSD-FSID/osd-data-<OSD-FSID>
使用单独的设备作为日志；日志 lv (osd-journal-<OSD-FSID>) 在日志设备的 vg ceph-journal-<UUID> 上创建，使用配置的日志大小；数据 lv (osd-data-<OSD-FSID>) 在数据设备的 ceph-<OSD-FSID> 上创建，使用 100% 的容量。
pv /dev/sdb
vg /dev/ceph-<OSD-FSID>
lv /dev/ceph-<OSD-FSID/osd-data-<OSD-FSID>
pv /dev/sdg
vg /dev/ceph-journal-<UUID>
lv /dev/ceph-journal-<UUID>/osd-journal-<OSD-FSID>
bluestore¶
Bluestore 比较简单，因为没有日志，因此将在 ceph-<OSD-FSID> 的提供的磁盘上创建一个逻辑卷
pv /dev/sdb
vg /dev/ceph-<OSD-FSID>
lv /dev/ceph-<OSD-FSID/osd-block-<OSD-FSID>
Bluestore DB 和 WAL 卷可以选择性地存储在单独的设备上，再次使用配置/默认大小的 vg ceph-{db,wal}-<UUID> 的逻辑卷。
pv /dev/sdb
vg /dev/ceph-<OSD-FSID>
lv /dev/ceph-<OSD-FSID/osd-block-<OSD-FSID>
pv /dev/sdg
vg /dev/ceph-db-<UUID>
lv /dev/ceph-db-<UUID>/osd-db-<OSD-FSID>
pv /dev/sdh
vg /dev/ceph-wal-<UUID>
lv /dev/ceph-wal-<UUID>/osd-wal-<OSD-FSID>
请注意，ceph-volume 仅提供在 Ceph Luminous 或更高版本中，因此在 Ceph Jewel 下的加密明确排除在本文档的范围之外。
备选方案¶
ceph¶
使用 Ceph 中用于 OSD 加密的本机支持；打折，因为它使用 ceph-mon 集群来存储密钥 - 密钥未分片，部署通常将 ceph-mon 单元与 ceph-osd 单元并排放置，因此加密密钥可能直接位于与加密 Ceph OSD 块设备相同的服务器上。
注意
ceph-osd charm 已经支持使用 ceph-disk/ceph-volume 通过 osd-encrypt 选项进行本机 Ceph 块设备加密。
可以将对 vault 的支持添加到 ceph-volume；但是，由于需要支持现有的 Ceph 版本（>= Luminous），因此短期内不考虑此选项，但如果支持进入 Ceph 上游，则可以在长期内考虑。
cinder¶
Cinder 具有使用 LUKS 进行块设备加密的本机支持；密钥使用 Barbican 存储，Barbican 依赖于实现 PKCS#11 或 KMIP 的 HSM，才能被认为安全。这将为 Cinder 块设备提供所需的加密支持，但需要使用基于硬件的安全模块（Barbican 不支持 Vault）。
nova¶
Nova 具有使用 LVM 后端进行存储时加密临时磁盘的本机支持；同样，密钥存储在 barbican 中，需要使用 HSM 或在 Barbican 中实现合适的软件安全模块。此选项也仅限于 LVM 存储。
swift¶
Swift 没有本机加密支持，因此没有考虑此问题域的其他替代方案。
实现¶
负责人¶
主要负责人
james-page
Gerrit Topic¶
对于与此规范相关的所有补丁，请使用 Gerrit 主题“vaultlocker”。
git-review -t vaultlocker
工作项¶
vaultlocker¶
基本代码库（支持加密/解密）
单元测试
功能测试
QA¶
mojo 规范以验证静态加密支持
文档¶
示例 bundle + 静态加密文档
附录，用于部署指南，介绍用法和安全注意事项
charmhelpers¶
块设备加密助手
ceph-osd¶
添加对使用 ceph-volume >= Luminous 的支持
启用使用 vaultlocker 进行块设备加密的支持
添加与 vault 的关系
swift-storage¶
启用使用 vaultlocker 进行块设备加密的支持
添加与 vault 的关系
nova-compute¶
启用使用 vaultlocker 进行块设备加密的支持
添加与 vault 的关系
仓库¶
需要一个新的仓库来存放 vaultlocker。
文档¶
文档将作为 ceph-osd、swift-storage 和 nova-compute charms 的一部分提供。
将在 charm 部署指南中添加一个额外的附录，涵盖静态加密。
安全性¶
由于此解决方案涵盖了用于保护用于保护块设备免受未经授权移除的加密密钥的安全性，因此有多个安全问题需要解决。
与 Vault 的通信将通过 TLS 加密连接进行，使用 AppRole（没有 secret_id）进行身份验证，该 AppRole 将通过 charm 关系传递到消耗 charm；与 Juju 的连接也经过 TLS 加密，因此拦截 AppRole 的可能性有限。
单元使用的 secret_id 通过 Juju 的方式传递 - 单次性令牌通过 vault-kv 关系传递，只能由消耗单元用于检索生成的 AppRole 的 secret_id。令牌的 TTL 为 1 小时，并且与 AppRole 具有相同的 CIDR 限制。
加密密钥将存储在 AppRole 特定的 Vault 路径下。Vault AppRole 将根据访问服务器的 CIDR 限制对 secrets 后端进行访问限制。
测试¶
功能将通过每个组件的单元测试和功能测试进行验证。
将使用 Mojo 规范验证整个解决方案的功能。
依赖项¶
生产级别的 vault charm。
AppRole 接口到 vault charm。
