概括
我们希望支持这种情况：如果我们感觉到任何可能暴露我们的核心数据（所有数据都存储在/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。我们实际上（我们认为？）想要做相反的事情。在我们开始实施这一切之前，我们发布这个问题，希望我们可以向前人学习，也许可以节省一点项目时间。