![概括](https://linux22.com/image/750213/%E6%A6%82%E6%8B%AC.png)
概括
我们希望支持这种情况:如果我们感觉到任何可能暴露我们的核心数据(所有数据都存储在/home
我们 NFS 服务器的 NFS 挂载上)的安全威胁,我们会立即“硬”关闭 NFS 服务器。任何潜在的、连续的、未经授权的服务器重启都无法读取或写入/home
...因为我们的系统(希望)需要人工输入密码/key_challenge/secret(如下文最初提出的),可能(如果不是)通过简单的 ssh 登录到 NFS 服务器计算机,然后系统才能挂载卷/home
。
这是可行的吗?如果可行,我们该怎么做?这是基于 LUKS 的安装(或某些类似技术、工具集、小发明)的“正常/默认”模式吗?或者还有其他(更好的?)方法来实现我们的目的吗?
细节
我的团队计划实施NFS 导出的基于 LUKS 的“稀疏文件类”循环设备文件,类似于或完全相同于/home
导出(用于由我们的 VPN/网络中的其他服务器/机器/虚拟机/容器安装的 NFS 客户端)。
我们目前的目标实现:系统需要输入密码(或基于密钥的质询)才能挂载 LUKS/home
卷(仅有的从 NFS 服务器挂载时),大概是在 NFS 服务器机器/容器正常启动之后。
但是,如果有更好的方法……请提出建议。我们希望以最佳方式实现摘要中描述的目标/意图,并且不希望假设潜在解决方案的范围有限。
目前,我们预计 NFS 服务器将是运行在相同版本 Ubuntu docker 主机上的 Ubuntu 18.04.4 Docker 容器。而 NFS 导出的挂载点将是 Docker 主机提供的 Docker 卷(到 NFS Docker 容器)。但这种设计远未“确定”,我们灵活且愿意接受其他建议。
虽然我们确实在为使用循环设备(我们所理解的“文件中的文件系统”)映射的 NFS 应用程序(系统设计)提供服务,但我们尚未将其视为 NFS 或循环设备特定的问题。即,对于没有 NFS 或循环设备组件的其他设计,可能会出现相同的情况。
系统约束
在我们当前的环境中,我们无法采用类似 SAN 的解决方案。(我们知道,如今嵌入在网络存储/SAN 解决方案中的 LUKS 非常流行。我们收到了很多类似“只使用基于 LUKS 的 SAN”的评论。在这种情况下,这对我们来说行不通。)我们当前的限制:此 NFS 服务器设备全部在基于kvm虚拟机,通常由 DigitalOcean、Linode、AWS 等托管服务提供商部署。
后果和团队背景
是的,我们意识到 NFS 服务器的硬关机/非正常关机将破坏所有 NFS 客户端;我们计划要求它们全部重新启动(在最坏的情况下)。是的,我们意识到非正常关机可能会破坏数据、文件系统、数据库等。
我们已经设计了我们的网络,使其能够在合理范围内稳健且(相对)轻松地处理所有这些情况。此外:我们预计 1) 这种“终止开关”情况很少2) 我们很少需要因为任何原因重启 NFS 服务器系统(Docker 容器或其他);我们将保持其非常稳定,并将所有动态变化较多的软件(操作系统、应用程序等)系统放在其他机器上。NFS 服务器有一点简单的配置锁定和超级简单的设置,几乎没有依赖关系。
无论如何,我们都会签约这套设备,因为我们是经验丰富的块和文件系统、存储服务器管理员(早在 LUKS 出现之前),并且“已经熟悉这个块”,至少从很久以前开始。(具体来说,从 1990 年代中期到 2000 年代初期,在 Linux“流行”之前,光纤通道 SAN 和 FC-SAN 时代之前。在 2000 年代后期到 2010 年代初期,我们拥有更多的系统经验。)
虽然我们是经验丰富、经验丰富的老手,但我们也是 LUKS 新手。尽管如此,对于我们之前管理过的类似系统,LUKS 概念似乎都很简单。我们最初的研究表明,有很多 StackExchange/ServerFault 问题专门询问如何避免必须手动提供某种密码/key_challenge/secret。我们实际上(我们认为?)想要做相反的事情。在我们开始实施这一切之前,我们发布这个问题,希望我们可以向前人学习,也许可以节省一点项目时间。