Helm安全安裝

安全安裝

Helm是一款強大而靈活的Kubernetes軟體包管理和運維工具。使用默認安裝命令helm init- 可以快速輕鬆地安裝它和 Tiller，與Helm相對應的服務端組件。

但是，默認安裝沒有啟用任何安全配置。使用這種類型的安裝在下面的場景下是完全合適的，在沒有安全問題或幾乎沒有安全問題的群集時可以使用這種安裝方式，例如使用Minikube進行本地開發，或者使用在專用網路中，安全性良好且無數據共享或無其他用戶或團隊。如果是這種情況，那麼默認安裝很合適，但請記住：權力越大，責任越大。決定使用默認安裝時始終要注意相應的安全問題。

誰需要安全配置？

對於以下類型的集群，我們強烈建議使用正確的安全配置應用於Helm和Tiller，以確保集群，集群中的數據以及它所連接的網路的安全性。

• 暴露於不受控制的網路環境的群集：不受信任的網路參與者可以訪問群集，也可以訪問網路環境的不受信任的應用程序。
• 許多人使用的群集 - 多租戶群集 - 作為共享環境
• 有權訪問或使用高價值數據或任何類型網路的群集

通常，像這樣的環境被稱為 生產等級 或 生產質量 的環境，因為任何因濫用集群而對任何公司造成的損害對於客戶，對公司本身或者兩者都是深遠的。一旦損害風險變得足夠高，無論實際風險如何，都需要確保集群的安全完整性。

要為環境正確配置安裝，必須：

• 了解群集的安全上下文
• 選擇合適的helm安裝的最佳實踐

以下假定有一個Kubernetes配置文件（一個kubeconfig文件），或者有一個用於訪問群集的文件。

了解群集的安全上下文

helm init將Tiller安裝到kube-system名稱空間中的集群中，而不應用任何RBAC規則。這適用於本地開發和其他私人場景，因為它可以讓立即開始工作。它還使你能夠繼續使用沒有基於角色的訪問控制（RBAC）支持的Kubernetes群集來運行Helm，直到可以將工作負載移動到更新的Kubernetes版本。

在Tiller安全安裝時，需要考慮四個主要方面：

1. 基於角色的訪問控制或RBAC
2. Tiller的gRPC端點及Helm的使用情況
3. Tiller的release信息
4. Helm harts

RBAC

Kubernetes的最新版本採用基於角色的訪問控制（或RBAC）系統（與現代操作系統一樣），以幫助緩解證書被濫用或存在錯誤時可能造成的損害。即使在身份被劫持的情況下，這個身份在受控空間也只有這麼多的許可權。這有效地增加了一層安全性，以限制使用該身份進行攻擊的範圍。

Helm和Tiller在安裝，刪除和修改邏輯應用程序時，可以包含許多服務交互。因此，它的使用通常涉及整個集群的操作，在多租戶集群中意味著Tiller安裝必須非常小心才能訪問整個集群，以防止不正確的安全活動。

特定用戶和團隊 - 開發人員，運維人員，系統和網路管理員 - 需要他們自己的群集分區，以便他們可以使用Helm和Tiller，而不會冒著集群其他分區的風險。這需要啟用RBAC的Kubernetes集群，並配置Tiller的RBAC許可權。有關在Kubernetes中使用RBAC的更多信息，請參閱使用RBAC授權Using RBAC Authorization。

Tiller和用戶許可權

當前情況下的Tiller不提供將用戶憑據映射到Kubernetes內的特定許可權的方法。當Tiller在集群內部運行時，它將使用其服務帳戶的許可權運行。如果沒有服務帳戶名稱提供給Tiller，它將使用該名稱空間的默認服務帳戶運行。這意味著該伺服器上的所有Tiller操作均使用Tiller pod的憑據和許可權執行。

為了合適的限制Tiller本身的功能，標準Kubernetes RBAC機制必須配置到Tiller上，包括角色和角色綁定，這些角色明確的限制了Tiller實例可以安裝什麼以及在哪裡安裝。

這種情況在未來可能會改變。社區有幾種方法可以解決這個問題，採用客戶端許可權而不是Tiller許可權的情況下，活動的許可權取決於Pod身份工作組，已經解決了的安全的一般性問題。

Tiller gRPC端點和TLS

