配置 Azure Kubernetes 服务的身份验证

已完成

在 Azure Kubernetes 服务 (AKS) 中部署和维护群集时，需要实施相应的方法来管理对资源和服务的访问。 如果没有这些控件：

• 帐户可以访问不必要的资源和服务。
  
• 跟踪用于执行更改的凭据可能很困难。

使用 Microsoft Entra ID

最佳实践指导：使用 Microsoft Entra 集成部署 AKS 群集。 使用 Microsoft Entra ID 可以集中处理标识管理层。 访问 AKS 群集时，用户帐户或组状态的任何更改会自动更新。 使用角色、群集角色或绑定将用户或组范围限制为最小权限量。

Kubernetes 群集的开发人员和应用程序所有者需要访问不同的资源。 Kubernetes 缺少一个标识管理解决方案，无法让你控制用户可与之交互的资源。 相反，可以将群集与现有标识解决方案集成，例如企业就绪标识管理解决方案 Microsoft Entra ID。

通过 AKS 中与 Microsoft Entra 集成的群集，可以创建可定义对资源的访问权限的“角色”或“ClusterRoles”。 然后将角色绑定到 Microsoft Entra ID 中的用户或组。

下图显示了 Microsoft Entra 集成，以及如何控制对资源的访问：

1. 开发人员可使用 Microsoft Entra ID 进行身份验证。
   

2. Microsoft Entra 令牌颁发终结点会颁发访问令牌。

3. 开发人员可使用 Microsoft Entra 令牌执行操作，例如 kubectl create pod。

4. Kubernetes 使用 Microsoft Entra 验证令牌，并提取开发人员的组成员身份。

5. 同时应用了 Kubernetes RBAC 和群集策略。

6. 开发人员的请求是否成功具体取决于前面的 Microsoft Entra 组成员身份和 Kubernetes RBAC 验证以及策略。

使用 Kubernetes 基于角色的访问控制 (Kubernetes RBAC)

最佳实践指导：使用 Kubernetes RBAC 定义对群集资源的用户或组权限。 创建角色和绑定，用于分配所需的最少量权限。 与 Microsoft Entra 集成，以自动更新任何用户状态或组成员身份更改，并保持对群集资源的访问权限处于最新状态。

在 Kubernetes 中，可以提供对群集资源的精确访问控制。 在群集级别或针对特定命名空间定义权限。 确定可使用哪些权限管理哪些资源。 然后，将这些角色应用到具有绑定的用户或组。

developer1@contoso.com 对 AKS 群集进行身份验证后，便对 finance-app 命名空间中的资源拥有了完全权限。 这样，即可以逻辑方式隔离和控制对资源的访问权限。 将 Kubernetes RBAC 与 Microsoft Entra ID 集成配合使用。

使用 Azure RBAC

最佳实践指导：使用 Azure RBAC 定义一个或多个订阅中 AKS 资源所需的最低用户和组权限。

完全操作 AKS 群集需要两个级别的访问权限：

• 访问 Azure 订阅上的 AKS 资源。
• 此访问级别允许：
  • 使用 AKS API 控制对群集的扩展或升级
  • 拉取 kubeconfig。
• 访问 Kubernetes API。
• 此访问级别由以下任一项控制：
  • KUBERNETES RBAC（传统做法）或
  • 通过将 Azure RBAC 与 AKS 集成以实现 Kubernetes 授权。

使用 Pod 托管标识

不要在 Pod 或容器映像中使用固定的凭据，因为它们存在泄漏或滥用的风险。 请改用 Pod 标识以通过 Microsoft Entra ID 来自动请求访问权限。

Pod 需要身份验证凭据，才可访问其他 Azure 资源（例如 Azure Cosmos DB、Key Vault 或 Blob 存储）。 可以使用容器映像定义身份验证凭据，或将其作为 Kubernetes 密码插入。 无论采用哪种方式，都需要手动创建和分配这些凭据。 这些凭据通常会在不同的 Pod 之间重复使用，并且不会定期轮换。

使用 Azure 资源的 Pod 托管标识（预览），可通过 Microsoft Entra ID 自动请求对服务的访问权限。 Pod 托管标识目前为 AKS 提供预览版。

Microsoft Entra Pod 托管标识（预览版）支持两种操作模式：

