Buildkit 在 Rootless 模式下进程残留问题分析与解决方案

问题现象

在使用 Buildkit 进行容器构建时，当以 Rootless 模式运行且启用了 --oci-worker-no-process-sandbox 参数时，发现构建过程中启动的某些进程（如示例中的 firebird 服务）会在构建完成后仍然保留在 Buildkitd 主机上持续运行。这种现象在 Kubernetes 环境中尤为明显，可能导致潜在的安全风险。

技术背景

Buildkit 是 Docker 生态系统中的下一代构建工具，支持 Rootless 模式运行以增强安全性。Rootless 模式通过避免使用 root 权限来降低潜在的安全风险。--oci-worker-no-process-sandbox 参数用于禁用进程沙箱，在某些场景下可以提高兼容性，但同时会带来一些安全上的妥协。

问题根源

该问题的根本原因在于：

1. 当启用 --oci-worker-no-process-sandbox 时，Buildkit 不会为构建容器创建独立的 PID 命名空间
2. 在 Rootless 模式下，虽然进程以非特权用户运行，但缺乏完整的进程隔离机制
3. 某些服务（如 firebird）设计为守护进程运行，在构建过程中启动后会持续运行

解决方案

Docker 环境解决方案

在 Docker 环境中，建议的解决方案是：

1. 移除 --oci-worker-no-process-sandbox 参数
2. 改用 --security-opt systempaths=unconfined 参数
3. 虽然这与 --privileged 类似，但进程仍以非特权用户运行

示例命令：

docker run --security-opt systempaths=unconfined ...

Kubernetes 环境解决方案

在 Kubernetes 环境中，情况更为复杂：

1. 理论上可以使用 procMount: Unmasked 配置
2. 但需要启用特定的特性门控（feature gates）
3. 在实际测试中，即使配置了也可能无法完全解决问题
4. 因此，在 Kubernetes 中更可靠的解决方案是使用 privileged: true

示例 Pod 配置：

securityContext:
  privileged: true

安全建议

1. 在生产环境中谨慎使用 --oci-worker-no-process-sandbox 参数
2. 定期检查 Buildkitd 主机上的运行进程
3. 考虑使用更严格的 seccomp 和 AppArmor 配置
4. 对于关键构建环境，建议使用完整的沙箱隔离

总结

Buildkit 在 Rootless 模式下的进程隔离问题反映了容器安全中的平衡取舍。开发者和运维人员需要根据实际需求和安全要求，在功能性和安全性之间做出合理选择。理解这些底层机制有助于构建更安全可靠的 CI/CD 流水线。

对于大多数生产环境，建议避免使用 --oci-worker-no-process-sandbox 参数，除非有明确的兼容性需求且已评估相关风险。在必须使用该参数的情况下，应实施额外的监控措施来检测和防止意外的进程残留。