引 言
這是一個系列文章,我們將在本系列中探索Rancher使用TLS證書的不同方式,TLS,安全傳輸層協議,是用于保護網路通信的加密協議,它是目前已經棄用的安全套接層(SSL)的繼任者,
你可以從本系列中了解TLS如何集成到各種Rancher組件中以及如何準備環境以正確利用Rancher中的TLS,
為什么安全傳輸層協議(TLS)很重要?
Rancher在任何地方都可以使用TLS,因此,在安裝Rancher之前,確定TLS終止選項十分重要,
1、 確認你想要執行的TLS終止型別,有以下幾種型別:
-
自簽名,由Rancher終止(這是默認的)
-
Let’s Encrypt,由Rancher終止
-
自帶證書,由Rancher終止
-
外部TLS終止
2、 如果你選擇了自帶證書或外部TLS終止,那么請確保你有用于注冊證書的CA證書的副本(僅需cert,不需要密鑰),Rancher在執行操作時需要這一檔案,
3、 確保你知道Rancher要使用的主機名,這在安裝之后不可更改,
建議你通過閱讀檔案來了解更多的細節:
https://docs.rancher.cn/

什么組件需要安全傳輸層協議
對于任何企業軟體來說,你都需要在安裝和使用之前確定特定的要求,包括存盤要求、網路、在云端還是本地等等,在進行安裝之前,你必須得明確回答這些問題,
對于Rancher來說,考慮因素之一是TLS,必須了解并計劃使用Rancher進行TLS的方法,如此才能獲得能夠充分支持并且擁有良好功能的解決方案,
除了HTTPS安全之外,還有其他兩個地方也十分需要TLS:
1、 kubectl
2、 節點和集群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連接的集群(包括匯入的或其他方式)中,需要部署兩個作業負載:
1、cattle-cluster-agentDeployment
2、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/rancher/v2.x/en/installation/k8s-install/helm-rancher/
一旦你完成cert-manager的安裝,下一步是安裝rancher,使用自簽名證書是Rancher的默認設定,所以執行helm install時實際上只有一個強制性引數:
--set hostname=<YOUR.DNS.NAME>
該引數是強制性的,因為Rancher HA安裝不具有與單節點安裝相同的即時證書生成功能,因此,一旦你設定了主機名,該主機名將用于Rancher安裝的整個生命周期,所以你必須確保你的設定是正確的,
然后cert-manager將會生成一個證書,該證書作為一個secret存盤在cattle-system命名空間中,名為tls-rancher-ingress,
本文就到此結束啦,本系列的第二篇文章將會為大家介紹其他型別的TLS終止選項,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/41196.html
標籤:其他
