Event Grid Security: IAM Policies and Network Security

Understanding Event Grid Security

Azure Event Grid is a fully managed event routing service that enables event-driven architectures. Security for Event Grid operates on two fundamental layers: Identity and Access Management (IAM) policies that control who can perform operations on Event Grid resources, and Network Security that governs how traffic reaches those resources. Together, these layers form a defense-in-depth strategy that protects your event infrastructure from unauthorized access, data exfiltration, and network-based threats.

What Event Grid Security Encompasses

Event Grid security combines Azure's built-in role-based access control (RBAC) with network isolation capabilities. On the IAM side, you define which security principals—users, groups, service principals, or managed identities—can publish events, create subscriptions, or manage topics and domains. On the network side, you control ingress traffic through private endpoints, service tags, and IP firewall rules that restrict which networks or public IP addresses can reach your Event Grid resources.

This dual-layer model is critical because Event Grid often sits at the intersection of event producers (which may be internal services or external partners) and event consumers (such as Azure Functions, Logic Apps, or custom webhooks). Securing both the management plane and the data plane prevents scenarios where a misconfigured subscription inadvertently exposes internal endpoints or where a compromised publisher floods your system with malicious events.

Why Event Grid Security Matters

Without proper IAM and network controls, several risks emerge:

Unauthorized event publication: A malicious actor could publish events to your custom topics, triggering downstream handlers with crafted payloads.
Subscription hijacking: An attacker with write permissions could create event subscriptions that exfiltrate data to external webhook endpoints they control.
Management plane compromise: Someone with elevated permissions could delete topics, disable subscriptions, or alter diagnostic settings, causing silent failures in your event pipeline.
Data exfiltration over public endpoints: If network restrictions are absent, event data could traverse the public internet, increasing exposure to interception or unauthorized access.

Implementing robust security ensures that your event-driven workflows remain reliable, compliant with regulatory requirements, and resilient against both external and internal threats.

IAM Policies for Event Grid

🚀 Deploy your AI agent in 10 minutes

Managed Hermes hosting. Zero DevOps. 100M tokens/mo included.

Try it free →

Built-in Roles and Their Scope

Azure provides several built-in roles specifically tailored for Event Grid operations. These roles can be assigned at the subscription, resource group, or individual resource level, giving you granular control over who can perform what actions:

Event Grid Contributor: Grants full management plane access—create, update, delete topics, domains, and event subscriptions—but does not grant data plane publish access.
Event Grid Data Sender: Allows publishing events to topics and domains. This role is essential for event producers and is scoped purely to the data plane.
Event Grid Data Contributor: Combines data sender capabilities with the ability to manage event subscriptions (create, delete, update) on a topic or domain. This is useful for consumers that also need to configure their own subscriptions.
Event Grid EventSubscription Contributor: Grants permission to create and manage event subscriptions but not to publish events or modify the topic itself.
Event Grid EventSubscription Reader: Read-only access to event subscriptions, suitable for auditing or monitoring scenarios.

Custom IAM Policies

When built-in roles are too broad or too narrow, you can craft custom role definitions. Custom roles let you specify exactly which actions are permitted and denied. For example, you might want a role that allows publishing events but only to a specific topic within a resource group, while preventing subscription creation.

The following code example demonstrates a custom role definition in JSON that permits event publishing but explicitly denies subscription management:

{
  "Name": "Custom Event Publisher - No Subscription Access",
  "Description": "Publish events to Event Grid topics, cannot manage subscriptions",
  "Actions": [
    "Microsoft.EventGrid/topics/write",
    "Microsoft.EventGrid/topics/read",
    "Microsoft.EventGrid/topics/publish/action",
    "Microsoft.EventGrid/domains/write",
    "Microsoft.EventGrid/domains/read",
    "Microsoft.EventGrid/domains/publish/action"
  ],
  "NotActions": [
    "Microsoft.EventGrid/topics/eventSubscriptions/write",
    "Microsoft.EventGrid/topics/eventSubscriptions/delete",
    "Microsoft.EventGrid/domains/eventSubscriptions/write",
    "Microsoft.EventGrid/domains/eventSubscriptions/delete"
  ],
  "AssignableScopes": [
    "/subscriptions/your-subscription-id/resourceGroups/your-rg"
  ]
}

You can deploy this custom role using Azure CLI:

az role definition create --role-definition custom-event-publisher-role.json

