Allow only authorized endpoints to send events to event grid

1
votes

I am working on a project which uses Azure Event Grid where a web application sends a custom event to event grid and a web-hook within a separate application is used to subscribe to these events.

It looks like it is secure on the web-hook side since only you can add the specific web hook to be used as the event grid subscription. However, I did not find much information on how to restrict event grid to receive events only from a specific endpoint. Right now it only provides you with an endpoint and a topic key which must be used when sending events to the topic. If someone manages to get hold of both the endpoint and the token key then "malicious events" can be sent to the event grid.

Is there a way on how to restrict event grid to only accept events from a particular source, or is storing and retrieving the key from Key Vault, the most secure option available?

1
azureazure-eventgridazure-authenticationazure-security
have a look at the docs.microsoft.com/en-us/azure/event-grid/event-domains – Roman Kiss

1 Answers

1
votes

When publishing messages to a topic, you can authenticate either by using a key or a SAS token.

  1. Using a key is the simplest way to authenticate, but like you've mentioned, if stolen, could lead to malicious events being sent.

    One way to secure this approach is to use KeyVault as you've mentioned. Clients could securely connect to KeyVault using Managed Identity (if running on Azure) or the Client Credentials flow.

  2. Using SAS tokens is the recommended way to secure your publish endpoint. For this, you will have to generate tokens as and when needed using a key (The same key as in 1)

    In this approach, you could have an API (like an Azure Function for example) which generates the SAS tokens on behalf of your clients. This API would still need the key (which could be in KeyVault) to generate the SAS tokens.

  3. Another approach would be to have an API which could forward events to Event Grid, upon authentication/authorization. This API would still need access to the key.

    This could be achieved in a couple of ways as well like