1. 问题现象与背景分析最近在Harvester平台上部署RKE2集群时遇到一个典型问题当Rancher使用私有CACertificate Authority时集群配置会失败。这个错误在日志中通常表现为x509证书验证失败具体报错可能是x509: certificate signed by unknown authority。这种情况在企业内部环境中特别常见因为很多组织都会使用私有CA来签发内部证书。Harvester作为新兴的HCI超融合基础设施平台与Rancher的集成越来越紧密但私有CA的配置细节却容易成为绊脚石。注意这个问题不仅限于Harvester平台任何使用私有CA的Rancher环境在配置RKE2集群时都可能遇到类似问题。2. 核心问题拆解2.1 证书链信任机制解析问题的根源在于RKE2节点不信任Rancher使用的私有CA。在TLS通信中客户端需要验证服务器证书的有效性这依赖于证书链的完整性和可信度。当使用公开CA如Lets Encrypt时操作系统通常预置了这些CA的根证书。但私有CA的根证书不会自动被信任。2.2 RKE2集群启动流程中的证书验证RKE2集群启动时会从Rancher获取bootstrap配置这个过程中涉及多个HTTPS请求节点向Rancher API请求集群配置下载必要的镜像和charts建立与Rancher的持续通信通道如果其中任何一个环节的证书验证失败整个流程就会中断。3. 解决方案与实操步骤3.1 准备私有CA证书首先需要获取你的私有CA的根证书通常是.crt或.pem格式。如果你不确定如何获取可以咨询你的安全团队或查看内部PKI文档。# 示例查看证书内容 openssl x509 -in ca.crt -text -noout3.2 在Harvester节点上配置CA信任对于基于openSUSE的Harvester节点需要将CA证书添加到系统信任库# 将CA证书复制到系统证书目录 sudo cp ca.crt /etc/pki/trust/anchors/ # 更新证书信任库 sudo update-ca-certificates验证是否添加成功openssl verify -CApath /etc/ssl/certs/ ca.crt3.3 配置RKE2信任私有CA有两种主要方法可以让RKE2信任私有CA方法一通过RKE2配置文件创建或编辑RKE2的配置文件通常是/etc/rancher/rke2/config.yamltls-san: - rancher.yourdomain.com cni: cilium private-registry: /etc/rancher/rke2/registries.yaml # 添加以下内容 cloud-provider-name: harvester kubelet-arg: - volume-plugin-dir/var/lib/kubelet/volumeplugins # 关键配置指定额外信任的证书目录 additional-trust-bundle: /etc/ssl/certs/ca-certificates.crt方法二通过Rancher UI配置登录Rancher管理界面导航到集群管理 - 驱动 - RKE2在集群模板中找到高级选项在Additional Trusted CA字段上传你的CA证书3.4 验证配置部署后检查RKE2节点的证书信任情况# 检查kubelet日志 journalctl -u rke2-server -f # 验证API服务器证书 curl -v --cacert /etc/ssl/certs/ca-certificates.crt https://rancher.yourdomain.com4. 常见问题与排查技巧4.1 证书链不完整如果私有CA使用了中间证书必须确保完整的证书链被配置。可以通过以下命令检查openssl s_client -showcerts -connect rancher.yourdomain.com:443如果发现证书链不完整需要将中间证书与根证书合并cat intermediate.crt root.crt fullchain.crt4.2 证书过期或时间不同步节点时间不同步会导致证书验证失败即使证书本身是有效的。确保所有节点时间同步sudo chronyc sources sudo timedatectl set-ntp true4.3 容器运行时证书信任即使主机系统信任了CA容器内部可能仍然不信任。对于Docker需要额外配置sudo mkdir -p /etc/docker/certs.d/rancher.yourdomain.com sudo cp ca.crt /etc/docker/certs.d/rancher.yourdomain.com/ca.crt sudo systemctl restart docker对于containerd配置略有不同sudo mkdir -p /etc/containerd/certs.d/rancher.yourdomain.com sudo cp ca.crt /etc/containerd/certs.d/rancher.yourdomain.com/ca.crt sudo systemctl restart containerd5. 高级配置与优化5.1 自动化证书分发在大规模部署中手动配置每个节点的证书不现实。可以考虑以下自动化方案使用Harvester的cloud-init功能在节点初始化时注入证书通过配置管理工具如Ansible批量部署创建自定义的Harvester镜像预置CA证书5.2 证书轮换策略私有CA证书也有有效期需要建立轮换机制监控证书过期时间可以使用Prometheus的ssl_exporter提前部署新证书保持旧证书直到所有节点更新完成使用证书管理工具如Vault自动化签发和部署5.3 多集群统一证书管理如果你管理多个Rancher环境可以考虑使用相同的私有CA签发所有环境证书在Harvester上创建全局的证书配置通过Rancher的Fleet管理跨集群证书6. 性能考量与最佳实践6.1 证书类型选择选择适当的证书类型可以提升性能ECDSA证书比RSA证书验证速度更快合理设置密钥长度ECDSA P-256足够安全避免过长的证书链最好不超过3层6.2 TLS会话恢复启用TLS会话恢复可以减少握手开销# 在RKE2配置中添加 kube-apiserver-arg: - tls-min-versionVersionTLS12 - tls-cipher-suitesTLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA2566.3 监控与告警建立完善的监控体系监控证书过期时间提前30天告警监控TLS握手失败率监控证书撤销状态如果使用CRL7. 安全加固建议7.1 证书吊销检查如果私有CA支持CRL证书吊销列表或OCSP在线证书状态协议应该启用验证# 在RKE2配置中添加 kube-apiserver-arg: - tls-cert-file/etc/rancher/ssl/server.crt - tls-private-key-file/etc/rancher/ssl/server.key - tls-ca-file/etc/rancher/ssl/ca.crt - tls-crl-file/etc/rancher/ssl/crl.pem # 如果使用CRL7.2 证书范围最小化为不同服务使用不同的证书Rancher UI使用独立证书Kubernetes API使用独立证书每个集群使用不同的证书7.3 证书透明度日志考虑部署私有证书透明度日志CT log虽然这是高级话题但对于严格的安全环境很有价值。8. 故障排查手册8.1 诊断证书问题使用openssl进行详细诊断openssl s_client -connect rancher.yourdomain.com:443 -CAfile /etc/ssl/certs/ca-certificates.crt -status8.2 日志分析要点关键日志位置和内容RKE2服务日志journalctl -u rke2-server -fKubelet日志journalctl -u kubelet -fContainerd日志journalctl -u containerd -f查找关键词x509, certificate, TLS, handshake, failed8.3 网络抓包分析当其他方法无法确定问题时可以尝试抓包sudo tcpdump -i any -w rancher.pcap port 443然后用Wireshark分析TLS握手过程。9. 替代方案比较9.1 使用公开CA如果安全策略允许可以考虑使用Lets Encrypt签发证书通过DNS挑战验证所有权配置自动续期优点无需管理CA兼容性好 缺点需要公共DNS记录证书有效期短90天9.2 使用服务网格管理证书对于高级用户可以考虑部署Istio或Linkerd服务网格通过服务网格管理服务间TLS使用mesh内部CA优点细粒度的证书管理 缺点增加系统复杂度10. 长期维护策略10.1 文档化证书架构建立详细的文档记录CA层次结构证书用途和范围续期和吊销流程10.2 定期审计每季度进行证书清单核对密钥存储检查访问控制审查10.3 灾难恢复计划为CA准备灾难恢复方案安全备份CA密钥定义恢复流程定期测试恢复过程在实际操作中我发现证书问题往往不是技术本身复杂而是组织流程不清晰导致的。建议建立一个跨团队的证书管理小组包括安全、运维和开发代表定期审查证书策略和实现。