Assigning Roles via Azure CLI

Role assignments tie a security principal to a role definition at a specific scope. The following examples illustrate common assignment patterns:

# Assign Event Grid Data Sender role to a service principal at the topic scope
az role assignment create \
  --assignee "00000000-0000-0000-0000-000000000000" \
  --role "Event Grid Data Sender" \
  --scope "/subscriptions/sub-id/resourceGroups/rg-name/providers/Microsoft.EventGrid/topics/topic-name"

# Assign Event Grid Contributor to a user at the resource group level
az role assignment create \
  --assignee "user@example.com" \
  --role "Event Grid Contributor" \
  --scope "/subscriptions/sub-id/resourceGroups/rg-name"

# Assign the custom role we created earlier
az role assignment create \
  --assignee "principal-id" \
  --role "Custom Event Publisher - No Subscription Access" \
  --scope "/subscriptions/sub-id/resourceGroups/rg-name/providers/Microsoft.EventGrid/topics/topic-name"

Managed Identity for Event Grid Delivery

When Event Grid delivers events to endpoints such as Azure Functions, Storage Queues, or Service Bus, it can authenticate using a managed identity rather than relying on shared secrets or connection strings embedded in the subscription. This approach eliminates credential rotation headaches and reduces the risk of leaked secrets.

To enable managed identity delivery, you specify the identity type in the event subscription's delivery properties. The following ARM template fragment shows how to configure system-assigned identity delivery to a Storage Queue:

{
  "type": "Microsoft.EventGrid/topics/eventSubscriptions",
  "apiVersion": "2023-12-15-preview",
  "properties": {
    "destination": {
      "endpointType": "StorageQueue",
      "properties": {
        "resourceId": "[resourceId('Microsoft.Storage/storageAccounts/queueServices/queues', parameters('storageAccountName'), 'default', parameters('queueName'))]",
        "deliveryAttributeMappings": []
      }
    },
    "deliveryWithResourceIdentity": {
      "identity": {
        "type": "SystemAssigned"
      },
      "destination": {
        "endpointType": "StorageQueue",
        "properties": {
          "resourceId": "[resourceId('Microsoft.Storage/storageAccounts/queueServices/queues', parameters('storageAccountName'), 'default', parameters('queueName'))]"
        }
      }
    }
  }
}

Before this works, the Event Grid system-assigned identity must be granted the appropriate data plane role (e.g., Storage Queue Data Message Sender) on the target storage account. This is typically done via an additional role assignment step in your deployment pipeline.

Network Security for Event Grid

Private Endpoints and Private Link

Private endpoints establish a direct, private connection from your virtual network to your Event Grid topic or domain using Azure Private Link. Traffic between your VNet and the Event Grid resource traverses the Microsoft backbone network entirely, bypassing the public internet. This eliminates exposure to internet-based threats and helps meet compliance requirements for data residency and network isolation.

When you enable a private endpoint, you can optionally choose to make the Event Grid resource accessible exclusively via private link by setting the publicNetworkAccess flag to disabled. This ensures that no public traffic can reach the resource.

The following Azure CLI commands create a private endpoint for an existing Event Grid topic:

# First, create a private endpoint connection
az network private-endpoint create \
  --name "myEventGridPrivateEndpoint" \
  --resource-group "myResourceGroup" \
  --vnet-name "myVNet" \
  --subnet "mySubnet" \
  --private-connection-resource-id "/subscriptions/sub-id/resourceGroups/myResourceGroup/providers/Microsoft.EventGrid/topics/myTopic" \
  --group-id "topic" \
  --connection-name "myConnection"

# Then, disable public network access on the topic
az eventgrid topic update \
  --name "myTopic" \
  --resource-group "myResourceGroup" \
  --public-network-access disabled

For DNS resolution, Event Grid automatically creates a private DNS zone (privatelink.eventgrid.azure.net) when you create a private endpoint. Ensure your VNet uses this zone for name resolution so that traffic resolves to the private IP address rather than the public endpoint.

IP Firewall Rules (Inbound Network Filtering)

If private endpoints are not feasible—perhaps because your event producers are external partners or SaaS applications—you can restrict public access using IP firewall rules. These rules define allowed source IP addresses or CIDR ranges that can publish events or manage subscriptions. Any traffic originating from an IP not on the allow list is denied.

IP firewall rules are configured at the topic or domain level. The following example demonstrates configuring IP rules via Azure CLI:

