1. 概述
OpenShift 是由 Red Hat 推出的容器化应用平台。它在 Kubernetes 的基础上增加了许多定制组件，从而提升了开发者体验。这些组件包括内置的 CI/CD 流水线系统、容器镜像仓库、服务网格、以及内部的 证书颁发机构（CA） 服务等。
在本教程中，我们将重点介绍 OpenShift 中的 Service CA Operator，并通过一个实际的 Spring Boot 应用部署示例，演示其自动管理 SSL 证书的能力。
2. OpenShift 中的 Service CA Operator
为了在客户端与服务端之间安全传输数据，很多服务会选择通过 SSL/TLS 加密通道 提供服务。例如，HTTPS 就是运行在加密通道上的 HTTP 协议。要启用 SSL/TLS，服务端需要拥有 SSL 证书以及对应的公私钥对。
2.1. SSL 证书管理需求
出于安全考虑，SSL 证书通常不会设置过长的有效期，一般不超过五年，因此需要定期更换。证书的生命周期管理往往是许多组织运维中的一个痛点。
在标准的 Kubernetes 集群 中，证书管理通常由管理员自行处理。很多人会使用如 cert-manager 这类外部工具来协助管理证书生命周期。而 OpenShift 平台则内置了 Service CA Operator 来自动管理 SSL 证书的生成与轮换。
2.2. Service CA Operator 简介
Service CA Operator 是 OpenShift 中用于管理数字证书的核心组件。它在集群部署时自动生成一个自签名的 CA，并为请求证书的服务资源签发并轮换数字证书。
该 Operator 内部包含两个控制器，以支持证书管理的完整功能：
✅ serving cert signer
负责为带有特定注解的服务资源签发证书。
✅ configmap cabundle injector
用于将 CA 证书注入到指定的 ConfigMap 中，以便客户端使用。
下面我们将分别介绍这两个控制器的功能。
2.3. serving cert signer 控制器
该控制器负责为带有 service.beta.openshift.io/serving-cert-secret-name 注解的服务资源签发证书。
当你在服务资源中添加如下注解：
metadata:
annotations:
service.beta.openshift.io/serving-cert-secret-name: server-ssl-bundle
控制器会自动生成一张有效期为两年的证书和私钥，并将 tls.crt 和 tls.key 存储到名为 server-ssl-bundle 的 Secret 对象中。
更棒的是，该控制器还会在证书过期前自动轮换，无需手动干预。
2.4. configmap cabundle injector 控制器
该控制器负责将服务 CA 的证书注入到带有 service.beta.openshift.io/inject-cabundle=true 注解的 ConfigMap 中。
如果该 ConfigMap 已包含名为 service-ca.crt 的键，控制器会更新其内容为最新的 CA 证书。这样，客户端就可以通过读取该 ConfigMap 获取信任的 CA 证书，用于建立安全连接。
3. 实战：在 OpenShift 中演示 Service CA Operator 的使用
3.1. 启动 CodeReady Container (CRC) 集群
要快速体验 OpenShift，可以使用 CodeReady Container (CRC) 创建本地 OpenShift 集群。它几乎完整地复现了 OpenShift 的功能，适合开发和测试使用。
安装完成后，启动集群：
$ crc start
配置 oc 命令行工具连接集群：
$ eval $(crc oc-env)
$ oc login -u developer https://api.crc.testing:6443
创建一个新项目用于演示：
$ oc create-project ssl-rotate-demonstration
$ oc projects
3.2. 创建支持 HTTPS 的 Spring Boot 应用
创建一个 Spring Boot 项目，并添加如下配置，用于指定证书路径：
spring.ssl.bundle.pem:
server:
keystore:
certificate: ${CERT_PATH}/tls.crt
private-key: ${CERT_PATH}/tls.key
这样，我们就可以在部署时通过环境变量动态指定证书路径，而无需硬编码。
3.3. 部署 Spring Boot 应用
创建 Deployment 资源定义：
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: ssl-rotate-demonstration-app
spec:
selector:
matchLabels:
app.kubernetes.io/name: ssl-rotate-demonstration-app
template:
metadata:
labels:
app.kubernetes.io/name: ssl-rotate-demonstration-app
spec:
containers:
- image: example/ssl-rotate-demonstration-app:latest
name: ssl-rotate-demonstration-app
ports:
- containerPort: 8443
name: https
env:
- name: CERT_PATH
value: /opt/ssl
volumeMounts:
- mountPath: /opt/ssl
name: server-ssl-bundle
volumes:
- name: server-ssl-bundle
secret:
secretName: server-ssl-bundle
再创建 Service 资源定义：
# service.yaml
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/name: ssl-rotate-demonstration-app
annotations:
service.beta.openshift.io/serving-cert-secret-name: server-ssl-bundle
name: ssl-rotate-demonstration-service
spec:
ports:
- name: https
port: 8443
targetPort: 8443
selector:
app.kubernetes.io/name: ssl-rotate-demonstration-app
type: ClusterIP
部署资源：
$ oc apply -f service.yaml
$ oc apply -f deployment.yaml
3.4. 验证部署
查看生成的 Secret：
$ oc describe secret server-ssl-bundle
输出结果中可以看到：
tls.crt和tls.key已生成service.beta.openshift.io/expiry标注显示证书有效期为两年
这说明 Service CA Operator 已成功生成证书并存储到 Secret 中，Spring Boot 应用可通过该路径加载证书。
4. 手动轮换 SSL 证书
虽然 Service CA Operator 会自动轮换即将过期的证书，但如果你需要手动强制轮换（例如私钥泄露），只需删除对应的 Secret：
$ oc delete secret server-ssl-bundle
Operator 会自动重新生成新的证书并更新 Secret：
$ oc describe secret server-ssl-bundle
你将看到 expiry 时间已被更新。
⚠️ 注意：Secret 删除后，Pod 会触发重建以加载新证书。建议确保应用具备优雅重启能力，避免服务中断。
5. 总结
OpenShift 在 Kubernetes 的基础上集成了丰富的开发与运维工具，极大提升了开发效率。其中的 Service CA Operator 能自动完成 SSL 证书的签发与轮换，省去了手动管理证书的繁琐操作。
通过本教程的实战示例，我们演示了如何利用 Service CA Operator 在 Spring Boot 应用中自动获取和使用 SSL 证书，从而实现 HTTPS 服务，并支持自动证书轮换。
✅ 关键点总结：
- OpenShift 内置 Service CA Operator，支持自动证书签发与轮换
- 使用
service.beta.openshift.io/serving-cert-secret-name注解触发证书生成 - 证书有效期为两年，到期前自动轮换
- 可通过删除 Secret 强制刷新证书
- 适用于需要 HTTPS 服务的微服务、API 网关等场景
希望这篇文章能帮助你更好地理解 OpenShift 的证书管理机制，并在实际项目中灵活运用。