Azure Kubernetes Workload Identity Overview
当我们在Kubernetes群集中运行工作负载时，无论工作负载是简单还是复杂，通常都需要以安全且可管理的方式访问到其他与其交互的受管理的资源。一般面对这种情况时，大多数的人员会选择在代码内嵌入应用的访问凭据，虽然这是一种很简单的实现方式，但这也会降低代码的安全性，同时也会使诸如凭据轮换或更新之类的任务成为负担。
在Azure中，解决这些问题的方式很简单，如果运行代码的服务支持托管标识，则只需要使用托管标识即可。同样，Azure Kubernetes服务也是如此，在AKS中，支持一个叫做Pod Identity的功能，该功能与此类管理身份相关联，在AKS中运行POD时，POD中的容器可以轻松的请求令牌，安全的访问Azure资源。
但是AKS中的Pod Identity一直处于预览状态并且它将被工作负载联合身份验证所取代。值得注意的是，AAD工作负载联合身份验证不限于Kubernetes服务，它还适用于其他工作负载，如Github Action工作流等。这也意味着 Kubernetes 的工作负载身份不仅适用于AKS，同时也适用于云端和本地的其他发行版。
虽然Pod Identity和workload Identity所实现的目标是相同的，但他们的工作方式是完全不同的。Pod Identity稍微复杂一些，因为它使用 Kubernetes 自定义资源定义 (CRD) 并且需要拦截IMDS流量的 Pod。拦截该流量可能会导致其他 pod 出现问题，这意味着需要进行额外的配置工作才能排除这些 pod。
Workload Identity工作方式
Workload Identity和Pod Identity的工作方式有很大的不同，在Workload Identity中，AKS群集充当令牌的颁发者，Azure AD使用 OpenID Connect 发现公共签名密钥并验证服务帐户令牌的真实性，然后再将其交换为 Azure AD 令牌。工作负载可以使用 Azure 身份客户端库或 Microsoft 身份验证库将投射到其卷的服务帐户令牌交换为 Azure AD 令牌。
下表描述了 Azure AD workload Identity所需的 OIDC 颁发者端点：
端点 | 描述 |
{IssuerURL}/.well-known/openid-configuration | 也称为 OIDC 发现文档。这包含有关发行者配置的元数据。 |
{IssuerURL}/openid/v1/jwks | 这包含 Azure AD 用于验证服务帐户令牌真实性的公共签名密钥。 |
下图总结了使用 OpenID Connect 的身份验证序列。
优势
相比于Pod Identity而言，Workload Identity更易于使用和部署，并且克服了 Azure AD pod 管理身份中的几个限制：
l 消除身份分配存在的规模和性能问题
l 支持托管在任何云或本地的 Kubernetes 集群
l 支持 Linux 和 Windows 工作负载
l 不再需要拦截Azure 实例元数据服务(IMDS) 流量的自定义资源定义和
l 避免了上一次迭代中的集群角色分配等复杂且容易出错的安装步骤
