Azure Kubernetes 應用程式網路安全概覽（預覽）

這很重要

AKS 預覽功能可透過自助服務，以加入方式使用。預覽是「依現況」及「可用時」提供的，並不包括在服務等級協定和有限保固之內。客戶支援部門會盡最大努力，部分支援 AKS 預覽。因此，這些功能不適合實際執行用途。如需詳細資訊，請參閱下列支援文章：

Azure Kubernetes 應用網路透過自動互助 TLS（mTLS）及基於身份的授權，保護連接的 Azure Kubernetes Service（AKS）叢集中服務之間的通訊。它會發出工作負載身份，並管理憑證的發行、輪換與驗證，以實現加密、認證且明確授權的服務對服務通訊，無需手動設定，且傳輸中同時具備符合 FIPS 標準的加密。

本文概述了 Azure Kubernetes 應用網路的安全特性，包括 mTLS、工作負載識別碼、憑證管理及授權政策。同時也說明了在 Azure Kubernetes 應用網路環境中實施安全通訊的限制與下一步步驟。

局限性

憑證目前由 Azure Kubernetes 應用網路管理的憑證授權機構（CA）頒發，且不綁定於公共憑證授權中心。

mTLS

應用程序網路使用 mTLS 提供基於身份的加密通訊，以實現工作負載之間的通信。應用網路連接叢集中的每個服務會自動獲得憑證，以證明其身份並建立同一應用網路內其他服務的信任加密連線。傳輸加密使用符合FIPS標準的密碼學。

mTLS 遷移策略

應用網路目前允許加密與未加密的流量。此方法確保現有工作負載持續正常運作，而新工作負載或更新工作負載則自動使用 mTLS 進行安全通訊。這表示你可以採用 mTLS，在無停機的情況下，實現跨工作負載的安全通訊。遷移完成後，你可以切換到嚴格模式，以確保認證被強制執行。

Azure Kubernetes 應用網路中 mTLS 的優點

Azure Kubernetes 應用網路中的 mTLS 能幫助你：

保護傳輸中的資料：所有服務間流量皆可自動加密（符合 FIPS 標準）。
驗證服務身份：每個工作負載都有獨特的 Application Network 管理的根與中介憑證。
簡化操作：應用網路負責使用者的憑證發放、輪替及撤銷。

憑證管理

Azure Kubernetes Application Network 提供憑證管理，由 Azure Key Vault 支援，該 Vault 負責發行與維護用於 mTLS 的憑證。此服務會在所有連接到同一應用網路資源的 AKS 叢集間建立共享的信任邊界。

Application Network 自動管理根憑證與中間憑證的整個生命週期，包括配置、續期與輪替。這確保工作負載身份保持有效，通訊隨時間保持安全。你不需要手動建立、儲存或輪換憑證。

下圖展示了應用網路中的憑證階層，說明根憑證、中間憑證及工作負載憑證如何結構以建立跨連接叢集的信任：

憑證階層與生命週期

當建立應用網路資源時，會配置根 憑證卡 作為應用網路的信任錨點。當 AKS 叢集加入應用程式網路成為成員時，應用程式網路會為該成員發出由應用程式網路根憑證機構簽署的 中間憑證 。每個連接的 AKS 叢集會使用其由應用網路管理的中介憑證，為該叢集中的工作負載簽發短壽命的 工作負載憑證。

所有工作負載憑證都繼承自應用網路根CA的信任，維持資源間統一的信任邊界。根憑證與中間憑證的輪替對使用者透明處理，不會造成任何停機或流量中斷。此管理階層確保應用網路中所有叢集間的一致且可驗證的信任，同時自動維持每張憑證的有效性。

從任何成員叢集，您可以從命名空間applink-system底下的 ConfigMap istio-root-cert取得根 CA 憑證。

證書類型與輪調期間

憑證類型	範圍	有效期	旋轉週期	Purpose
根 CA	Azure Kubernetes Application Network	12個月	6 個月	建立所有連接至 Azure Kubernetes 應用網路叢集的信任邊界
中級CA	Cluster	90 天	45天	為該叢集內的工作負載發出憑證
工作負載證書	[工作負載]	24 小時	12 小時	驗證工作負載並保護服務間通訊

工作負載識別與授權

隨著應用程式成長，服務通常需要在同一部署中跨不同命名空間與環境安全通訊。管理憑證並確保每個服務都能驗證其通訊對象，這很快就會變得複雜且容易出錯。 Azure Kubernetes Application Network 透過自動指派和管理工作負載身份，消除這些開銷。

在應用程式網路連接環境中，工作負載在命名空間內外安全通訊。為了確保每個服務都能被信任並驗證，應用網路會為每個工作負載分配一個 可驗證的身份 ，代表其命名空間與服務帳號。

每個應用網路工作負載會自動獲得一個 SPIFFE 格式的唯一身份，包含其命名空間與服務帳號。身分識別將使用以下格式：

spiffe://cluster.local/ns/<namespace>/sa/<service-account>

此身份嵌入於工作負載憑證中，用於與其他工作負載通訊時證明服務身份。 Azure Kubernetes Application Network 採用這種基於 SPIFFE 的身份模型，搭配 Istio 授權政策，因此你可以定義明確且一致的規則，決定哪些服務可以通訊。

定義存取政策

你可以用 Istio AuthorizationPolicies 控制哪些工作負載可以在你的環境中通訊。這些政策允許你根據已驗證的工作負載身份來定義存取權限，而非網路位置或 IP 位址。這種方法能幫助你在服務擴展並跨節點移動時，仍能強制一致的存取控制。例如，你可以透過在政策的主體清單中引用其 SPIFFE 身份，允許僅允許來自受信任命名空間的特定閘道或工作負載呼叫服務，如下範例所示：

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-gateway-to-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: myApp
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/myApp-gateway // see SPIFFE format above

政策設計指導

在設計授權政策時，請牢記以下最佳實務：

務必同時指定命名空間與服務帳號，以防止非預期的跨命名空間存取。
使用主體定義明確的工作負載身份，以實現細粒度存取。
適當時，使用 命名空間 來定義更廣泛的信任邊界。
避免規則只匹配服務帳號名稱而未指定命名空間，因為這可能會授予跨叢集或環境的存取權。
結合 AuthorizationPolicies 與 Kubernetes NetworkPolicies 來強制執行基於身份與網路的隔離。

備註

Azure Kubernetes 應用網路授權是基於已驗證的工作負載身份，而非 IP 位址。這確保即使工作負載在擴展或跨節點移動時，執行仍能保持一致。

透過結合 Azure Kubernetes 應用網路管理的身份、憑證與政策控制，您可以實作基於身份的最低權限服務通訊，確保跨叢集工作負載的流量經過認證、加密且明確授權。

欲了解更多關於 Azure Kubernetes 應用網路的資訊，請參閱以下文章：

意見反應

此頁面對您有幫助嗎？

Last updated on 2026-03-23