在默認安裝中，Tiller提供的gRPC端點在集群內部（不在集群外部）可用，不需要應用認證配置。如果不應用身份驗證，集群中的任何進程都可以使用gRPC端點在集群內執行操作。在本地或安全的專用群集中，這可以實現快速使用並且是合適的。（當在集群外部運行時，Helm通過Kubernetes API伺服器進行身份驗證，以達到Tiller，利用現有的Kubernetes身份驗證支持。）

共享和生產群集 - 大多數情況下 - 應至少使用Helm 2.7.2，並為每個Tiller gRPC端點配置TLS，以確保群集內gRPC端點的使用僅適用於該端點的正確身份驗證標識。這樣做可以在任意數量的namespace中部署任意數量的Tiller實例，任何gRPC端點未經授權不可使用。使用Helm init --tiller-tls-verify選擇安裝啟用TLS的Tiller,並驗證遠程證書，所有其他Helm命令都應該使用該--tls選項。

有關正確配置並使用TLS的Tiller和Helm的正確步驟的更多信息，請參閱Helm和Tiller使用SSLUsing SSL between Helm and Tiller。

當Helm客戶端從群集外部連接時，Helm客戶端和API伺服器之間的安全性由Kubernetes本身管理。你可能需要確保這個鏈接是安全的。請注意，如果使用上面建議的TLS配置，則Kubernetes API伺服器也無法訪問客戶端和Tiller之間的未加密消息。

Tiller Release信息

由於歷史原因，Tiller將其release信息存儲在ConfigMaps中。我們建議將默認設置更改為Secrets。

Secrets是Kubernetes用於保存被認為是敏感的配置數據的可接受的方法。儘管secrets本身並不提供很多保護，但Kubernetes集群管理軟體經常將它們與其他對象區別開來。因此，我們建議使用secrets來存儲release信息。

啟用此功能目前需要在Tiller部署時設置參數--storage=secret。這需要直接修改deployment或使用helm init --override=...，因為當前沒有helm init 參數可供執行此操作。有關更多信息，請參閱 Using --override。

關於chart

由於Helm的相對生命周期，Helm chart生態系統的發展並沒有考慮到整個集群的控制，這在開發人員來說，是完全合理的。但是，chart是一種不僅可以安裝可能已經驗證或可能未驗證的容器的包，它也可以安裝到多個namespace中。

與所有共享的軟體一樣，在受控或共享的環境中，必須在安裝之前驗證自己安裝的所有軟體。如果已經通過TLS配置安裝了Tiller，並且只有一個或部分namespace的許可權，某些chart可能無法安裝 - 在這些環境中，這正是你想要的。如果需要使用chart，可能必須與創建者一起工作或自行修改它，以便在應用了適當的RBAC規則的多租戶群集中安全地使用它。helm template命令在本地呈現chart並顯示輸出。

一旦通過檢查，可以使用Helm的工具來確保使用的圖表的出處和完整性ensure the provenance and integrity of charts。

gRPC工具和安全Tiller配置

許多非常有用的工具直接使用gRPC介面，並且已經針對默認安裝構建 - 它們提供了集群範圍的訪問 - 一旦應用了安全配置後就可能工作不正常。RBAC策略由你或集群運維人員控制，並且可以針對該工具進行調整，或者可以將該工具配置為，在應用於Tiller的特定RBAC策略的約束範圍內來正常工作。如果gRPC端點受到保護，則可能需要執行相同的操作：為了使用特定的Tiller實例，這些工具需要自己的安全TLS配置。RBAC策略和gRPC工具一起配置的安全gRPC端點的組合，使你能夠按照自己的需要控制群集環境。

Helm和Tiller安全最佳實踐

以下指導原則重申了Helm和Tiller安全並正確使用它們的最佳方法。

1. 創建一個啟用了RBAC的集群
2. 配置每個Tiller gRPC端點以使用單獨的TLS證書
3. Release信息應該使用Kubernetes Secret
4. 為每個用戶，團隊或其他具有--service-account參數，role和RoleBindings的組織安裝一個Tiller
5. helm init使用--tiller-tls-verify，其他Helm命令--tls來強制驗證

如果遵循這些步驟，則helm init命令可能如下所示：

$ helm init --tiller-tls --tiller-tls-verify --tiller-tls-cert=cert.pem --tiller-tls-key=key.pem --tls-ca-cert=ca.pem --service-account=accountname

此命令將通過gRPC進行強身份驗證，並應用RBAC策略的服務帳戶安裝啟動Tiller。