LinkedIn 強化 Kubernetes 身分安全
LinkedIn 公布一套 Kubernetes 身分安全架構，結合 cert-manager、SPIFFE 與內部驗證流程，自動簽發與輪替憑證，降低憑證外洩與人工維運負擔。
LinkedIn 用 cert-manager 建了一套 Kubernetes 身分系統，讓工作負載自動拿到憑證並完成驗證。
LinkedIn 在 5 月 22 日公開這套 Kubernetes 安全框架，核心是把每個 workload 綁定到可驗證的身分。系統會自動簽發、輪替與刪除憑證，也會做 attestation 和政策檢查，目標是減少身分偽冒與手動處理憑證的成本。
| 項目 | 數值 |
|---|---|
| 發布日期 | May 22 |
| 閱讀時間 | 8 min |
| 規模 | Thousands of nodes |
| Pod 規模 | Hundreds of thousands of pods per cluster |
發生了什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
LinkedIn 把 cert-manager 往前推了一步，讓它不只負責發證，還能處理 Kubernetes workload 的整個憑證生命週期。公司也加上 CSI driver，把憑證掛進容器，同時把私鑰留在 node 上，降低外洩風險。
這套設計分成兩條路徑：一條是給大多數服務用的 Fully Managed，另一條是給手動部署或外部系統用的 Self Serve。前者讓平台團隊統一控管，後者則保留彈性，避免所有例外都擠進同一套流程。
- 工作負載建立時就會拿到數位憑證。
- 加上 `spiffe: enabled` 標籤後，會觸發 webhook 自動注入。
- CSI driver 會為每個 workload 建立 CertificateRequest。
- Lipki-Controller 先查內部 Identity Registry，再決定是否簽發。
- Kyverno 規則限制誰能申請憑證。
LinkedIn 也把 SPIFFE 風格的身分、mutual TLS，以及 Java、Go、Rust 的內部 auth library 串起來。對應用團隊來說，很多憑證細節被藏到基礎設施層，部分 Java 框架還能熱更新 TLS context，憑證輪替時不必重啟服務。
為什麼重要
對開發者來說，這種做法最直接的影響是少碰憑證、少寫身分膠水碼。當安全預設被放進部署流程，團隊就不用為每個服務、job 或資料庫連線手工處理憑證與驗證邏輯。
對平台與維運團隊來說，真正的壓力在規模。LinkedIn 面對的是 thousands of nodes、每個 cluster 內 hundreds of thousands of pods 的環境，還要支援多 cluster job 與頻繁調度，代表憑證系統不能只「能用」，還得在高 churn 下保持低延遲與一致性。
這也反映出 Kubernetes 安全的方向正在變：靜態 secret 逐步讓位給 workload identity。當 attestation、政策引擎與可觀測性一起進場，開源元件就能被拼成企業級信任層，但前提是流程要夠自動化，否則安全只會變成另一層營運負擔。
LinkedIn 的訊號很清楚：在大型 Kubernetes 環境裡，憑證自動化已經不是附加功能，而是基礎設施本身。問題只剩一個——你的團隊還在手管 secret，還是已經把身分當成平台的一部分？