az eventgrid topic update \
  --name "myTopic" \
  --resource-group "myResourceGroup" \
  --public-network-access enabled \
  --inbound-ip-rules "[{'action':'allow','ipMask':'203.0.113.0/24'},{'action':'allow','ipMask':'198.51.100.42'}]"

You can also express this in an ARM template:

{
  "type": "Microsoft.EventGrid/topics",
  "apiVersion": "2023-12-15-preview",
  "properties": {
    "publicNetworkAccess": "Enabled",
    "inboundIpRules": [
      {
        "ipMask": "203.0.113.0/24",
        "action": "allow"
      },
      {
        "ipMask": "198.51.100.42",
        "action": "allow"
      }
    ]
  }
}

Be aware that IP firewall rules apply to both the management plane and data plane. If you restrict IPs too aggressively, you might inadvertently block the Azure portal or Azure CLI from managing the resource. Always include the public IP ranges of your management infrastructure in the allow list.

Service Tags for Network Security Groups

When you need to control outbound traffic from your VNet to Event Grid—for example, when an Azure Function inside a VNet publishes events—you can use the EventGrid service tag in Network Security Group (NSG) rules. Service tags abstract the underlying IP ranges and are automatically updated by Azure as the service evolves.

The following NSG rule allows outbound traffic from a subnet to Event Grid:

az network nsg rule create \
  --resource-group "myResourceGroup" \
  --nsg-name "myNSG" \
  --name "AllowOutboundEventGrid" \
  --priority 200 \
  --direction Outbound \
  --destination-service-tag "EventGrid" \
  --destination-port-ranges "443" \
  --protocol "Tcp" \
  --access "Allow"

Service tags are also useful for configuring firewall rules on Azure Firewall or third-party network virtual appliances deployed in your VNet.

Combining IAM and Network Security in Practice

Scenario: Securing a Multi-Tenant Event Grid Domain

Imagine you operate an Event Grid domain that serves multiple internal teams. Each team gets its own topic within the domain, and you want each team to publish only to their assigned topic while preventing cross-topic access. Additionally, you want all management operations restricted to a specific management subnet.

Here is a step-by-step implementation approach:

Create the Event Grid domain and disable public network access.
Create a private endpoint that connects the domain to your management VNet.
For each team, create a topic within the domain and grant the team's service principal the Event Grid Data Sender role scoped to that specific topic.
Grant your operations team the Event Grid Contributor role at the domain scope, but only allow access from the management subnet via Azure AD conditional access policies or by ensuring the operations team's machines are within the VNet.
Configure IP firewall rules to allow only the private endpoint subnet's IP range (or leave public access disabled entirely).

The following script automates portions of this setup:

# Create domain
az eventgrid domain create \
  --name "multi-tenant-domain" \
  --resource-group "shared-rg" \
  --location "eastus" \
  --public-network-access disabled

# Create topics for Team A and Team B
az eventgrid domain topic create \
  --domain-name "multi-tenant-domain" \
  --resource-group "shared-rg" \
  --name "team-a-events"

az eventgrid domain topic create \
  --domain-name "multi-tenant-domain" \
  --resource-group "shared-rg" \
  --name "team-b-events"

# Assign Data Sender role to Team A's service principal on their topic
az role assignment create \
  --assignee "team-a-sp-object-id" \
  --role "Event Grid Data Sender" \
  --scope "/subscriptions/sub-id/resourceGroups/shared-rg/providers/Microsoft.EventGrid/domains/multi-tenant-domain/topics/team-a-events"

# Assign Data Sender role to Team B's service principal on their topic
az role assignment create \
  --assignee "team-b-sp-object-id" \
  --role "Event Grid Data Sender" \
  --scope "/subscriptions/sub-id/resourceGroups/shared-rg/providers/Microsoft.EventGrid/domains/multi-tenant-domain/topics/team-b-events"

With this configuration, Team A cannot publish to Team B's topic because the IAM scope restricts their service principal's permissions. Network isolation ensures that no public internet traffic reaches the domain, reducing the attack surface to only what flows through your private network.

Validating Security Configuration

After implementing your security controls, validate them systematically. Test the following scenarios:

