服务器 SSL 证书云原生改造如何做

云原生SSL证书改造核心是自动化生命周期管理，而非单纯换证：通过Ingress/Gateway统一TLS终止，用cert-manager或Certbot+云API自动签发续期，内网服务采用私有CA体系，并配套HSTS、TLS策略与证书监控实现安全闭环。

云原生环境下的 SSL 证书改造，核心不是“换证书”，而是把证书生命周期管理从人工运维模式，升级为与容器编排、服务网格、CI/CD 深度集成的自动化流程。重点在于解耦、集中、可编程。

用 Ingress 或 Gateway 统一终止 HTTPS

避免在每个 Pod 或应用里硬编码证书——这是云原生最典型的反模式。应由入口层统一处理 TLS：

1. 在 Kubernetes 中，使用 Ingress（配合 nginx-ingress、traefik）或更现代的 Gateway API（如 envoy-gateway、istio gateway）作为 TLS 终结点；
2. 证书直接绑定到 Ingress/Gateway 资源上，通过 tls.secretName 引用集群内的 Secret；
3. 后端服务保持 HTTP 内网通信，既简化应用逻辑，又便于审计和策略控制。

证书自动签发与轮换：Certbot + ACME 或 cert-manager

手动更新证书在容器化环境中不可持续。推荐两种主流方式：

1. cert-manager（K8s 原生首选）：部署后，通过 ClusterIssuer 配置 Let’s Encrypt 或私有 CA；再用 certificate 资源声明域名，自动申请、续期、注入 Secret；
2. Certbot + CLB/ALB（公有云场景）：在跳板机或专用 Job 中运行 Certbot 获取证书，再调用云厂商 API（如腾讯云 LB、阿里云 ALB）上传并绑定，实现证书与负载均衡器联动；
3. 无论哪种方式，都需确保 DNS 或 HTTP 挑战可达——内网服务建议搭配自建 ACME CA（如 smallstep 或 boulder），配合内部 DNS 或 Service IP 自验证。

内网服务（如 Harbor、Prometheus）用自签名 CA 体系

面向集群内部的 HTTPS 服务（非公网暴露），不依赖公网 CA，而应构建可控的私有信任链：

1. 用 OpenSSL 或 cfssl 生成根 CA 和中间 CA；
2. 为 Harbor、GitLab、Grafana 等服务签发服务器证书，并将根 CA 证书分发至所有节点的系统信任库（/usr/local/share/ca-certificates/）及 containerd/Docker 的 certs.d 目录；
3. 配合 Helm Chart 或 Kustomize，把证书 Secret 注入对应 Deployment，并设置 volumeMounts 挂载证书路径；
4. 关键点：CA 证书必须提前预置，否则 docker pull 或 kubectl apply 会因证书不受信失败。

安全加固与可观测性闭环

证书只是起点，还需配套机制保障长期可用与合规：

1. 启用 HSTS 头（通过 Ingress annotation 或 Envoy filter），强制浏览器走 HTTPS；
2. 配置 TLS 版本与加密套件（如禁用 TLS 1.0/1.1，仅允许 TLS 1.2+ 和 AEAD 密码）；
3. 用 Prometheus + cert-manager-webhook 或自定义 exporter 监控证书剩余有效期，触发告警（如
4. 定期审计 Secret 权限（rbac.authorization.k8s.io/v1 控制谁可读取证书私钥）。