資料加密和密鑰管理可以確保敏感性資料在儲存、傳輸和處理過程中得到有效保護。同時，持續監測和更新密碼編譯演算法和密鑰管理原則，以適應不斷演變的安全威脅和技術挑戰。
資料加密
雲端硬碟加密建議
開啟雲端硬碟加密特性
對業務資料靜態加密是安全的最佳實務，具體操作，請參見加密雲端硬碟儲存卷。
定期輪換CMK
您可以通過密鑰版本化和定期輪轉來加強密鑰使用的安全性，實現資料保護的安全性原則和最佳實務。具體操作，請參見自動輪轉密鑰。
使用KMS中的指定金鑰組指定雲端硬碟儲存卷進行加密
阿里雲ACK叢集適用於有高安全性或合規性要求的應用情境，您無需自建和維護密鑰管理基礎設施，通過加密保護儲存在阿里雲ECS上的資料就能保護資料的隱私性和自主性。更多資訊，請參見加密雲端硬碟儲存卷。
本文以配置加密雲端硬碟資料卷為例，在建立儲存資源執行個體時，您可以使用KMS中的指定金鑰組指定雲端硬碟儲存卷進行加密。
配置StorageClass參數。
將以下內容複寫到sc-kms.yaml檔案中。
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: csi-disk provisioner: diskplugin.csi.alibabacloud.com parameters: fsType: ext4 type: cloud_ssd encrypted: "true" kmsKeyId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx reclaimPolicy: Delete執行以下命令建立StorageClass。
kubectl create -f sc-kms.yaml
建立PVC。
將以下內容複寫到sc-pvc.yaml檔案中。
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: disk-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: csi-disk執行以下命令建立PVC。
kubectl create -f sc-pvc.yaml
密鑰管理
Kubernetes作為編排引擎為應用開發人員提供了Secrets模型，用於在應用Pod中載入和使用敏感資訊，例如資料庫密碼、應用認證、認證Token等。Secrets相關概念如下。
Secrets是一個Namespace維度模型，結合K8s RBAC存取控制可以實現叢集內Namespace維度讀寫隔離。
Secrets可以通過檔案或環境變數的形式掛載到Pod容器中使用。
Secrets中的敏感性資料以Tmpfs格式儲存在節點檔案系統中。
叢集APIServer以Base64明文編碼的形式將Secrets儲存在叢集etcd中。
Secrets單個執行個體的大小限制在1 MB內。
K8s Secrets作為K8s應用處理敏感資訊的載體和橋樑，但並不能保證敏感資訊的安全性，在使用過程中可能會遇到以下問題。
一些關鍵的密鑰資訊，需要開發人員和安全管理員在應用系統實施前確定密鑰管理的安全方案，明確如何儲存應用密鑰。
如何在不破壞密鑰可載入和使用的前提下，保護其讀寫和傳輸階段的安全性？
雲端服務商有哪些安全方案可以協助保護應用密鑰？
在K8s環境中，您可以採取哪些安全措施協助管理和使用密鑰？
下文從雲端服務商提供的密鑰管理安全方案和面嚮應用開發人員的密鑰管理最佳安全實踐兩個維度幫您解決以上問題。
安全方案
雲端式上安全責任共擔模型，雲端服務商有責任保護管控側配置和敏感資訊的安全性，同時提供密鑰管理的安全方案，可以協助您提升應用密鑰的安全水位，推薦的安全方案如下。
使用雲上Key Management Service
雲端服務商都會提供Key Management Service。例如，阿里雲Key Management Service提供專業的密鑰生命週期管理和資料加解密，可以協助您簡化應用系統接入流程。關於阿里雲Key Management Service的更多資訊，請參見什麼是Key Management Service。
在應用系統開發部署的供應鏈流程中，任何一個環節對敏感密鑰的寫入程式碼都有可能導致泄露風險。通過使用雲上Key Management Service，您可以在應用開發、測試、構建等生命週期流程中使用統一方式進行密鑰的讀寫，避免寫入程式碼出現。同時，雲上的Key Management Service支援自動化的密鑰輪轉能力，進一步降低了敏感資訊泄露傳播的安全風險，同時也可協助公司專屬應用程式滿足合規需求。
使用Secret Store CSI driver
應用消費密鑰的方式通常是從指定檔案系統路徑或是從環境變數讀取，使用Secret Store CSI driver可以幫您解決如何將雲上KMS服務中的密鑰資訊匯入到應用Pod容器內的指定路徑的問題。
K8s社區基於CSI儲存標準擴充實現了secrets-store-csi-driver，用於將儲存在外部金鑰管理服務中的密鑰以Volume儲存卷的形式掛載到應用Pods中。當Volume完成attach掛載後，密鑰資訊將以檔案系統的形式在容器中使用，無需建立K8s Secret執行個體。從而避免了etcd中出現明文Secret資訊，避免大規模情境下的Secret堆積，同時應用可以保持原先的檔案路徑方式讀取密鑰，避免通過KMS服務介面形式擷取密鑰帶來的額外改造代價。
基於該外掛程式機制，各雲端服務商可以實現自己的Provider對接不同的後端Key Management Service，例如，阿里雲的secrets-store-csi-driver-provider-alibabacloud，在叢集中部署該外掛程式，可以方便地將阿里雲KMS憑據管家中儲存的金鑰認證以檔案或K8s Secrets執行個體兩種方式同步到應用程式容器中，同時支援後端憑據修改後的同步更新能力，保證業務容器中密鑰資訊的即時性。為解決最後一把密鑰的問題，由於外掛程式需要調用KMS憑據管家服務的許可權，您可以通過使用RRSA方案，保護外掛程式對KMS服務要求的憑據，RRSA方案將KMS憑據的請求許可權綁定在外掛程式使用的獨立ServiceAccount上，避免將許可權泄露給應用Pod。
開啟etcd落盤加密
etcd是K8s叢集預設的後端儲存系統，Secrets在etcd中以Base64明文編碼的形式儲存，存在一定的安全風險。尤其在雲端服務商提供的託管叢集形態下，etcd維護在雲端服務商側，雲端式上安全零信任原則和很多應用情境下的合規要求，推薦您使用K8s提供的etcd落盤加密，選擇使用阿里雲KMS服務中管理的密鑰在Secret資料落盤流程中以信封加密的形式加密資料，同時在讀取Secret資訊時自動解密。配合使用自動輪轉密鑰可進一步提升資料安全性。
使用機密計算容器
對於對資料安全性有嚴格要求的情境，例如金融支付、隱私認證或涉及智慧財產權的核心資料計算，除了保證這些核心敏感資訊在讀寫和傳輸過程中的安全性，還需要保證機密資訊在雲上節點記憶體運算和預存程序中的安全可信。在此情境下推薦使用阿里雲ACK-TEE機密計算叢集，ACK-TEE可以基於底層硬體加密技術在容器應用實現一個可信執行加密環境，保證機密資訊在雲端代碼使用過程中的完整性，實現資料全生命週期的安全可信。同時，應用系統核心密鑰也可以儲存在可信的隔離環境Enclave中，實作類別似KMS HSM的能力，減少密鑰傳輸鏈路。
最佳安全實踐
雲端式服務商提供的密鑰管理安全方案，應用開發營運人員需要負責自身業務密鑰的安全性。以下為業務側推薦實施的密鑰管理最佳安全實踐。
RBAC存取控制
Secrets作為K8s系統中的基本模型，通過RBAC實現對Secrets執行個體的存取權限控制是基本且必要的安全要求，在叢集的日常營運開發中應該遵循許可權最小化原則進行授權，避免在下發憑證中綁定全域Secret讀寫權限，並及時吊銷可能泄露的叢集訪問憑證。
Pod安全強化
容器逃逸是針對K8s叢集常見的攻擊方式，對於一個已經逃逸到容器主機的攻擊，可以輕鬆擷取節點上相關Secrets的明文資訊，同時也可以發起進一步的攻擊，擷取整個叢集的存取權限，從而造成叢集內敏感資訊的泄露。
K8s提供了多種安全配置，協助應用開發人員加固容器安全，應用開發人員應當根據實際業務需要最小化Pod的Capabilities，避免使用Privileged或其他共用主機網路、檔案系統等特權配置。通過使用安全性原則，可以在應用部署過程中時刻有效攔截不符合安全性原則約束的違規特權部署。另外，部署和使用Network Policy，可以限制應用Pod內的東西向網路訪問，進一步收斂攻擊者入侵後實施下一步橫向攻擊的安全風險。
節點安全強化
叢集基礎設施安全是保證上層應用安全的基礎。首先應盡量選擇私人網路，同時使用安全性群組ACL規則控制出入網流量。對於叢集節點自身，推薦使用經過基於等保或阿里雲OS加固等安全合規規範，加固後的基礎鏡像作為叢集節點OS，可以協助在基礎設施層身份鑒別、存取控制、安全審計、入侵防範等多個維度提升基礎安全性，降低攻擊者從主機側攻擊竊取敏感資訊的風險。關於等保加固的更多資訊，請參見ACK等保加固使用說明。
K8s叢集自身組件的配置對上層應用系統的安全性起到至關重要的作用，可通過基準巡檢功能及時發現叢集中的不當安全配置，封堵漏洞。
供應鏈安全強化
關於密鑰的讀取使用會貫穿應用製品生命週期的各階段，需要在組織流程上加強對密鑰安全的風險意識，規範密鑰使用，嚴禁在應用模板、代碼倉庫、設定檔中寫入程式碼敏感資訊。在製品供應鏈生命週期中統一使用Key Management Service進行管理，同時，企業內部安全管理營運團隊可針對供應鏈各環節增加自動化安全掃描卡點，從源頭上防止敏感資訊的傳播和泄露。
審計和監控
在公司專屬應用程式系統中，涉及密鑰生命週期管理和讀寫使用的所有操作均應接入審計日誌，保證針對敏感資訊的操作可溯源，同時接入運行時刻監控機制，例如，針對應用中儲存敏感資訊的路徑設定可疑讀寫監控警示，對雲帳號AK設定泄露警示等安全設定。當發生密鑰泄露時，日誌和警示可以協助企業營運快速定位問題，判斷影響面，同時及時進行相關止血措施。
使用臨時憑證，定期或自動輪轉密鑰
請勿在應用系統中使用例如帳號AK的固定密鑰，推薦使用臨時憑據。當密鑰發生泄露時，獲得臨時憑據的攻擊者只有一個短暫的視窗期進行下一步的探查和攻擊，這無疑增加了攻擊難度，也給系統營運人員提供了封堵和修複系統漏洞的機會，試想如果憑據是永久的，可能應用系統的徹底修複需要成倍的難度。同樣的道理，當您使用雲上Key Management Service中的密鑰時，推薦定期輪轉或開啟密鑰自動輪轉特性，提升應用安全防禦能力。
使用信封加密並保護好最後一把密鑰
信封加密和直接使用雲上管理服務提供的密鑰進行直接加解密明文資料的方式不同，信封加密使用一個獨立的資料加密金鑰，並將其加密後封入信封中傳遞使用，業務側的敏感資訊可以在本地實現離線的加解密，避免上傳雲端傳輸過程中的泄露，同時解決了雲端服務商不信任問題。同時，對於資料量較大的加解密情境，離線的計算過程也避免了雲上傳輸和計算的開銷，有效提升計算效能並降低成本。關於信封機密的更多資訊，請參見使用KMS信封加密在本地加密和解密資料。
最後一把密鑰的安全問題是KMS加解密情境中的普遍問題，在信封加密過程中，同樣需要在雲上放置一把KEK密鑰用於加解密資料密鑰，此時通用的方案是使用類似RAM的存取控制服務，在最小化授權的前提下保證密鑰安全性。在應用側，需要限制讀取雲上密鑰的RAM憑證的可見範圍，同時使用可自動輪轉的臨時憑證，推薦在容器應用中使用類似RRSA應用維度隔離機制保護RAM憑證的安全性。關於RRSA的更多資訊，請參見RRSA。