-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'master' into helm-chart-operator-port-443
- Loading branch information
Showing
21 changed files
with
556 additions
and
71 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,185 @@ | ||
# 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.](#security-sentry-and-injector-only-apply-daprsystem-configuration-from-the-control-plane-namespace) | ||
|
||
Additionally, this patch release contains bug fixes: | ||
|
||
- [Fixed Sentry authentication validator rejecting valid requests.](#fixed-sentry-rejecting-valid-requests-from-daprd) | ||
- [Fixed RabbitMQ not returning error when initialising component](#fixed-rabbitmq-not-returning-error-when-initialising-component) | ||
- [Fixed returning of HTTP status code in HTTP service invocation with resiliency enabled](#fixed-returning-of-http-status-code-in-http-service-invocation-with-resiliency-enabled) | ||
- [Fixed Dapr Runtime panic for malformed/unexpected workflow URLs](#fixed-dapr-runtime-panic-for-malformedunexpected-workflow-urls) | ||
- [Fixed an issue where Azure Blob Storage components cannot be used with Azure Blob Reader permission alone](#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](#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-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.](#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-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`](https://github.com/advisories/GHSA-vvjp-q62m-2vph) | ||
- [gRPC-Go HTTP/2 Rapid Reset vulnerability](https://github.com/dapr/components-contrib/security/dependabot/124) | ||
- [HTTP/2 rapid reset can cause excessive work in net/http](https://github.com/dapr/components-contrib/security/dependabot/111) | ||
- [NATS.io: xkeys seal encryption used fixed key for all encryption](https://github.com/dapr/components-contrib/security/dependabot/120) | ||
- [NATS.io: Adding accounts for just the system account adds auth bypass](https://github.com/dapr/components-contrib/security/dependabot/116) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
# Dapr 1.12.2 | ||
|
||
This patch release contains bug fixes: | ||
|
||
- [Fixed mTLS configuration](#fixed-mtls-configuration) | ||
|
||
## Fixed mTLS configuration | ||
|
||
### Problem | ||
|
||
The mTLS configuration was always enabled for Dapr sidecards in Kubernetes, regardless of the `daprsystem` configuration. | ||
|
||
### Impact | ||
|
||
Users on Dapr 1.12.1 could not disable mTLS for Dapr sidecars in Kubernetes. | ||
|
||
### Root cause | ||
|
||
The `daprsystem` configuration was not being read correctly by the sidecar injector. | ||
|
||
### Solution | ||
|
||
The `daprsystem` configuration is now read correctly by the sidecar injector and the mTLS option is correctly set for Dapr sidecars in Kubernetes. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.