Azure Event Hubs is streaming platform and event ingestion service that can receive and process millions of events per second. In this blog, we are going to cover one of the security aspects related to Azure Event Hubs.

Shared Access Signature (SAS) is a commonly used authentication mechanism for Azure Event Hubs which can be used to enforce granular control over the type of access you want to grant - it works by configuring rules on Event Hubs resources (namespace or topic). However, it is recommended that you use Azure AD credentials (over SAS) whenever possible since it provides similar capabilities without the need to manage SAStokens or worry about revoking a compromised SAS.

To read more about this topic, check out “Authenticate access to Event Hubs resources using shared access signatures (SAS)”.

There a couple of ways in which you can do this:

• using Managed Identity or
• by using service principal in your client applications

We will explore the second option i.e. how to use Azure Active Directory based authentication in your Azure Event Hubs client applications. With a practical example, you will learn:

• Overview of Azure Event Hubs roles
• How to use Azure CLI to configure Service Principal and RBAC policies for Event Hubs
• Event Hubs supports multiple programming languages with specific SDKs and we’ll see how to use RBAC with Java and Go clients

_The code is available in this GitHub repo — _https://github.com/abhirockzz/azure-eventhubs-rbac-example

---

Overview

This section provides a high level overview for you to get an understand the key terminologies: Roles, Security principals and Role based access control (RBAC).

Roles: Azure Event Hubs defines specific roles each of which allows you to take specific action on its resources — Data Owner, Data Sender, Data Receiver. They are quite self explanatory - Sender and Receiver roles only allow send and receive respectively, while the Owner role is like an admin privilege which allows you to complete access.

_For details on these roles, please refer to their documentation links — Azure Event Hubs Data Owner, Azure Event Hubs Data Sender, _Azure Event Hubs Data Receiver

RBAC, Service Principals: Service Principals are entities to who, these roles are granted — this is “Role Based Access Control” since the role you grant to the Service Principal defines _which actions_they can perform — in this case, the actions are: send, receive or everything!

… the scenario

Here is the example we will use to learn this. There are two Event Hubs client apps — a Java producer and a Go consumer. We will configure fine grained rules (i.e. enforce RBAC) such that:

• Java app can only send messages to an Event Hubs topic, and,
• Go app can only receive messages from an Event Hubs topic

Here are relevant code snippets:

In the Java producer client, the [DefaultAzureCredentialBuilder](https://docs.microsoft.com/java/api/com.azure.identity.defaultazurecredentialbuilder.defaultazurecredentialbuilder?view=azure-java-stable&WT.mc_id=medium-blog-abhishgu) is used.

String eventhubsNamespace = System.getenv("EVENTHUBS_NAMESPACE");
String eventhubName = System.getenv("EVENTHUB_NAME");

EventHubProducerClient producer = new EventHubClientBuilder().credential(eventhubsNamespace, eventhubName, new DefaultAzureCredentialBuilder().build()).buildProducerClient();

By convention (default), the Java SDK tries to read pre-defined environment variables for Service Principal info and authenticate based on that. If this does not work, it falls back to try the SASauth mechanism and looks for another set of environment variables

Similarly, in the Go consumer client, the Event Hubs client creation process is greatly simplified as well

ehNamespace := os.Getenv("EVENTHUBS_NAMESPACE")
ehName := os.Getenv("EVENTHUB_NAME")

hub, err := eventhub.NewHubWithNamespaceNameAndEnvironment(ehNamespace, ehName)

The developer experience is uniform across SDKs and [_NewHubWithNamespaceNameAndEnvironment_](https://godoc.org/github.com/Azure/azure-event-hubs-go#NewHubWithNamespaceNameAndEnvironment) does the same thing as the _DefaultAzureCredentialBuilder_ in terms of following a fixed convention attempting to authenticate using Azure Active Directory (AAD) backed Service Principal first, followed by SAS mechanism

With that said, you do need a few things to get through this tutorial:

#java #cloud #paas #kafka #confluence