• 标准模式：在此模式下，将会向 AKS 群集部署以下 2 个组件：
  • 托管标识控制器 (MIC)：一种 Kubernetes 控制器，通过 Kubernetes API 服务器监视对 Pod、AzureIdentity 和 AzureIdentityBinding 所做的更改。 检测到相关更改时，MIC 会根据需要添加或删除 AzureAssignedIdentity。 具体而言，如果计划了 Pod，MIC 会将 Azure 上的托管标识分配给节点池在创建阶段使用的基础虚拟机规模集。 删除所有使用该标识的 Pod 时，MIC 会从节点池的虚拟机规模集中删除标识，除非其他 Pod 使用相同的托管标识。 创建或删除 AzureIdentity 或 AzureIdentityBinding 时，MIC 会执行类似的操作。
    
  • 节点托管标识 (NMI)：是在 AKS 群集中每个节点上作为 DaemonSet 运行的 Pod。 NMI 会拦截对每个节点上的 Azure 实例元数据服务的安全令牌请求。 它会将请求重定向到自身并验证 Pod 是否有权访问它为其请求令牌的标识，并代表应用程序从 Microsoft Entra 租户中提取令牌。
    
• 托管模式：在此模式下，只有 NMI。 标识需要由用户手动分配和管理。 在此模式下，使用 az aks pod-identity add 命令将 Pod 标识添加到 Azure Kubernetes 服务 (AKS) 群集时，它会在 --namespace 参数指定的命名空间中创建 AzureIdentity 和 AzureIdentityBinding，而 AKS 资源提供程序则会将 --identity-resource-id 参数指定的托管标识分配给 AKS 群集中每个节点池的虚拟机规模集。
  

注意

如果你决定改用 AKS 群集加载项安装 Microsoft Entra pod 托管标识，安装程序将使用托管模式。

与standard模式相比，managed模式具备以下优点：

• 节点池虚拟机规模集上的标识分配可能需要 40-60 秒。 对于需要访问标识且不能接受分配延迟的定时任务或应用程序，最好使用 managed 模式，因为标识已经预先分配给了节点池的虚拟机规模集。 请手动执行操作或使用 az aks pod-identity add 命令。
  
• 在 standard 模式下，MIC 要求对 AKS 群集使用的虚拟机规模集具有写入权限和对用户分配的托管标识的 Managed Identity Operator 权限。 在 managed mode 下运行时，由于没有 MIC，因此不需要角色分配。

Pod 托管标识不会手动定义 Pod 凭据，而是会实时请求访问令牌，并使用该令牌访问仅为它们分配的资源。 在 AKS 中，有两个组件处理操作，以便 Pod 使用托管标识：

• 节点管理标识 (NMI) 服务器是在 AKS 群集中每个节点上作为守护程序集运行的 pod。 NMI 服务器侦听发送到 Azure 服务的 pod 请求。
• Azure 资源提供程序会查询 Kubernetes API 服务器，并检查与 Pod 对应的 Azure 标识映射。

当 Pod 从 Microsoft Entra ID 请求安全令牌以访问 Azure 资源时，网络规则会将流量重定向到 NMI 服务器。

1. NMI 服务器：

   • 根据远程地址请求访问 Azure 资源的 Pod 标识。
   • 查询 Azure 资源提供程序。

2. Azure 资源提供程序会检查 AKS 群集中的 Azure 标识映射。

3. NMI 服务器将根据 Pod 的标识映射从 Microsoft Entra ID 请求访问令牌。

4. Microsoft Entra 会提供对 NMI 服务器的访问权限，然后该权限将返回给 pod。

   • 然后，pod 可以使用此访问令牌请求对 Azure 中资源的访问权限。

在以下示例中，开发人员创建使用托管标识请求 Azure SQL 数据库访问权限的 Pod：

1. 当 Pod 请求访问资源时，群集运算符会创建一个服务帐户来映射标识。
2. NMI 服务器与 Azure 资源提供程序一起部署，以将任何对访问令牌的 Pod 请求中继到 Microsoft Entra ID。
3. 开发人员使用托管标识部署一个 pod，该 pod 可通过 NMI 服务器请求访问令牌。
4. 该令牌将返回给 Pod，并用于访问 Azure SQL 数据库