前言

在前面我們有透過實戰篇，去盤點憑證。 部分原理還有待補充，這邊我們繼續完成內容。 關於那些憑證的期限，以及管理的手段。

為什麼需要進行替換？

• 憑證 和 Secret 都有有效期，如果忘記更新，服務會斷線 (TLS 過期、DB 連線失敗)。
• 定期更換，可以降低外洩風險。 如果真的不巧金鑰或憑證被偷走，透過輪替，可以定期讓那些資訊失效，使得攻擊者幹來的舊金鑰失效。
• 為了合規，很多標準（ISO 27001、PCI-DSS、HIPAA）都要求金鑰要定期更新。

Secret 的種類

在 OCP / K8s 中，Secret 常見的有：

• 應用層 Secret：DB 密碼、API Token、OAuth Secret。
• TLS 憑證 Secret：Ingress / Route TLS、Service Mesh 憑證。
• 叢集內建憑證：OCP API Server、etcd、kubelet、ingress-operator 管理的憑證。

在開始說明範例之前，先聊些基礎知識。

OCP Ingress Operator 的定位

自動管理 IngressController

• OCP 因為存在一個 Ingress Operator，專門管理叢集內的 IngressController（HAProxy Router）。 每個 IngressController 本質上就是一組 HAProxy Router Pod，跑在 openshift-ingress namespace。
• 並且 Router 處理外部流量進來 OCP 的 Route。

負責憑證與加密流量 (TLS)

• 憑證發行流程
  1. Ingress Operator 預設會建立一個 自簽 CA (ingress-ca)
  2. 用 自簽 CA (ingress-ca) 發行 Router 的 TLS 憑證。
  3. 預設憑證放到 router-certs-default Secret (openshift-ingress namespace)。
  4. 可以在 IngressController.spec.defaultCertificate 指定自己的憑證（例如公司 CA 或公有 CA）。

管理 Route 流量路由

• Route 是 OCP 的 Layer 7 HTTP(S) 負載平衡抽象物件。
• Ingress Operator 負責確保 Router Pod 正確解析 Route，並維持流量導向對應的 Service/Pod。

提供 HA

• Ingress Operator 會確保 Router Pod 數量符合 IngressController 規範（scaling）。
• Router Pod 通常以 DaemonSet 或 Deployment 方式在指定 Node 上跑，確保高可用性。

繼續回到更新輪替的方法

Secret Rotation 的做法

1. 手動更新流程說明 / 備份 / 替換 / 回滾

• 概念就是使用 oc create secret 或 oc replace secret 更新內容。
• 以下，是拿來更換 openshift 預設入口憑證的做法。 用來假設你的 OCP 入口使用的憑證和金鑰，使用了 default-ingress-crt secret。
• 這個是備份指令，先備份！！！！！！ 並且用指令檢查備份起來 cert 的東西能不能解。

  oc get secret default-ingress-crt -n openshift-ingress -o jsonpath='{.data.tls\.crt}' | base64 -d > ingress.crt
  oc get secret default-ingress-crt -n openshift-ingress -o jsonpath='{.data.tls\.key}' | base64 -d > ingress.key
  openssl x509 -in ingress.crt -noout -text
  

• 替換手法
  • 用新的憑證和金鑰覆蓋舊有設定
  • 指令會配置新的 crt 和 key 後，產生 yaml
  • 並使其 oc apply

  oc create secret tls ingress-crt \
    --cert=new.crt \
    --key=new.key \
    -n openshift-ingress \
    --dry-run=client -o yaml | oc apply -f -
  

• 當你衰衰衰，連三衰，種瓠仔生菜瓜，發生預期之外的事情要回滾
  • 利用前面備份好的東西，回滾

  oc create secret tls ingress-crt \
    --cert=ingress.crt \
    --key=ingress.key \
    -n openshift-ingress \
    --dry-run=client -o yaml | oc apply -f -
  

2. 自動更新

• cert-manager：自動幫你 Renew TLS 憑證，存回 Secret。
• Sealed Secrets (Bitnami)：GitOps 下 Secret 加密存放，換新金鑰時重產。
• External Secret Operator (ESO)：從 AWS Secrets Manager、HashiCorp Vault、Azure Key Vault 同步 Secret 到 OCP，並自動更新。
• OCP Operators：某些 Operator（如 ingress-operator、service-ca-operator）會自動幫你輪替憑證。

Key/Cert Rotation 流程

整理流程說明

1. 產生新憑證/金鑰（CA 或外部 KMS 發新）

   確認憑證誰發行：公司的網管？ 付錢給外面的公正第三方得到的？ 自簽憑證？

2. 更新叢集中的 Secret（透過 Operator 或 External Secret）

   上述的手動或自動流程

3. 應用程式 Reload Secret（Pod restart、Sidecar Reload、或透過熱更新機制）

   如何使更新生效？

4. 回收舊金鑰（避免同時存在太久）

   汰舊換新啦

Key Management

• 這裡更偏向 金鑰的全生命周期管理 (Key Lifecycle Management)：
  1. 建立 (Creation)：由可信任的 CA 或 KMS 生成。
  2. 儲存 (Storage)：避免明文，應存在 KMS、Vault、或 OCP Secret（Base64，但不是加密！建議搭配 KMS）。
  3. 存取控制 (Access Control)：用 RBAC 控制誰能讀取 Secret。
  4. 輪替 (Rotation)：定期更新、縮短有效期。
  5. 撤銷 (Revocation)：金鑰外洩時，立即停用舊憑證。
  6. 稽核 (Audit)：記錄誰存取過 Secret，符合合規。

結論

• 在 OCP 的實務建議:
  • TLS 憑證 → 交給 cert-manager 自動更新。
  • DB / API Key → 用 External Secret Operator (ESO)，連接 AWS Secrets Manager 或 HashiCorp Vault。

    分開放的意思

  • 核心 OCP 憑證（API Server、etcd） → 用 oc adm 或 Operator（例如 service-ca-operator）管理。
  • 敏感金鑰管理 → 搭配 HSM（Hardware Security Module）或雲端 KMS (AWS KMS, Azure Key Vault)。

    也是分開放的意思

  • GitOps 環境 → 搭配 Sealed Secrets，避免 Secret 以明文出現在 Git Repo。

    這個應該已經是顯學了，不要把機敏資料寫在原始碼中，除非故意要讓他被駭。