Allow Webhooks to be delivered into VNETS
Currently Webhook events can only be delivered to public IPs.
For security reasons, we have a situation where we liked to be Webhook events to be delivered to VMs, Kubernetes Clusters etc. inside a VNET.
As the target VNET can only be configured with permissions to this VNET, this would also ease the for requirements on authentication on both sides (for which there are other improvement suggestions).
I understand your requirements for communicating via the private IP address space to an endpoint that receives events. We are sympathetic to your needs and to this requirement.
Please note that there is an approach that can achieve basically the same level of security robustness and that is documented here: https://docs.microsoft.com/en-us/azure/event-grid/consume-private-endpoints. You may be asking why the proposed approach uses the public IP space for a part of the solution which is not what you want. Security-wise this approach should be just as strong as private links, for example. If you want to know why private links do not solve your problem, please read on. We are working on another potential approach (not private links and no VNET injection) to address this requirement besides the current solution described in the link above. However, we still do not have a date for it. Stay tuned and thanks for the feedback.
Clarifying private links and VNET injection
This kind of request is often described in terms of using private links (private IP endpoints) to communicate and hence avoid leaking any information to the public internet. I want to clarify that private links support was designed for clients connecting to a service…and only in that direction. Private links do not apply and was not designed for those situations in which the service connects (sends events) to your endpoint, which is what Event Grid does. You can publish events to Event Grid using private links (a client connects to a service scenario), but private links do not apply when Event Grid sends events because your app/solution does not connect as a client to Event Grid. It is the other way around.
Now, sometimes users want a solution referred as “VNET injection” where a service is deployed to your VNET. That is not on the roadmap and it is unlikely that we will be doing that.
Thanks again for your feedback!
Oisin Grehan commented
It was extremely disappointing to discover this doesn't work. We, the consumers (devs) of Azure, don't care about the internal design decisions for event grid which led to this problem - we only care about the higher level semantics. Please permit deploying an event grid topic (or better yet, a domain) into a vnet.
Donovan Bergin commented
Having the flexibility to create webhooks to our k8s cluster would provide us some much needed flexibility. Would love to see this soon!
Jordan Restifo commented
Yes please! It is quite a pain to have a VM ingest any Event Grid events. Basically I have a function app with Vnet integration which subscribes to events, and when it receives them it posts to a .NET core API running in the VM. When publishing, the .NET core app can make use of a private endpoints. Whole thing is a very circuitous path just for some simple pub/sub with Azure infrastructure.