你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Kubernetes 应用程序网络安全概述（预览版）

重要

AKS 预览功能可在自助服务和自愿选择的基础上启用。预览版按“现状”和“视供应情况”提供，它们不包括在服务级别协议和有限保证范围内。 AKS 预览功能是由客户支持尽最大努力部分覆盖。因此，这些功能并不适合用于生产。有关详细信息，请参阅以下支持文章：

Azure Kubernetes 应用程序网络通过自动相互 TLS (mTLS) 和基于标识的授权来保护连接的 Azure Kubernetes服务 (AKS) 群集中服务之间的通信。它颁发工作负载标识并管理证书颁发、轮换和验证，以启用加密、经过身份验证和显式授权的服务到服务通信，而无需手动配置，且传输中符合 FIPS 标准的加密。

本文概述了 Azure Kubernetes 应用程序网络中的安全性功能，包括 mTLS、工作负荷标识、证书管理和授权策略。它还概述了在 Azure Kubernetes 应用程序网络环境中实现安全通信的限制和后续步骤。

局限性

证书当前由 Azure Kubernetes 应用程序网络管理的证书颁发机构（CA）颁发，不会链接到公共 CA。

mTLS

应用程序网络使用 mTLS 在工作负荷之间提供基于标识的加密通信。应用程序网络连接的群集中的每个服务都会自动接收一个证书，该证书允许它证明其标识，并与同一应用程序网络中的其他服务建立受信任的加密连接。传输中的加密使用符合 FIPS 的加密。

mTLS 迁移策略

应用程序网络目前允许加密和未加密的流量。此方法可确保现有工作负荷继续正常运行，而新的或更新的工作负载会自动使用 mTLS 进行安全通信。这意味着，可以采用 mTLS 在工作负载之间安全通信，而无需停机。迁移完成后，可以更改为严格模式，以便强制实施身份验证。

Azure Kubernetes 应用程序网络中 mTLS 的优点

Azure Kubernetes 应用程序网络中 mTLS 可帮助你：

保护传输中的数据：可以自动加密所有服务到服务流量（符合 FIPS）。
验证服务标识：每个工作负荷都具有唯一的应用程序网络管理的根证书和中间证书。
简化操作：应用程序网络为用户处理证书颁发、轮换和吊销。

证书管理

Azure Kubernetes 应用程序网络提供由 Azure Key Vault 支持的证书管理，用于颁发和维护用于 mTLS 的证书。此服务跨连接到同一应用程序网络资源的所有 AKS 群集建立共享信任边界。

应用程序网络会自动管理根证书和中间证书的整个证书生命周期，包括预配、续订和轮换。这可确保工作负荷标识保持有效，并且通信在一段时间内保持安全。无需手动创建、存储或轮换证书。

下图演示了应用程序网络中的证书层次结构，其中显示了根 CA、中间 CA 和工作负荷证书的结构，以跨连接的群集建立信任：

证书层次结构和生命周期

创建应用程序网络资源时，会预配 根 CA 作为应用程序网络的信任定位点。 AKS 群集以成员身份加入应用程序网络时，应用程序网络会为由应用程序网络根 CA 签名的成员颁发 中间证书 。每个连接的 AKS 群集都使用其应用程序网络管理的中间证书向该群集中的工作负荷颁发生存期较短的 工作负荷证书 。

所有工作负荷证书都从应用程序网络根 CA 继承信任，从而跨资源维护统一信任边界。根证书和中间证书的轮换以透明方式处理，而不会造成任何停机或流量中断。此托管层次结构可确保应用程序网络中所有群集之间的一致可验证信任，同时自动维护每个证书的有效性。

从任何成员群集中，可以从命名空间istio-root-cert下的配置映射applink-system中获取根 CA 证书。

证书类型和轮换期

证书类型	范围	有效期	轮换期	Purpose
根证书授权中心 (Root CA)	Azure Kubernetes 应用程序网络	12 个月	6 个月	为连接到 Azure Kubernetes 应用程序网络的所有群集建立信任边界
中级 CA	集群	90 天	45 天	为集群内的工作负载颁发证书
工作负荷证书	工作量	24 小时	12 小时	对工作负荷进行身份验证并保护服务到服务通信

工作负荷标识和授权

随着应用程序的增长，服务通常需要在同一部署中的不同命名空间和环境之间安全地通信。管理证书并确保每个服务都可以验证与之通信的人员，这很快就会变得复杂且容易出错。 Azure Kubernetes 应用程序网络通过自动分配和管理工作负荷标识来消除此开销。

在连接应用程序网络的环境中，工作负载在命名空间内和跨命名空间安全通信。为了确保每个服务都受信任且经过身份验证，应用程序网络为每个工作负荷分配一个 可验证标识 ，该标识表示其命名空间和服务帐户。

每个应用程序网络工作负荷都会以 SPIFFE 格式自动接收唯一标识，其中包括其命名空间和服务帐户。标识的格式如下：

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

此标识嵌入到工作负荷证书中，用于在与其他工作负荷通信时证明服务的标识。 Azure Kubernetes 应用程序网络将此基于 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