Azure AKS中使用工作负载身份进行Azure CLI认证的最佳实践

Azure AKS中使用工作负载身份进行Azure CLI认证的最佳实践

AKS Azure Kubernetes Service 项目地址: https://gitcode.com/gh_mirrors/ak/AKS

背景介绍

在Azure Kubernetes Service(AKS)环境中，应用程序需要安全地访问Azure资源时，传统方式通常使用服务主体或托管身份。随着技术演进，Azure提供了更安全、更灵活的工作负载身份(Workload Identity)方案，它通过联合身份凭证将Kubernetes服务账户与Azure托管身份关联起来。

常见误区

许多开发者在初次使用工作负载身份时，容易陷入以下误区：

1. 错误地尝试使用az login --identity命令，这是针对虚拟机托管身份的认证方式
2. 混淆了即将停用的Pod托管身份与工作负载身份的区别
3. 未正确配置Kubernetes服务账户的标签注解

正确认证方法

要在AKS Pod中使用工作负载身份通过Azure CLI进行认证，必须使用联合令牌方式：

az login --federated-token "$(cat $AZURE_FEDERATED_TOKEN_FILE)" \
         --service-principal \
         -u $AZURE_CLIENT_ID \
         -t $AZURE_TENANT_ID

关键环境变量说明

• AZURE_FEDERATED_TOKEN_FILE: Kubernetes自动注入的联合令牌文件路径
• AZURE_CLIENT_ID: 关联的Azure托管身份客户端ID
• AZURE_TENANT_ID: Azure租户ID

权限配置要点

即使认证成功，要访问Azure资源仍需确保：

1. 为托管身份分配适当的RBAC角色
2. 角色范围需覆盖目标资源
3. 最少权限原则，仅授予必要的访问权限

实施建议

1. 确保AKS集群已启用工作负载身份功能
2. 正确配置服务账户的注解，关联Azure托管身份
3. 部署Pod时包含必要的环境变量
4. 测试认证后，验证资源访问权限是否按预期工作

总结

工作负载身份为AKS中的工作负载提供了安全、灵活的Azure资源访问方案。理解其工作原理并正确实施，可以避免常见的认证失败问题，同时遵循云安全最佳实践。相比即将停用的Pod托管身份方案，工作负载身份代表了更现代的云原生身份管理方式。

AKS Azure Kubernetes Service 项目地址: https://gitcode.com/gh_mirrors/ak/AKS