TLS使用指南（一）：如何在Rancher 2.x中進行TLS Termination？

引 言

這是一個系列文章，咱們將在本系列中探索Rancher使用TLS證書的不一樣方式。TLS，安全傳輸層協議，是用於保護網絡通訊的加密協議。它是目前已經棄用的安全套接層（SSL）的繼任者。

你能夠從本系列中瞭解TLS如何集成到各類Rancher組件中以及如何準備環境以正確利用Rancher中的TLS。

爲何安全傳輸層協議（TLS）很重要？

Rancher在任何地方均可以使用TLS。所以，在安裝Rancher以前，肯定TLS終止選項十分重要。

一、 確認你想要執行的TLS終止類型，有如下幾種類型：

• 自簽名，由Rancher終止（這是默認的）
• Let’s Encrypt，由Rancher終止
• 自帶證書，由Rancher終止
• 外部TLS終止

二、 若是你選擇了自帶證書或外部TLS終止，那麼請確保你有用於註冊證書的CA證書的副本（僅需cert，不須要密鑰）。Rancher在執行操做時須要這一文件。

三、 確保你知道Rancher要使用的主機名。這在安裝以後不可更改。

建議你經過閱讀文檔來了解更多的細節：

https://docs.rancher.cn/

什麼組件須要安全傳輸層協議

對於任何企業軟件來講，你都須要在安裝和使用以前肯定特定的要求，包括存儲要求、網絡、在雲端仍是本地等等。在進行安裝以前，你必須得明確回答這些問題。

對於Rancher來講，考慮因素之一是TLS。必須瞭解並計劃使用Rancher進行TLS的方法，如此才能得到可以充分支持而且擁有良好功能的解決方案。

除了HTTPS安全以外，還有其餘兩個地方也十分須要TLS：

一、 kubectl

二、 節點和集羣agent通訊

注意，並不止以上兩個地方會使用到TLS，只是上述兩個地方更爲常見。

理解kubectl TLS

首先，咱們來看一下示例kubeconfig文件：

apiVersion: v1
kind: Config
clusters:
\- name: "sample"
  cluster:
    server: "https://rancher.example.org/k8s/clusters/c-1234"
    certificate-authority-data: "LS0t..."

特別注意certificate-authority-data的存在。該字段是CA證書的base64編碼版本，這一CA證書可用於對Kubernetes API服務器提供的TLS證書進行簽名。或者是Rancher在代理調用kube-apiserver時提供的TLS證書。

爲何這個如此重要呢？由於kubectl使用certificate-authority-data來確保是你（而不是冒名頂替者）正在鏈接到正確的集羣。若是服務器提供的證書還沒有由certificate-authority-data中的證書籤名，那麼kubectl會警告你而且退出。基本上，你不會遭受MITM（中間人）攻擊。

certificate-authority-data中的值來自kube-ca的CA證書（非Rancher集羣或使用受權集羣端點的Rancher集羣），或者是Rancher CA證書（任意Rancher集羣）。

請務必在此字段中輸入正確的值，不然kubectl不會驗證與你的Kubernetes集羣的鏈接。這就是爲何在設置Rancher時須要正確配置TLS。

理解節點和集羣Agent通訊

在任意Rancher鏈接的集羣（包括導入的或其餘方式）中，須要部署兩個工做負載：

一、cattle-cluster-agentDeployment

二、cattle-node-agentDeployment

每一個工做負載執行一個特定的功能。總之，這兩個agent鏈接到Rancher的API並在tcp/443上創建安全的websocket鏈接。而後，該websocket鏈接會用於Rancher與託管的節點或集羣之間的雙向通訊。

集羣agent鏈接到託管集羣的Kubernetes API，這使Rancher能夠經過websocket隧道執行API操做。當執行集羣操做時（如升級、ectd快照等），節點agent將與RKE集羣中的節點進行交互。

這兩個agent都使用稱爲「CA checksum」的配置值，該配置值將做爲環境變量以CATTLE\_CA\_CHECKSUM的形式傳遞給Pod。該值須要與kubectl相同——確保鏈接到正確的端點並方式MITM的發生。可是，校驗和的工做原理略有不一樣。

cattle agent的CA checksum能夠厭憎agent是否鏈接到Rancher API的正確實例。因爲Rancher使用TLS保護其HTTPS API端點，所以agent容器可使用此校驗和來驗證API端點提供的TLS證書是否正確。

其次，CATTLE\_CA\_CHECKSUM未配置爲CA證書的base64編碼副本。相反，Rancher會生成CA證書的sha256校驗和，該證書用於簽署Rancher TLS證書，並將該值放入CATTLE\_CA\_CHECKSUM字段中。結果以下：

CATTLE\_CA\_CHECKSUM=b0af09b35ef086fcfc21e990fbd750720abe5c811dbea3ae40fe050a67f0bdb0e

當一個Rancher集羣或節點agent調用Rancher API，它會將CA證書與其在Deployment和DaemonSet中配置的那一個進行比較。若是它們匹配，通訊則會創建起來。

安全傳輸層協議（TLS）終止(termination)

當安裝Rancher時有如下4種主要方式來終止TLS：

• 使用Rancher的自簽名證書
• 使用Let’s Encrypt
• 自帶證書
• 外部TLS終止

每種方法都有特定的要求，須要在具體操做中進行權衡。

使用Rancher的自簽名證書

在終止TLS的四個選項中，這個多是最簡單的。在HA和單節點安裝方案中，這也是Rancher的默認選項。也就是說，經過不將任何TLS特定的參數傳遞給helm install或docker run，來進行安裝。

安裝後，Rancher會生成一個CA證書（CN=cattle-ca），而且使用該證書爲其自身證書籤名。根據你執行的安裝類型，自簽名證書的工做方式會有所不一樣。

單節點安裝

容器啓動後，設置前，Rancher在443端口上響應任意HTTPS請求，不管其目標Host值如何。這是如何成爲可能的呢？

在這一狀態下，Rancher會爲你到達的任何主機名自動生成一個證書。若是是一個IP（如10.11.12.13），那麼Rancher會爲該IP生成一個自簽名（使用cattle-ca）證書。若是是以一個主機名（如my-rancher.example.org）到達此新的Rancher安裝目錄，一樣也會以相同的方式生成一個自簽名證書。

在Rancher使用單個證書以前，你須要完成設置步驟（設置管理員密碼並確認Rancher主機名）。該證書對於在Rancher初始設置期間配置的主機名有效。

HA安裝

在HA安裝場景下，自簽名證書須要你安裝一個名爲cert-manager的應用程序。與單節點Rancher管理CA證書自己不一樣，HA rancher使用cert-manager來處理證書的生命週期。你能夠根據如下指引將cert-manager安裝到你準備好的Kubernetes集羣中：

https://rancher.com/docs/ranc...

一旦你完成cert-manager的安裝，下一步是安裝rancher。使用自簽名證書是Rancher的默認設置，因此執行helm install時實際上只有一個強制性參數：

--set hostname=<YOUR.DNS.NAME>

該參數是強制性的，由於Rancher HA安裝不具備與單節點安裝相同的即時證書生成功能。所以，一旦你設置了主機名，該主機名將用於Rancher安裝的整個生命週期。因此你必須確保你的設置是正確的。

而後cert-manager將會生成一個證書，該證書做爲一個secret存儲在cattle-system命名空間中，名爲tls-rancher-ingress。

本文就到此結束啦，本系列的第二篇文章將會爲你們介紹其餘類型的TLS終止選項。