如何在 Kubernetes 中生成自簽名證書？

---

簡介

在當今的數字時代，網路安全是企業和組織的首要任務。資料洩露和網路攻擊可能導致重大的經濟損失和聲譽損害。Kubernetes 是一種流行的容器編排系統，許多組織使用它來管理其容器化應用程式。

但是，隨著容器數量的增加，確保容器安全已成為一項重大挑戰。自簽名證書提供了一種簡單且經濟高效的方式來建立 Kubernetes 不同元件（包括 API 伺服器、etcd 和 kubelet）之間的安全通訊。

為 Kubernetes 生成自簽名證書

使用 OpenSSL 或其他工具為 Kubernetes 生成自簽名證書的分步指南

一旦您對 SSL/TLS 證書及其在保護網路流量中的作用有了基本的瞭解，您就可以開始為您的 Kubernetes 環境生成自己的自簽名證書。生成自簽名證書的過程相對簡單，但具體步驟可能因您使用的工具而異。

在本節中，我們將介紹使用 OpenSSL 或其他工具為 Kubernetes 生成自簽名證書所涉及的常規步驟。第一步是生成一個私鑰，該私鑰將用於簽署您的證書。

您可以透過執行以下命令生成此私鑰：

openssl genpkey -algorithm RSA -out server.key 

此命令將生成一個 RSA 私鑰並將其儲存到名為“server.key”的檔案中。您應妥善保管此檔案，因為它將用於簽署由此金鑰生成的所有證書。

接下來，您需要生成一個證書籤名請求 (CSR)，該請求可以傳送到受信任的第三方證書頒發機構 (CA) 或由您自己的私有 CA 簽署。要生成 CSR，請執行以下命令：

openssl req -new -key server.key -out server.csr 

此命令將提示您輸入有關您的組織和網站的一些資訊。請確保準確填寫所有必填欄位，因為這些詳細資訊將包含在您的最終證書中。

生成 CSR 後，您就可以建立自簽名證書了。為此，請執行以下命令：

openssl x509 -req -days 365 -in server.csr \ -signkey server.key -out server.crt 

此命令生成一個符合 x509 標準的證書，該證書有效期為一年 (-days 365)，並由第一步生成的私鑰簽署。生成的證書將儲存到名為“server.crt”的檔案中。

生成證書時涉及的不同引數的說明，例如公用名稱、組織名稱和過期日期

為 Kubernetes 生成自簽名證書時，您需要指定一些用於識別您的組織和網站的引數。一些最重要的引數包括：

• 公用名稱 - 這是您網站或服務的完全限定域名 (FQDN)。例如，如果您的網站是 www.example.com，則此名稱將是您的公用名稱。

• 組織名稱 - 這是您組織的法人名稱。- 國家程式碼：這應該是代表您組織所在位置的兩位國家程式碼。

• 過期日期 - 指定證書在必須續訂之前有效的期限。請注意，必須準確輸入這些引數，因為它們將顯示在您的最終證書中。

如果在輸入此資訊時出現任何錯誤或錯別字，可能會導致以後證書驗證出現問題。除了這些必填引數之外，根據您的具體需求，還可以將其他一些可選引數包含在自簽名證書中。

配置 Kubernetes 以使用自簽名證書

現在我們已經生成了自簽名證書，我們需要配置 Kubernetes 以使用它。如果沒有此步驟，API 伺服器將無法識別我們新生成的證書，並且不允許 Kubernetes 元件之間進行安全通訊。在本節中，我們將討論如何配置 Kubernetes 以使用新生成的自簽名證書。

更新 Kubeconfig 檔案

配置 Kubernetes 以使用自簽名證書的一種方法是更新 kubectl 和其他命令列工具使用的 kubeconfig 檔案。預設情況下，這些檔案位於使用者的主目錄下的 ~/.kube/config 中。

要使用新證書更新這些檔案，我們必須新增幾行程式碼來指定新生成的自簽名證書的路徑和名稱。為此，請在文字編輯器（如 vim 或 nano）中開啟您的 kubeconfig 檔案，並查詢 cluster 部分。

在此部分下，新增一個名為“certificate-authority-data”的新欄位，並將它的值設定為新生成的自簽名證書的 base64 編碼內容。完成此步驟後，所有 kubectl（以及類似）命令都將使用您的新證書。

配置 API 伺服器標誌

配置 Kubernetes 以使用自簽名證書的另一種方法是透過 API 伺服器標誌。當多個叢集在不同的節點上執行或當使用負載均衡器進行 HA 設定時，此方法非常有用，因為它允許您在每個節點上指定證書，而無需更改任何 kubeconfig 檔案。要實現此方法，您必須指定指向金鑰和證書檔案儲存位置的標誌。

如果您覺得更方便，也可以使用 --tls-cert-file 標誌指定包含金鑰和證書的檔名，因為此方法比為每個檔案使用單獨的檔案路徑要短得多，但靈活性也較差。將這些標誌新增到您的配置檔案後，Kubernetes 將開始使用新生成的自簽名證書。

在 Kubernetes 中使用自簽名證書的最佳實踐

瞭解自簽名證書的風險

雖然自簽名證書可以成為保護 Kubernetes 叢集的有用工具，但它們也存在一些固有的風險。由於這些型別的證書未由受信任的第三方證書頒發機構 (CA) 簽署，因此存在更大的安全漏洞可能性。

例如，如果攻擊者能夠獲取自簽名證書金鑰，則他們可能會攔截和修改叢集中兩個節點之間的流量。為了降低這些風險，在 Kubernetes 中使用自簽名證書時，務必遵循最佳實踐。

其中一項實踐是限制自簽名證書的使用範圍。例如，與其在整個叢集中使用單個自簽名證書，不如為叢集中的每個節點或服務生成唯一的證書。

有關確保適當安全措施的提示

除了限制自簽名證書的使用範圍外，還可以採取其他步驟來確保在 Kubernetes 中使用這些型別的證書時採取適當的安全措施。其中一個步驟是定期輪換和重新生成每個證書的新金鑰。

這有助於防止攻擊者使用受損金鑰解密先前攔截的流量。另一個重要步驟是確保叢集中的所有節點和服務都具有驗證對等連線所需的任何必要的根 CA 證書的最新副本。

結論

在本文中，我們探討了為 Kubernetes 生成自簽名證書並配置它的過程，以確保 Kubernetes 流量是加密和安全的。我們瞭解了 SSL/TLS 證書、可用的不同型別以及自簽名證書與商業證書的區別。

我們還詳細討論瞭如何使用 OpenSSL 或其他工具為 Kubernetes 生成自簽名證書。此外，我們還介紹瞭如何配置 Kubernetes 以使用此新生成的證書。