Attempt to publish an event from an unauthorized service principal—the request should fail with a 403 Forbidden error.
Try to access the topic's public endpoint from an IP not on the allow list—the connection should be refused.
Verify that a service principal with only Data Sender role cannot create or delete event subscriptions.
Confirm that DNS resolution inside the VNet resolves to the private endpoint's IP address, not the public endpoint.

You can use tools like curl, az eventgrid topic show, or the Azure portal's "Networking" blade to inspect the current configuration. The following command retrieves the private endpoint connections for a topic:

az eventgrid topic private-endpoint-connection list \
  --resource-group "myResourceGroup" \
  --topic-name "myTopic"

Best Practices for Event Grid Security

Principle of Least Privilege

Assign the minimal role required for each workload identity. For event producers, use Event Grid Data Sender scoped to the exact topic. For event consumers that only need to receive events, avoid granting any Event Grid roles—instead, configure delivery with managed identity and grant the consumer-side permissions on the destination resource (e.g., Storage Queue Data Message Sender). For infrastructure-as-code deployment pipelines, create a dedicated service principal with Event Grid Contributor scoped to the resource group where topics reside, and nothing broader.

Default to Network Isolation

Whenever possible, disable public network access (publicNetworkAccess: disabled) and route all traffic through private endpoints. This aligns with Azure's Zero Trust networking guidance. If public access is required for hybrid scenarios, apply strict IP firewall rules and review them quarterly to remove stale entries.

Use Managed Identities for Delivery

Eliminate shared access signatures and connection strings in event subscriptions by adopting managed identity delivery. This not only improves security posture but also simplifies operational management since Azure handles credential lifecycle automatically.

Audit and Monitor IAM Changes

Enable Azure Activity Log diagnostics and send logs to a centralized workspace. Create alerts for role assignment changes involving Event Grid roles, especially at the subscription scope. The following Azure Monitor query detects recent role assignments:

AzureActivity
| where OperationNameValue == "Microsoft.Authorization/roleAssignments/write"
| where parse_json(Properties).resource contains "Microsoft.EventGrid"
| project TimeGenerated, Caller, Resource, Properties
| order by TimeGenerated desc

Implement Diagnostic Logging on Event Grid Resources

Enable diagnostic settings on your topics and domains to capture delivery failures, publish failures, and subscription operations. Route these logs to Log Analytics or a SIEM system. This telemetry helps you detect anomalies such as repeated authentication failures or unexpected subscription deletions that might indicate a security incident.

Regularly Review Event Subscription Destinations

Audit all active event subscriptions to ensure webhook endpoints point to expected, internal destinations. A rogue subscription pointing to an external URL is a data exfiltration vector. Automate this audit using the Event Grid management API:

# List all subscriptions across all topics in a resource group
az eventgrid topic event-subscription list \
  --resource-group "myResourceGroup" \
  --topic-name "myTopic" \
  --query "[].{Name:name,Destination:destination.endpointUrl}" \
  --output table

Combine with Azure Policy for Governance

Use Azure Policy to enforce security configurations at scale. For example, you can create a policy that denies creation of Event Grid topics with publicNetworkAccess set to Enabled, or a policy that requires private endpoints on all topics. This ensures that new resources automatically comply with your security standards.

{
  "policyRule": {
    "if": {
      "field": "type",
      "equals": "Microsoft.EventGrid/topics"
    },
    "then": {
      "effect": "deny",
      "details": {
        "field": "Microsoft.EventGrid/topics/publicNetworkAccess",
        "value": "Enabled"
      }
    }
  }
}

Rotate Access Keys and Shared Secrets

If you must use shared access signature (SAS) keys for webhook delivery validation or legacy integrations, rotate them regularly. Store keys in Azure Key Vault and reference them dynamically to avoid hardcoding secrets in configuration files. Event Grid's key regeneration capability supports both primary and secondary keys, enabling rotation without downtime.

Conclusion

Securing Azure Event Grid requires a thoughtful combination of IAM policies and network controls. IAM roles and custom policies define the boundaries of what authenticated identities can do—whether publishing events, managing subscriptions, or administering topics. Network security measures such as private endpoints, IP firewall rules, and service tags ensure that traffic flows only through authorized paths, reducing exposure to internet-borne threats.

By applying the principle of least privilege, defaulting to network isolation, adopting managed identities, and continuously auditing configurations, you build a resilient event infrastructure that protects both the integrity of your event data and the availability of your event-driven applications. These practices are not one-time setup tasks but ongoing disciplines that evolve alongside your architecture and threat landscape.