為了解決GKE應用程式連接到其他GCP服務,現行授權驗證方法存在的安全問題,Google為GKE用戶推出Workload Identity功能,透過建立Kubernetes服務帳戶和Cloud IAM服務帳戶之間的關聯,用戶能夠定義工作負載的身份,不需要管理Kubernetes機密資訊或是IAM帳戶金鑰,GKE應用程式就能自動地存取其他雲端服務。

過去GKE工作負載存取Google雲端API,主要使用兩種授權驗證方法,一種是儲存服務帳號金鑰作為Kubernetes機密資訊,另一種則是使用節點的IAM服務帳號,但這兩種方法都存在管理和安全性的問題。

第一種方法是把Cloud IAM服務帳戶當作是應用程式請求Google API的身份標示,開發人員可以為每個應用程式創建獨立的IAM服務帳戶,並將金鑰下載下來作為Kubernetes的機密資訊,但Google提到,這個方法的應用過程不只麻煩,而且由於服務帳戶金鑰10年才會過期,因此在開發者沒發現被入侵的情況下,駭客有機會可以長期存取使用。

第二種方法則是使用節點的IAM服務帳號,因為每個GKE節點都是Compute Engine實例,所以GKE上執行的應用程式都會繼承Compute Engine實例的屬性,而這也包括了IAM服務帳號,不過在容器化應用程式的架構中,用戶通常會希望特定的Pod擁有存取權限就好,避免授予其他Pod不需要的權限,但是這種方法無可避免地,會讓節點上的所有Pod都同時具有權限,這違反只給應用程式所需資源的最小權限原則。

由於現存兩種授權方式各有缺點,因此Google推出了Workload Identity功能,提供GKE應用程式更安全也更快速的GCP服務存取驗證方法。Kubernetes服務帳戶與Cloud IAM服務帳戶之間的關聯是由Identity命名空間定義,當用戶在叢集啟用Workload Identity之後,專案會便會收到Identity命名空間,共用Kubernetes服務帳戶名稱、Kubernetes命名空間以及Identity命名空間的應用程式,將獲得存取Cloud IAM服務帳戶的權限。

用戶授權Kubernetes服務帳戶使用目標IAM服務帳戶,並以Kubernetes命名空間更新IAM服務帳戶,而這就能讓Kubernetes工作負載知道,要使用哪個服務帳戶來存取Google雲端服務,只要工作負載使用的是標準Google客戶端函式庫存取雲端服務,就能利用設定的IAM服務帳戶進行存取。Workload Identity的有效範圍是以專案為單位,因此用戶可以為專案中的新叢集或是現有叢集授予權限。

Workload Identity帶來的好處除了可以實施最小權限原則,讓所有工作負載僅具有需要的對低權限,當發生安全問題時,也能限制受到影響的範圍,而且因為命名空間服務帳號的憑證是由Google管理,因此也減少人為發生錯誤的可能性,而且實際發出的工作負載憑證也僅在短時間有效,比起10年效期的服務帳戶金鑰,當惡意入侵發生時,將能縮短影響的時間。


Advertisement

更多 iThome相關內容