sops-nix项目中容器化服务的密钥管理实践

在NixOS系统中使用sops-nix管理容器化服务的密钥时，开发者可能会遇到权限配置的挑战。本文将通过一个典型场景，分析如何正确处理systemd-nspawn容器中的密钥访问问题。

问题背景

当在NixOS容器中使用sops-nix管理密钥时，常见做法是通过bindMounts将主机解密后的密钥文件挂载到容器内部。然而，这种方案可能面临密钥文件权限不一致的问题：

• 对于有固定UID的系统服务（如nginx用户UID为398），密钥访问正常
• 对于动态分配UID的服务用户（如nextcloud），会出现"Permission denied"错误

根本原因分析

这种不一致性源于NixOS的特殊设计：

1. 部分核心服务在misc/ids.nix中预定义了固定UID
2. 普通服务用户的UID通常由系统动态分配
3. sops-nix在主机端配置时需要明确知道容器内用户的UID

解决方案比较

方案一：固定服务用户UID

在容器配置中显式指定用户UID：

users.users.nextcloud = {
  uid = 998;
  isSystemUser = true;
};

同时确保主机端sops配置使用相同的UID：

sops.secrets."nextcloud/admin/password" = {
  uid = 998;
  gid = 998;
};

优点：保持现有架构不变 缺点：需要手动协调UID分配

方案二：使用共享age密钥

1. 为所有容器配置相同的age密钥
2. 在每个容器内部独立运行sops-nix

优点：各容器自治，无需处理跨容器权限 缺点：需要管理多个容器的密钥更新

方案三：Systemd LoadSecret机制

利用systemd的临时文件系统特性安全传递密钥：

systemd.services.container-service = {
  serviceConfig.LoadCredential = "secret:/run/secrets/container-secret";
};

优点：

• 自动处理文件权限
• 密钥仅在内存中存在
• 无需关心UID映射问题

缺点：需要调整现有容器启动方式

安全建议

1. 对于生产环境，优先考虑Systemd LoadSecret方案
2. 临时测试可使用固定UID方案
3. 避免在容器间共享解密密钥
4. 所有密钥文件应设置isReadOnly=true

最佳实践示例

# 采用Systemd LoadSecret的容器配置示例
containers.nextcloud = {
  config = { pkgs, ... }: {
    systemd.services.nextcloud-setup = {
      serviceConfig.LoadCredential = [
        "adminpass:${config.sops.secrets."nextcloud/admin/password".path}"
      ];
      preStart = ''
        install -m 600 -o nextcloud -g nextcloud \
          "${"\${CREDENTIALS_DIRECTORY}/adminpass"}" \
          /run/secrets/adminpass
      '';
    };
  };
};