共用方式為

具有 Azure Kubernetes Service (AKS) 的機密容器 (預覽版)

  • 發行項

機密容器提供一組特性與功能，進一步保護您的標準容器工作負載，以達到更高的資料安全性、資料隱私權，以及執行階段程式碼完整性目標。 Azure Kubernetes Service (AKS) 包含 AKS 上的機密容器 (預覽版)。

機密容器建置於 Kata 機密容器和硬體型加密之上，可加密容器記憶體。 其會在計算期間防止記憶體中的資料成為純文字、可讀取格式，藉以建立新的資料機密層級。 在容器中透過硬體證明贏得信任，允許信任的實體存取加密資料。

與 Pod 沙箱功能一起使用，您可以在 Azure 中執行隔離的敏感性工作負載來保護資料和工作負載。 讓容器成為具有機密性的項目：

  • 透明度：敏感性應用程式共用所在的機密容器環境，您可以查看並確認其是否安全。 信任的運算基礎 (TCB) 的所有元件都會開放原始碼。
  • 稽核能力：您能夠確認並查看哪個 CoCo 環境套件版本 (包括 Linux 客體 OS 與所有元件) 是最新的。 Microsoft 透過證明來向客體 OS 和容器執行階段環境進行簽署，以進行驗證。 其也會發行客體 OS 組建的安全雜湊演算法 (SHA)，以建置字串清晰度和控制劇本。
  • 完整證明：所有隸屬於 TEE 的項目都應該由 CPU 進行完整測量，且能夠從遠端驗證。 AMD SEV-SNP 處理器的硬體報告應透過證明宣告，來反映容器層和容器執行階段設定雜湊。 應用程式可以在本機擷取硬體報告，包括反映客體 OS 映像和容器執行階段的報告。
  • 程式碼完整性：執行階段強制執行一律可透過客戶針對容器和容器設定定義的原則取得，例如，不可變的原則和容器簽署。
  • 與操作員隔離：採用最低權限和最高隔離度的安全性設計，可防護所有不受信任的合作對象，包括客戶/租用戶系統管理員。 其包含強化現有 Kubernetes 控制平面對機密 Pod 的存取 (kubelet)。

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

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

  • 使用 Azure CLI 部署或升級 AKS 叢集
  • 將註釋新增至您的 Pod YAML，將 Pod 標示為以機密容器的形式執行
  • 將安全性原則 (部分機器翻譯) 新增至您的 Pod YAML
  • 啟用安全性原則的強制執行
  • 在機密運算中部署您的應用程式

支援的案例

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

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

考量

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

  • 相較於 Runc Pod 和核心隔離的 Pod，Pod 啟動時間增加。
  • 不支援第 1 版容器映像。
  • 對祕密和 ConfigMaps 的更新不會反映在客體中。
  • 暫時性容器和其他疑難排解方法 (例如，exec 至容器、記錄容器的輸出，以及 stdio (ReadStreamRequest 與 WriteStreamRequest)) 都需要修改並重新部署原則。
  • 原則產生器工具不支援 cronjob 部署類型。
  • 由於容器映像層量值已編碼於安全性原則中，因此，不建議在指定容器時使用 latest 標籤。
  • 服務、Load Balancer 和 EndpointSlices 僅支援 TCP 通訊協定。
  • 叢集上所有 Pod 中的所有容器都必須設定為 imagePullPolicy: Always。
  • 原則產生器僅支援使用 IPv4 位址的 Pod。
  • 如果在部署 Pod 之後使用環境變數方法進行設定，則無法變更 ConfigMaps 和祕密值。 安全性原則會防止它。
  • 不支援 Pod 終止記錄。 雖然 Pod 會將終止記錄寫入 /dev/termination-log 或 Pod 資訊清單中指定的自訂位置，但主機/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 資訊清單中的資源要求，因此，容器不會將要求傳遞至填充碼。 使用資源 limit (而不是資源 requests)，針對工作負載或容器配置記憶體或 CPU 資源。

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

下一步