Knative Serving证书管理器配置问题分析与解决方案

问题背景

在Knative Serving 1.15.0版本中，当用户尝试为系统配置Cert-Manager时，发现无法为不同类型的证书颁发者设置独立的引用配置。具体表现为：当用户在config-certmanager配置中设置issuerRef、clusterLocalIssuerRef和systemInternalIssuerRef这三个字段时，系统会将它们强制设置为相同的值，失去了预期的灵活性。

技术细节分析

证书颁发者配置的作用

在Knative Serving中，Cert-Manager集成提供了三种证书颁发者配置选项：

1. issuerRef：用于常规服务的证书颁发
2. clusterLocalIssuerRef：用于集群本地服务的证书颁发
3. systemInternalIssuerRef：用于系统内部组件的证书颁发

这三种配置本应允许用户为不同场景指定不同的证书颁发策略，例如：

• 生产环境使用Let's Encrypt等公共CA
• 内部服务使用自签名证书
• 系统组件使用特定CA

问题根源

通过代码分析发现，问题出在配置解析逻辑上。当前实现中，当任一字段被设置时，系统会错误地将该值复制到其他两个字段，导致配置覆盖。这种实现方式违背了设计初衷，限制了用户对不同类型证书颁发策略的精细控制。

影响范围

此问题会影响以下场景：

1. 需要为公开服务、内部服务和系统组件使用不同CA策略的环境
2. 需要区分生产证书和测试证书的部署
3. 需要为不同安全级别服务设置不同证书策略的场景

解决方案

临时解决方案

目前用户可以通过以下方式规避问题：

1. 统一使用相同的证书颁发者
2. 手动创建证书资源绕过自动证书管理

根本解决方案

修复方案需要修改配置解析逻辑，确保：

1. 每个字段能够独立设置
2. 未设置的字段保持默认值
3. 配置验证逻辑正确处理独立配置

最佳实践建议

当此问题修复后，建议用户采用以下配置策略：

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
spec:
  config:
    certmanager: 
      "issuerRef": |
        kind: ClusterIssuer
        name: letsencrypt-prod
      "clusterLocalIssuerRef": |
        kind: ClusterIssuer
        name: internal-ca
      "systemInternalIssuerRef": |
        kind: ClusterIssuer
        name: system-ca

这种配置方式可以实现：

• 公开服务使用公共可信CA
• 内部服务使用组织内部CA
• 系统组件使用专用CA

总结