Dapr 1.12.1

This update contains the following security fixes:
- Security: prevent Sentry and Injector from applying the daprsystem Configuration from a non control plane namespace.

Additionally, this patch release contains bug fixes:

• Fixed Sentry authentication validator rejecting valid requests.
• Fixed RabbitMQ not returning error when initialising component
• Fixed returning of HTTP status code in HTTP service invocation with resiliency enabled
• Fixed Dapr Runtime panic for malformed/unexpected workflow URLs
• Fixed an issue where Azure Blob Storage components cannot be used with Azure Blob Reader permission alone
• Fixed incorrect error message in the Azure EventHubs components
• Fixes an issue where the Consul nameresolution component only accepted IP addresses and not hostnames.
• Fixes an issue in the Redis PubSub component where a PubSub subscription could not recover under certain conditions.
• Security: Several dependency upgrades to address security issues

Security: Sentry and Injector only apply daprsystem Configuration from the control plane namespace

Problem

Sentry and Injector will apply the daprsystem configuration from a non-control plane namespace if the namespace name is alphabetically higher than the control plane namespace name.

Impact

Accidentally or maliciously, a Kubernetes user can write a Configuration in a non-control plane namespace that will be applied by Sentry and Injector.
This can re-write the Sentry CA, disable mTLS, or otherwise bring down the entire Dapr cluster.

Root cause

Sentry and Injector currently list Configurations, before matching on the list for the daprsystem Configuration, without filtering for namespaces.

Solution

Update Sentry and Injector to only get the daprsystem Configuration from the namespace where the Dapr control plane is installed, instead of listing all Configurations.

Fixed Sentry rejecting valid requests from Daprd

Problem

Dapr would fail to request an identity certificate from Sentry when residing in a Namespace or using a Service Account with a sufficiently long name.

Impact

Users on Dapr 1.12.0 can observe Dapr sidecars failing to start.

Root cause

Sentry validates that clients cannot request for an app ID which is over 64 characters in length.
Sentry also still accepts requests which use the legacy identifier of <namespace>:<service account> which was not taken account for when doing the 64 character evaluation.

Solution

Sentry now evaluates the actual app ID being requested, whether or not the client is using the legacy or app ID as the identifier.

Fixed RabbitMQ not returning error when initialising component

Problem

A RabitMQ component may be considered healthy, when in fact it failed to initialise.

Impact

Dapr or downstream consumers of Dapr would consider RabitMQ components to be healthy when in fact they were not, causing improper reporting of status.

Root cause

RabbitMQ was not returning an error when initialising a component, causing Dapr to consider the component healthy.

Solution

Failure to connect to RabbitMQ during initialization now causes an error to be returned, allowing Dapr to consider the component as unhealthy.

Fixed returning of HTTP status code in HTTP service invocation with resiliency enabled

Problem

With Resiliency enabled, in case of HTTP service invocation, if one application sends error status codes (HTTP codes <200 or >=400), Dapr returns a response with a generic 500 error, instead of the actual response error code.

Impact

Applications will receive the wrong status code in case of HTTP service invocation returning a failure error code with Resiliency enabled.

Root cause

A bug was discovered in how errors were handled when Resiliency was enabled, causing all errors from the application to be "swallowed" by Dapr.

Solution

Resiliency code now returns the correct status code to the application.

Fixed Dapr Runtime panic for malformed/unexpected workflow URLs

Problem

Invoking certain Workflow APIs using HTTP with malformed URLs can cause Dapr to panic.

Impact

Impacts users on Dapr 1.12.0.

Root cause

The Daprd metrics handler for workflows did not correctly handle malformed or unexpected URLs, and would panic if the URL was not in the expected format.

Solution

The Daprd metrics handler for workflows now correctly handles malformed or unexpected URLs.

Fixed an issue where Azure Blob Storage components cannot be used with Azure Blob Reader permission alone

Problem

The Azure Blob Storage component cannot be used with Azure Blob Reader permission alone.

Impact

Users on Dapr 1.12.0 cannot use the Azure Blob Storage component with Azure Blob Reader permission alone.

Root Cause

The component attempts to create a storage account (even when it exists already) but is not authorized to do so due to a lack of permission.

Solution

Added a boolean metadata option disableEntityManagement which now can be used to skip the attempt to create the storage container.

Fixed incorrect error message in the Azure EventHubs components

Problem

Azure EventHub component returns a warning message saying the storageAccountKey will be used but StorageAccountName is actually used in that condition.

Impact

Users on Dapr 1.12.0 may be confused by the warning message.

Root Cause

The component was using the StorageAccountName instead of the StorageAccountKey.

Solution

The component now emits the correct warning message.

Fixes an issue where the Consul nameresolution component only accepted IP addresses and not hostnames.

Problem

Dapr 1.12.0 was unable to add and resolve hostnames using the Consul nameresolution component.

Impact

Users on Dapr 1.12.0 were unable to resolve hostnames using the Consul nameresolution component.

Root Cause

A previous community contribution to improve IPv6 support inadvertently removed support for host names by returning an error for any string that does not parse as an IPv4 or IPv6 address.

Solution

Support for hostnames was added once again.

Fixes an issue in the Redis PubSub component where a PubSub subscription could not recover under certain conditions.

Problem

The Redis PubSub component could experience a rare situation where PubSub subscriptions would seize to function, causing the Dapr sidecar to print Redis error logs containing the word NOGROUP indefinitely.

Root Cause

The NOGROUP message is indicative of the consumer group no longer existing. This could be because the group or stream was manually deleted outside of Dapr or because the external Redis server was restarted/reconfigured.

Solution

To avoid the excessive NOGROUP logs in this rare situation Dapr will now attempt to recreate the consumer group for the given topic/stream when this error is encountered.

Security: Several dependency upgrades to address security issues

• CVE-2023-45283: Windows specific vulnerability in GO standard library path/filepath
• gRPC-Go HTTP/2 Rapid Reset vulnerability
• HTTP/2 rapid reset can cause excessive work in net/http
• NATS.io: xkeys seal encryption used fixed key for all encryption
• NATS.io: Adding accounts for just the system account adds auth bypass