Google推出GKE應用程式存取其他雲端服務的驗證新方法

為了解決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年效期的服務帳戶金鑰，當惡意入侵發生時，將能縮短影響的時間。