Limitation in Using Azure Event Grid Input Binding with Dapr in Azure Container Apps

[sohocine]

This issue is a:

• [x] bug report -> please search issues before submitting
• [x] documentation issue or request
• [ ] regression (a behavior that used to work and stopped in a new release)

Issue description

There is a significant limitation when using Azure Event Grid as an input binding with Dapr in Azure Container Apps. The issue stems from the requirement for Event Grid to communicate with subscriber endpoints over HTTPS, which conflicts with Dapr's typical setup of using HTTP for internal communication between the application and the Dapr sidecar.

Steps to reproduce

1. Configure a Dapr component for Azure Event Grid input binding in an Azure Container App environment.
2. Attempt to set the subscriberEndpoint to the local Dapr sidecar address (e.g., http://localhost:<dapr-port>).
3. Observe the failure due to Event Grid's requirement for an HTTPS endpoint.

Expected behavior The Dapr sidecar should be able to handle Event Grid events internally without requiring an external HTTPS endpoint, allowing for environment-level configuration of the input binding.

Actual behavior Event Grid requires a publicly accessible HTTPS endpoint, making it impossible to use the Dapr sidecar's HTTP address as the subscriber endpoint.

Additional context

This issue occurs in Azure Container Apps, where direct control over network configurations is limited. It undermines the simplicity and flexibility that Dapr aims to provide for setting components that can be used by multiple container apps within the same environment.

[anthonychu]

Event Grid requires an external HTTPS endpoint. Haven't tried this with the Dapr input binding, but according to the spec, looks like you'll need to do a few things:

• Set handshakePort to "9000". The sidecar will listen to this point for incoming webhook requests. Don't set this to a port already in use such as your app's port or Dapr's 3500.
• Set up an external ingress on the app, with 9000 as the target port. This allows Event Grid to send webhook requests to the Dapr sidecar on each replica of your app.
• Set subscriberEndpoint to https://<app_fqdn>/. For example, https://myapp.happypond-abcdef.westus.azurecontainerapps.io/. The Dapr spec mentions a <path> but is unclear about what that is.

If you don't want to expose a public ingress, try using pull delivery instead.

[sohocine]

This would defeat the purpose of having a dapr component, which are set at the Container Apps Environment level; so that the bindings remain usable by one or more different container apps on the same environment. By hardcoding a specific container app in the SubscriberEndpoint value, it is at best just creating the Subscriber automatically on Event Grid, but then would completely bypass dapr for delivering events. And I would have to create a specific input binding for every container app that should subscribe to the same topic.

Pull delivery just won't cut it in my case, the whole goal is to use push.

[anthonychu]

It looks like that's how the Event Grid input binding in Dapr works today. It always needs a subscribe endpoint that points to a specific app. If you deployed it to Kubernetes, the component would still be specific to a given deployment/service. @greenie-msft can help verify.

[sohocine]

Would it be possible to create & test a simple example on your end? Can't find any speific documentation or someone who made it work. I'm struggling to get the metadata right on the dapr component, especially the subscriberEdpoint and handshakePort when dealing with container apps.

[anthonychu]

handshakePort is the port that the binding opens to receive Event Grid webhook requests. The docs use "9000" as an example, I would use that too. You'd need to configure your app with an external HTTP ingress and set target port to 9000, so that HTTP requests are routed to the Dapr sidecar's webhook listener.

subscriberEndpoint might be https://myapp.happypond-abcdef.westus.azurecontainerapps.io/api/events. It's unclear from the docs, but based on this example (from this issue), it seems like the right value.

Dapr support for Event Grid is currently in beta. Looks like there is still some remaining work (https://github.com/dapr/components-contrib/issues/1917, https://github.com/dapr/components-contrib/issues/3322). It also uses a service principal to create the Event Grid subscription, which is a bit outdated and could be replaced with managed identity. I'm not sure what the timeline is before it's stable or if the binding will change. Since the binding isn't providing a whole lot, you might want to consider changing your app to receive event grid events directly and not using Dapr for this.

[microsoft-github-policy-service[bot]]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.