Cert-manager 单命名空间部署问题解析

问题背景

Cert-manager 作为 Kubernetes 上广泛使用的证书管理工具，其设计初衷是作为集群级组件运行。然而在实际生产环境中，出于安全隔离和多租户管理的需求，用户有时希望将 cert-manager 限制在单个命名空间内运行。

问题现象

当用户按照官方文档说明，通过 --namespace 参数将 cert-manager 限制在特定命名空间运行时，发现控制器仍然会尝试访问集群级资源（如 ClusterIssuer），导致在没有集群级 RBAC 权限的情况下运行失败。

技术分析

问题根源

1. 控制器设计缺陷：虽然 --namespace 参数理论上应该限制 cert-manager 只处理指定命名空间内的资源，但内部实现上仍然初始化了 ClusterIssuer 的监听器。

2. RBAC 权限要求：即使禁用了 ClusterIssuer 功能（通过 --controllers=*,-clusterissuers），控制器仍然需要集群级权限来验证 ClusterIssuer 资源是否存在。

3. 依赖关系：某些功能模块（如自签名颁发者）与集群级资源存在隐式依赖关系，简单的控制器禁用可能导致功能异常。

影响范围

此问题影响所有希望以命名空间隔离方式部署 cert-manager 的用户，特别是：

• 多租户环境下的集群管理员
• 安全合规要求严格的组织
• 需要最小权限原则部署的场景

解决方案

临时解决方案

1. 完全禁用相关控制器：

--controllers=*,-clusterissuers,-certificaterequests-issuer-selfsigned

注意：此方案会导致自签名颁发者功能不可用。

2. 自定义 RBAC 配置：

• 修改部署模板，将 ClusterRole 改为 Role
• 移除 webhook 相关组件
• 确保所有资源引用都限定在目标命名空间内

长期建议

等待官方修复此问题，在 v1.18.0 版本中已包含相关修复，建议用户测试预发布版本并反馈结果。

最佳实践

对于需要命名空间隔离的场景，建议：

1. 评估是否真正需要单命名空间部署，cert-manager 设计更适合集群级部署
2. 如果必须隔离，考虑使用独立的 Kubernetes 集群而非命名空间隔离
3. 密切跟踪官方版本更新，及时升级到包含修复的版本

总结

Cert-manager 的单命名空间部署模式目前存在实现不完善的问题，用户需要权衡功能完整性和安全隔离需求。随着项目的持续发展，这个问题有望在后续版本中得到彻底解决。在此期间，用户可以根据自身需求选择适合的临时解决方案或等待官方修复。