Important: Users who rely on gRPC-to-gRPC service invocation (legacy, non proxy-based) are encouraged to upgrade to Dapr 1.11.5 before upgrading existing deployments to 1.12.x, to prevent temporary issues during a rollout of Dapr 1.12.x.
This update contains the following security fixes:
- Security: prevent Sentry and Injector from applying the
daprsystemConfiguration from a non control plane namespace.
Additionally, this patch release contains bug fixes:
- Fixed gRPC-to-gRPC service invocation when the
ServiceInvocationStreamingfeature is enabled.
- Fixed invoke remote stream from closing stream before EOF
- Fixed failures downgrading from 1.12.x to 1.11.x
- Fixed returning of HTTP status code in HTTP service invocation with resiliency enabled
Security: Sentry and Injector only apply
daprsystem Configuration from the control plane namespace
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.
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.
Sentry and Injector currently list Configurations, before matching on the list for the
daprsystem Configuration, without filtering for namespaces.
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 gRPC-to-gRPC service invocation when the
ServiceInvocationStreaming feature is enabled.
ServiceInvocationStreaming preview flag is enabled, the
type_url property is removed when performing service invocation. This can cause failures when performing the gRPC-to-gRPC service invocation (legacy, non proxy-based).
Aside from the immediate impact on users who have the
ServiceInvocationStreaming feature flag enabled, this issue can also impact users who rely on the (legacy, non proxy-based) gRPC-to-gRPC service invocation capabilities of Dapr, and who are in the process of upgrading to Dapr 1.12.x.
In fact, a Dapr 1.12.x sidecar would always attempt to communicate with Dapr 1.11.x using the streaming APIs, so using Dapr 1.12.x to invoke Dapr 1.11.x would cause the issue to appear even if
ServiceInvocationStreaming is not enabled in Dapr 1.11.x
An issue was detected in the internal implementation of service invocation when streaming was enabled.
We fixed the issue in Dapr 1.12.0 and 1.11.5.
Fixed invoke remote stream from closing stream before EOF
When performing service invocation using resiliency, the service invocation can end with an EOF error rather than successfully returning the result.
ServiceInvocationStreaming is enabled, service invocation is unusable when using resiliency.
A bug in the code meant that the gRPC stream was closed before the EOF was sent to the client.
Fix the code so that the EOF is sent before the stream is closed.
Fixed failures downgrading from 1.12.x to 1.11.x
When downgrading from 1.12.x to 1.11.x, the Dapr sidecar injector will fail to inject the sidecar into pods, failing with validating certificates against the Certification Authority.
Users who downgrade the Dapr installation from 1.12.x to 1.11.x will result in their Dapr cluster being in broken state.
1.12 made a change that the Injector's serving certificate is now signed by the Dapr CA (Certification Authority), rather than a separate CA managed through Helm.
The 1.11 Helm chart will always use an existing CA in the Webhook Configuration if it exists, meaning the serving certificate and CA will mismatch on a downgrade.
The 1.11 Helm chart will correctly update the webhook Configuration to use the Dapr CA when downgrading from 1.12 to 1.11.
Fixed returning of HTTP status code in HTTP service invocation with resiliency enabled
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.
Applications will receive the wrong status code in case of HTTP service invocation returning a failure error code with Resiliency enabled.
A bug was discovered in how errors were handled when Resiliency was enabled, causing all errors from the application to be "swallowed" by Dapr.
Resiliency code now returns the correct status code to the application.
Security wording was detected, but no CVEs were found.
- 🔍View and search all dapr releases.
- 🛠️Create and share lists to track your tools.
- 🚨Setup notifications for major, security, feature or patch updates.
- 🚀Much more coming soon!