云原生ssl证书改造核心是自动化生命周期管理，而非单纯换证：通过ingress/gateway统一tls终止，用cert-manager或certbot+云api自动签发续期，内网服务采用私有ca体系，并配套hsts、tls策略与证书监控实现安全闭环。
云原生环境下的 SSL 证书改造，核心不是“换证书”，而是把证书生命周期管理从人工运维模式，升级为与容器编排、服务网格、CI/CD 深度集成的自动化流程。重点在于解耦、集中、可编程。
用 Ingress 或 Gateway 统一终止 HTTPS
避免在每个 Pod 或应用里硬编码证书——这是云原生最典型的反模式。应由入口层统一处理 TLS：
- 在 Kubernetes 中，使用 Ingress（配合 nginx-ingress、traefik）或更现代的 Gateway API（如 envoy-gateway、istio gateway）作为 TLS 终结点；
- 证书直接绑定到 Ingress/Gateway 资源上，通过
tls.secretName引用集群内的Secret； - 后端服务保持 HTTP 内网通信，既简化应用逻辑，又便于审计和策略控制。
证书自动签发与轮换：Certbot + ACME 或 cert-manager
手动更新证书在容器化环境中不可持续。推荐两种主流方式：
-
cert-manager（K8s 原生首选）：部署后，通过
ClusterIssuer配置 Let’s Encrypt 或私有 CA；再用certificate资源声明域名，自动申请、续期、注入 Secret； - Certbot + CLB/ALB（公有云场景）：在跳板机或专用 Job 中运行 Certbot 获取证书，再调用云厂商 API（如腾讯云 LB、阿里云 ALB）上传并绑定，实现证书与负载均衡器联动；
- 无论哪种方式，都需确保 DNS 或 HTTP 挑战可达——内网服务建议搭配自建 ACME CA（如 smallstep 或 boulder），配合内部 DNS 或 Service IP 自验证。
内网服务（如 Harbor、Prometheus）用自签名 CA 体系
面向集群内部的 HTTPS 服务（非公网暴露），不依赖公网 CA，而应构建可控的私有信任链：
- 用 OpenSSL 或 cfssl 生成根 CA 和中间 CA；
- 为 Harbor、GitLab、Grafana 等服务签发服务器证书，并将根 CA 证书分发至所有节点的系统信任库（
/usr/local/share/ca-certificates/）及 containerd/Docker 的 certs.d 目录； - 配合 Helm Chart 或 Kustomize，把证书 Secret 注入对应 Deployment，并设置
volumeMounts挂载证书路径； - 关键点：CA 证书必须提前预置，否则
docker pull或kubectl apply会因证书不受信失败。
安全加固与可观测性闭环
证书只是起点，还需配套机制保障长期可用与合规：
- 启用 HSTS 头（通过 Ingress annotation 或 Envoy filter），强制浏览器走 HTTPS；
- 配置 TLS 版本与加密套件（如禁用 TLS 1.0/1.1，仅允许 TLS 1.2+ 和 AEAD 密码）；
- 用 Prometheus + cert-manager-webhook 或自定义 exporter 监控证书剩余有效期，触发告警（如
- 定期审计 Secret 权限（
rbac.authorization.k8s.io/v1控制谁可读取证书私钥）。
