Share via

具有 Azure Kubernetes Service 的機密容器 （預覽版）

  • 發行項

機密容器提供一組特性和功能，進一步保護您的標準容器工作負載，以達到更高的數據安全性、數據隱私權和運行時間程式代碼完整性目標。 Azure Kubernetes Service （AKS） 包含 AKS 上的機密容器（預覽版）。

機密容器是以 Kata 機密容器和硬體型加密為基礎來加密容器記憶體。 它會在計算期間防止記憶體中的數據處於純文本、可讀取格式，以建立新的數據機密層級。 信任是透過硬體證明在容器中賺取，允許存取受信任實體的加密數據。

與 Pod 沙盒一起，您可以執行隔離在 Azure 中的敏感性工作負載，以保護您的數據和工作負載。 容器機密的內容：

  • 透明度：敏感性應用程式共用所在的機密容器環境，您可以查看並確認其是否安全。 信任運算基底 （TCB） 的所有元件都必須 開放原始碼。
  • 可稽核性：您可以確認並查看 CoCo 環境套件的版本，包括 Linux 客體 OS 和所有元件都是最新的。 Microsoft 會透過證明向客體 OS 和容器運行時間環境進行驗證。 它也會發行客體OS組建的安全哈希演算法 （SHA），以建置字串奧迪和控制故事。
  • 完整證明：屬於 TEE 一部分的任何專案都應該由 CPU 完整測量，且能夠從遠端驗證。 AMD SEV-SNP 處理器的硬體報告應透過證明宣告反映容器層和容器運行時間組態哈希。 應用程式可以在本機擷取硬體報告，包括反映客體OS映像和容器運行時間的報告。
  • 程序代碼完整性：運行時間強制執行一律可透過客戶定義的容器和容器設定原則來使用，例如不可變的原則和容器簽署。
  • 與操作員隔離：採用最低許可權和最高隔離度的安全性設計，可防護所有不受信任的合作物件，包括客戶/租用戶系統管理員。 它包含強化現有 Kubernetes 控制平面存取權 （kubelet） 至機密 Pod。

透過其他安全性措施或數據保護控件，作為整體架構的一部分，這些功能可協助您符合保護敏感性資訊的法規、產業或治理合規性需求。

本文可協助您了解機密容器功能，以及如何實作及設定下列專案：

  • 使用 Azure CLI 部署或升級 AKS 叢集
  • 將批註新增至 Pod YAML，以將 Pod 標示為以機密容器的形式執行
  • 將 安全策略 新增至您的 Pod YAML
  • 啟用安全策略的強制執行
  • 在機密運算中部署您的應用程式

支援的案例

機密容器 （預覽） 適用於涉及敏感數據的部署案例。 例如，個人標識資訊（PII）或任何具有法規合規性所需強大安全性的數據。 容器的一些常見案例包括：

  • 使用 Apache Spark 在金融領域執行巨量數據分析，以進行詐騙模式辨識。
  • 執行自我裝載的 GitHub 執行器，以安全地簽署程式代碼，作為持續整合和持續部署 （CI/CD） DevOps 實務的一部分。
  • 機器學習 使用受信任來源的加密數據集推斷和定型 ML 模型。 它只會解密機密容器環境內的隱私權。
  • 在零售與數位廣告等產業中，建置用於標識符比對的巨量數據清理室，作為多方計算的一部分。
  • 建置機密運算 零信任 登陸區域，以符合應用程式移轉至雲端的隱私權法規。

考量

以下是此機密容器預覽版的考慮：

  • 相較於 Runc Pod 和核心隔離的 Pod，Pod 啟動時間增加。
  • 不支援第1版容器映像。
  • 更新 秘密和設定 地圖 不會反映在來賓中。
  • 暫時容器和其他疑難解答方法，例如 exec 進入容器、記錄容器的輸出，以及 stdio （ReadStreamRequest 和 WriteStreamRequest） 都需要修改和重新部署原則。
  • 原則產生器工具不支援cronjob部署類型。
  • 由於容器映射層度量在安全策略中編碼，我們不建議在指定容器時使用 latest 標記。
  • 服務、Load Balancer 和 EndpointSlices 僅支援 TCP 通訊協定。
  • 叢集上所有 Pod 中的所有容器都必須設定為 imagePullPolicy: Always。
  • 原則產生器僅支援使用 IPv4 位址的 Pod。
  • 如果部署Pod之後使用環境變數方法進行設定，則無法變更設定 地圖和秘密值。 安全策略會防止它。
  • 不支援 Pod 終止記錄。 當 Pod 在 Pod 指令清單中指定時，將終止記錄 /dev/termination-log 寫入或寫入自定義位置時，主機/kubelet 無法讀取這些記錄。 從客體變更為該檔案不會反映在主機上。

資源配置概觀

請務必瞭解此版本中的記憶體和處理器資源配置行為。

  • CPU：填充碼會將一個 vCPU 指派給 Pod 內的基底 OS。 如果未指定任何資源 limits ，則工作負載沒有指派個別的CPU共用，則 vCPU 會與該工作負載共用。 如果指定 CPU 限制，則會針對工作負載明確配置 CPU 共用。
  • 記憶體：Kata-CC 處理程式會針對 UVM OS 和 X MB 額外記憶體使用 2 GB 記憶體，其中 X 是 YAML 指令清單中指定的資源 limits （若未指定任何限制，則會產生 2 GB 的 VM，而沒有容器的隱含記憶體）。 當 YAML 指令清單中指定資源limits時，Kata 處理程式會針對 UVM OS 和 X MB 額外記憶體使用 256 MB 基底記憶體。 如果未指定限制，則會新增 1,792 MB 的隱含限制，導致容器的 2 GB VM 和 1,792 MB 的隱含記憶體。

在此版本中，不支援在Pod指令清單中指定資源要求。 Kata 容器會忽略 Pod YAML 指令清單中的資源要求，因此，容器不會將要求傳遞至填充碼。 使用資源而非資源limitrequests來配置工作負載或容器的記憶體或 CPU 資源。

使用 VM 記憶體所支援的本機容器檔案系統，寫入容器檔案系統（包括記錄）可以填滿提供給 Pod 的可用記憶體。 此條件可能會導致潛在的Pod當機。

下一步

  • 請參閱機密容器安全策略的概觀，以瞭解工作負載及其 Pod 中的數據如何受到保護。
  • 使用預設安全策略在 AKS 上部署機密容器。
  • 深入了解具有 AKS 叢集之節點的 Azure 專用主機，以使用硬體隔離和控制 Azure 平台維護事件。