本頁面說明 GKE on AWS 的安全架構，包括加密和節點設定。
GKE 叢集提供多項功能，可協助保護工作負載，包括容器映像檔的內容、容器執行階段、叢集網路，以及叢集 API 伺服器的存取權。
使用 GKE 叢集時，您同意承擔叢集的特定責任。詳情請參閱「GKE 叢集共同責任」。
AWS KMS 加密
GKE on AWS 使用客戶管理的 AWS Key Management Service (KMS) 對稱金鑰加密下列項目：
在正式環境中，建議使用不同的金鑰進行設定和磁碟區加密。如要進一步降低金鑰遭盜用的風險，您也可以為下列項目分別建立金鑰：
為進一步提升安全性，您可以建立 AWS KMS 金鑰政策，只指派最低必要權限。詳情請參閱建立具有特定權限的 KMS 金鑰。
靜態資料加密
靜態資料加密是指加密儲存的資料，與傳輸中的資料不同。根據預設，GKE on AWS 會使用 AWS 平台代管的金鑰，加密 etcd 和儲存空間磁碟區中的靜態資料。
GKE on AWS 叢集會將資料儲存在 AWS Elastic Block Storage (EBS) 磁碟區。這些 EBS 磁碟區一律會使用 AWS Key Management System (AWS KMS) 金鑰加密靜態資料。建立叢集和節點集區時，您可以提供客戶管理的 KMS 金鑰 (CMK)，加密基礎 EBS 磁碟區。如未指定金鑰，AWS 會在叢集執行的 AWS 區域內，使用預設的 AWS 管理金鑰。
此外，所有 GKE 叢集都會啟用「應用程式層 Secret 加密」，保護機密資料 (例如 Kubernetes Secret 物件，這類物件儲存在 etcd 中)。即使攻擊者取得 etcd 資料儲存所在的基礎磁碟區存取權，這些資料也會經過加密。
建立叢集時，您必須將 AWS KMS 金鑰傳遞至 --database-encryption-kms-key-arn 欄位。這個金鑰用於應用程式資料的封包加密。由於這個資源欄位不可變動，且叢集建立後就無法修改，建議您使用 KMS 金鑰別名。您可以使用金鑰別名，在叢集的整個生命週期內輪替用於靜態加密的金鑰。
應用程式層級加密的運作方式
Kubernetes 提供應用程式層級的加密機制，也就是所謂的「信封加密」。系統會使用通常稱為「資料加密金鑰 (DEK)」的本機金鑰，加密 Secret。然後，DEK 本身會使用第二個金鑰 (稱為「金鑰加密金鑰 (KEK)」) 進行加密。Kubernetes 不會儲存 KEK。建立新的 Kubernetes Secret 時，叢集會執行下列操作：
Kubernetes API 伺服器會使用隨機號碼產生器，為密鑰產生一個不重複的 DEK。
Kubernetes API 伺服器會在本機使用 DEK 加密 Secret。
Kubernetes API 伺服器會將 DEK 傳送至 AWS KMS 進行加密。
AWS KMS 會使用預先產生的 KEK 加密 DEK，並將加密的 DEK 傳回 Kubernetes API 伺服器的 AWS KMS 外掛程式。
Kubernetes API 伺服器會將加密過的 Secret 和加密過的 DEK 儲存至 etcd。但不會將純文字 DEK 儲存在磁碟中。
Kubernetes API 伺服器會建立記憶體內快取項目，將加密的 DEK 對應至純文字 DEK。這樣一來，API 伺服器就能解密最近存取的密鑰，而不必查詢 AWS KMS。
用戶端向 Kubernetes API 伺服器要求 Secret 時，會發生以下情況：
Kubernetes API 伺服器會從 etcd 擷取加密過的 Secret 和加密過的 DEK。
Kubernetes API 伺服器會檢查快取中是否有現有對應項目，如果有的話，就會使用該項目解密 Secret。
如果沒有相符的快取項目，API 伺服器會將 DEK 傳送至 AWS KMS，以 KEK 進行解密。然後使用解密的 DEK 解密密鑰。
最後，Kubernetes API 伺服器會將解密後的 Secret 傳回給用戶端。
金鑰輪替
與憑證輪替不同，金鑰輪替是指變更金鑰加密金鑰 (KEK) 中包含的基礎加密編譯內容。這項作業可自動觸發 (排定輪替作業時)，或手動觸發 (通常是在發生安全事件後，因為金鑰可能已遭盜用)。金鑰輪替只會替換金鑰中包含原始加密/解密金鑰資料的單一欄位。
KMS 金鑰輪替
AWS KMS 支援「自動輪替 KMS 金鑰」。啟用後，AWS 每年會自動為您的金鑰產生新的加密金鑰內容。您不需要手動採取任何行動。
詳情請參閱「金鑰輪替」。
叢集信任
所有叢集通訊都會使用傳輸層安全標準 (TLS)。每個叢集都會佈建下列主要自簽根憑證授權單位 (CA)：
- 叢集根 CA 用於驗證傳送至 API 伺服器的要求。
- etcd 根 CA 用於驗證傳送至 etcd 副本的要求。
每個叢集都有專屬的根 CA。如果某個叢集的 CA 遭駭，其他叢集的 CA 不會受到影響。所有根 CA 的效期都是 30 年。
節點安全性
GKE on AWS 會將工作負載部署到 AWS EC2 執行個體的節點集區。以下章節說明節點的安全功能。
Ubuntu
節點會執行最佳化版本的 Ubuntu OS，以執行 Kubernetes 控制層和節點。詳情請參閱 Ubuntu 說明文件中的「安全防護功能」。
GKE 叢集會實作多項安全防護功能，包括：
最佳化套裝組合
Google Cloud-tailored Linux kernel
有限的使用者帳戶及停用 root 使用者登入
Ubuntu 還有其他安全指南，例如：
保護工作負載
Kubernetes 可讓使用者快速佈建、調度資源及更新以容器為基礎的工作負載。本節說明可用的策略，以避免執行中的容器對叢集和 Google Cloud 服務造成副作用。
限制 Pod 容器程序權限
限制容器化程序權限對叢集安全至關重要。您可以透過安全環境設定安全性相關選項。這些設定可讓您變更程序的安全設定，例如：
- 執行程序的使用者和群組
- 可用的 Linux 功能
- 權限提升
預設的 GKE on AWS 節點作業系統 Ubuntu 會對所有容器使用預設的 Docker AppArmor 安全政策。您可在 GitHub 上檢視設定檔範本。此外，這個設定檔會拒絕在容器執行下列功能：
- 直接在程序 ID 目錄 (
/proc/) 中寫入檔案 - 寫入不在
/proc/中的檔案 - 將檔案寫入
/proc/sys(而非/proc/sys/kernel/shm*) - 掛接檔案系統
限制工作負載自行修改的能力
特定 Kubernetes 工作負載 (尤其是系統工作負載) 有權自行修改。舉例來說，部分工作負載會自動垂直擴充。雖然方便，但如果攻擊者已入侵節點，就能在叢集中進一步擴大影響範圍。舉例來說，攻擊者可能會讓節點上的工作負載變更，以同一個命名空間中權限較高的服務帳戶身分執行。
理想情況下，工作負載不應獲得修改自身的權限。如果必須自行修改，您可以安裝 Policy Controller 或 Gatekeeper，並套用限制 (例如開放原始碼 Gatekeeper 程式庫中的 NoUpdateServiceAccount)，藉此限制權限。這個程式庫提供多項實用的安全性政策。
部署政策時，通常需要允許管理叢集生命週期的控制器略過政策。這是必要步驟，因為控制器需要變更叢集，例如套用叢集升級。舉例來說，如果您在 AWS 上的 GKE 部署 NoUpdateServiceAccount 政策，就必須在 Constraint 中設定下列參數：
parameters:
allowedGroups: []
allowedUsers:
- service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com
將 PROJECT_NUMBER 替換為叢集所在專案的編號 (而非 ID)。
使用二進位授權
啟用二進位授權是保護工作負載的另一種方式。 二進位授權是一項安全功能，可確保只有受信任的容器映像檔會部署至 GKE 叢集。
整個程序的運作流程如下：
管理員會建立政策，定義部署映像檔的規定。包括指定可簽署映像檔的授權實體 (驗證者)，以及映像檔必須符合的其他條件，才能視為可安全部署。
認證者 (例如開發人員或自動化系統) 會使用加密演算法產生金鑰組 (私密和公開金鑰)。
私密金鑰會妥善保存，並用於產生圖片的數位簽章 (即一組不重複的字元)。這個簽章就像是核准印章，表示圖片已通過所有必要檢查和驗證。
數位簽章隨即「附加」至圖片。換句話說，簽章會儲存在圖片的中繼資料中，通常位於圖片登錄檔中。
接著向 Binary Authorization 系統註冊公開金鑰，系統就能使用公開金鑰驗證簽名。
當系統收到部署容器的要求時，二進位授權系統會擷取登錄檔中附加至映像檔的數位簽章。
二進位授權系統會使用已註冊的公開金鑰，驗證映像檔附加的數位簽名。此外，系統也會檢查圖片是否符合政策中定義的所有其他條件。如果使用公開金鑰和映像檔資料成功驗證數位簽章，且映像檔符合政策中定義的所有其他條件，二進位授權系統就會允許部署容器。如果無法使用公開金鑰和映像檔資料成功驗證數位簽章，或映像檔不符合政策中定義的其他條件，二進位檔授權系統就會拒絕部署容器。
如要進一步瞭解二進位授權的運作方式，請參閱「二進位授權總覽」。
如要在現有叢集或建立叢集時啟用二進位授權，請參閱如何啟用二進位授權。
在專屬節點集區中隔離工作負載
您可以使用 Kubernetes taint 和容許條件，指定特定節點集區執行特定類型的工作負載。舉例來說，您可以指示 GKE on AWS 避開大多數系統管理的工作負載來排定使用者工作負載，或將不同信任層級的工作負載放在不同的節點集區。
使用 taint 和容許條件隔離工作負載並非有保障的安全措施。請務必搭配 GKE on AWS 提供的其他強化措施使用。
詳情請參閱「在專屬節點集區中隔離工作負載」。
後續步驟
- 瞭解金鑰輪替。