发布日期: 2026-08-15
版本号: v1.16.19

Dapr 1.16.19 版本更新包含两个错误修复：首先，修复了 Azure 组件认证链在遇到 SPIFFE 凭证不可用时未能正确回退到后续凭证（如托管标识）的问题，现在该凭证在缺失时会被标记为不可用以允许链继续尝试；其次，修复了 SPIFFE SVID 源未能传播到组件操作调用上下文的问题，使其现在可在操作级别用于认证，从而支持如 Azure SDK 等更透明的身份验证机制。

更新内容 （中文）

Dapr 1.16.19

本次更新包含以下错误修复：

Azure组件认证在SPIFFE凭据处停止而非回退

问题描述

Azure（Microsoft Entra ID）组件通过按顺序尝试凭据链进行认证，直到其中一个成功为止。 当设置了azureClientId和azureTenantId时，该链会包含SPIFFE工作负载身份凭据。如果没有可用的SPIFFE JWT SVID源，认证链会在此步骤停止：

ChainedTokenCredential: failed to acquire a token.
Attempted credentials:
	ClientAssertionCredential: failed to get JWT SVID source from context

认证链中后续的凭据（如托管身份或Azure CLI）从未被尝试，因此即使存在可用的凭据，组件认证也会失败。

影响范围

在以下任一配置下，使用Dapr 1.16.0或更高版本（SPIFFE凭据已加入默认链）时会受到影响：

  • 设置了azureClientId和azureTenantId但未提供客户端密钥或证书的Azure组件，依赖于默认链中后续的凭据（例如托管身份或Azure CLI）。
  • 显式定义了azureAuthMethods列表，将spiffeworkloadidentity放在其他方法之前（例如spiffeworkloadidentity,managedidentity），期望在SPIFFE未配置时进行回退。

根本原因

ChainedTokenCredential仅会继续尝试报告credentialUnavailableError的凭据；其他任何错误都被视为致命错误并终止认证链。 当上下文未携带JWT SVID源时，SPIFFE凭据会返回普通错误，因此前置条件缺失被视为致命的认证失败，而非尝试下一个凭据的信号。

解决方案

现在，当不存在JWT SVID源时，SPIFFE凭据会在发起任何令牌请求之前报告自身不可用，这正是ChainedTokenCredential继续尝试链中下一个凭据所需的行为。 默认链和显式排序的azureAuthMethods列表现在都能按预期进行回退，而当SPIFFE源已配置时的行为保持不变。

SPIFFE SVID组件操作传播

问题描述

SPIFFE SVID源未被传播到组件操作调用中。因此，任何希望使用SPIFFE ID进行认证的组件都必须在其init方法中捕获该源并显式管理。像Azure SDK这样能够在存在SPIFFE SVID源时透明地使用它的SDK无法实现这一点。

影响范围

Azure组件无法在不显式处理源的情况下利用SPIFFE ID进行认证，这也阻碍了未来在其他组件中对基于SPIFFE的认证的支持。

根本原因

SPIFFE SVID源仅附加到组件的init方法上下文，而未附加到传递到操作调用的上下文中。

解决方案

现在，SPIFFE SVID源已附加到传递到操作调用的上下文中，允许组件基于单个操作使用SPIFFE ID进行认证。

更新内容 （原始）

Dapr 1.16.19

This update contains the following bug fixes:

Azure component authentication halting at the SPIFFE credential instead of falling back

Problem

Azure (Microsoft Entra ID) components authenticate by trying a chain of credentials in order until one succeeds. When azureClientId and azureTenantId were set, the chain included the SPIFFE workload identity credential, and if no SPIFFE JWT SVID source was available the chain stopped at that step:

ChainedTokenCredential: failed to acquire a token.
Attempted credentials:
	ClientAssertionCredential: failed to get JWT SVID source from context

Credentials later in the chain, such as managed identity or the Azure CLI, were never attempted, so the component failed to authenticate even though a working credential was available.

Impact

You were affected on Dapr 1.16.0 or later (where the SPIFFE credential joined the default chain) in either of these configurations:

  • An Azure component with azureClientId and azureTenantId set but no client secret or certificate, relying on a later credential in the default chain (for example managed identity or the Azure CLI).
  • An explicit azureAuthMethods list placing spiffeworkloadidentity before another method (for example spiffeworkloadidentity,managedidentity), expecting fallback when SPIFFE is not configured.

Root Cause

ChainedTokenCredential only continues past a credential that reports a credentialUnavailableError; any other error is treated as fatal and ends the chain. The SPIFFE credential returned a plain error when the context carried no JWT SVID source, so a missing prerequisite was treated as a fatal authentication failure rather than a signal to try the next credential.

Solution

The SPIFFE credential now reports itself as unavailable when no JWT SVID source is present, before any token request is made, which is exactly what ChainedTokenCredential requires to continue to the next credential in the chain. Both the default chain and explicitly ordered azureAuthMethods lists now fall through as expected, and behavior when a SPIFFE source is configured is unchanged.

SPIFFE SVID component operation propagation

Problem

The SPIFFE SVID source was not propagated to component operation calls. As a result, any component that wanted to use the SPIFFE ID for authentication had to capture the source in its init method and manage it explicitly. SDKs such as the Azure SDK, which can transparently use the SPIFFE SVID source when it is present on the context, were unable to do so.

Impact

Azure components could not leverage the SPIFFE ID for authentication without explicitly handling the source, and this also blocked future support for SPIFFE-based authentication in other components.

Root Cause

The SPIFFE SVID source was attached only to the component’s init method context, not to the context passed into operation calls.

Solution

The SPIFFE SVID source is now attached to the context passed into operation calls, allowing components to use the SPIFFE ID for authentication on a per-operation basis.

下载链接