Flux2 项目中使用自定义 CA 证书解决 Helm 仓库 TLS 验证问题

问题背景

在企业环境中使用 Flux2 进行 GitOps 部署时，经常会遇到中间人代理（如 ZScaler）进行 SSL 流量检查的情况。这些安全代理会替换原始 TLS 证书，导致 Flux2 组件在访问外部 Helm 仓库时出现证书验证失败的问题。

典型错误表现

当 Flux2 的 source-controller 尝试从 Helm 仓库获取 chart 时，可能会出现两种类型的错误：

1. 获取 index.yaml 时的证书错误
2. 下载实际 chart 包时的证书错误

错误信息通常表现为：

tls: failed to verify certificate: x509: certificate signed by unknown authority

或

tls: failed to verify certificate: x509: certificate is valid for github.com, www.github.com, not prometheus-community.github.io

解决方案

1. 基础证书配置

最简单的解决方案是为 HelmRepository 资源指定证书 Secret：

apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: example
spec:
  certSecretRef:
    name: z-scaler-ca

证书 Secret 可以通过以下命令创建：

kubectl create secret generic z-scaler-ca --from-file=ca.crt=path/to/cert.crt -n flux-system

2. 深入解决方案：将证书注入系统信任库

基础方案可能无法解决所有问题，特别是当：

• 不同组件需要访问不同域名的资源
• 证书链比较复杂
• 需要长期稳定的解决方案

这时需要将企业根证书注入到 Flux2 控制器的系统信任库中。具体步骤如下：

2.1 创建 ConfigMap 存储证书

apiVersion: v1
kind: ConfigMap
metadata:
  name: z-scaler-ca
  namespace: flux-system
data:
  Company-Root-CA.crt: |
    -----BEGIN CERTIFICATE-----
    MII...
    -----END CERTIFICATE-----

2.2 修改 Flux2 控制器部署

通过 Kustomize 补丁方式修改控制器部署，添加证书挂载：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: source-controller
  namespace: flux-system
spec:
  template:
    spec:
      containers:
        - name: manager
          volumeMounts:
            - name: cert-volume
              mountPath: /etc/ssl/certs/Company-Root-CA.crt
              subPath: Company-Root-CA.crt
      initContainers:
        - name: init-certs
          image: debian
          command: ["sh", "-c", 'echo "$TRUSTED_CERT" > /var/tmp/Company-Root-CA.crt']
          env:
            - name: TRUSTED_CERT
              valueFrom:
                configMapKeyRef:
                  name: z-scaler-ca
                  key: Company-Root-CA.crt
          volumeMounts:
            - name: cert-volume
              mountPath: /var/tmp
      volumes:
        - name: cert-volume
          emptyDir: {}

2.3 安全注意事项

在实施此方案时，需要注意 Pod 安全策略：

1. 设置 securityContext.allowPrivilegeEscalation=false
2. 限制容器能力 securityContext.capabilities.drop=["ALL"]
3. 以非 root 用户运行 securityContext.runAsNonRoot=true
4. 配置 seccomp 策略 securityContext.seccompProfile.type=RuntimeDefault

方案验证

实施后可以通过以下方式验证：

1. 检查控制器 Pod 中证书文件是否存在：

kubectl exec -it source-controller-xxx -n flux-system -- ls -l /etc/ssl/certs/

2. 查看 HelmRepository 资源状态：

kubectl get helmrepositories -A

3. 检查 HelmRelease 资源状态：

kubectl get helmreleases -A

高级场景处理

对于某些特殊情况，如：

• Helm 仓库 index.yaml 和实际 chart 包位于不同域名
• 使用 GitHub Releases 作为 chart 存储

需要特别注意证书的通用性，可能需要将多个相关域名都加入信任。这种情况下，系统级的证书信任方案比单独为每个资源指定证书更为可靠。

总结

在企业环境中使用 Flux2 时，正确处理 TLS 证书验证是确保 GitOps 流程顺畅运行的关键。通过将企业根证书注入 Flux2 控制器的系统信任库，可以一劳永逸地解决各种证书验证问题，而无需为每个资源单独配置。这种方法不仅解决了 Helm 仓库访问问题，也为其他需要外部访问的 Flux2 组件提供了统一的证书管理方案。