RBAC Vs SAS Policy while consuming the EventHub with Kafka library

Mahendra Sawarkar 40 Reputation points
2023-11-23T13:03:46.4333333+00:00

Hi Team,

We already using the SAS Policy while configuring the integration between the EventHub and our service(client which consumes EventHub using Apache Kafka library). In this case the customer used to create the EventHub and create SAS policy and they used to provide us the Primary Connection String, which we use while communicating with EventHub. Which is just working fine.

Below is connection string we are getting while creating the SAS policy:

Endpoint=sb://uniqname.servicebus.windows.net/;SharedAccessKeyName=policyname;SharedAccessKey=AHDFHAWEFJASDFHAEFRMVMBCb4N6t+ASDKFKAEJFJASDF=;EntityPath=uniqueeventhubname

In this case we are not managing any SAS Token at our side. Few questions:

  1. Is SharedAccessKey a SAS Token ? Or is it responsible for creating a SAS token. If so where the SAS token is created i.e. at client side or server side
  2. In this full flow, do you think the SAS token is created, may be at the client side or the Azure side?
  3. Is this flow not recommended?
  4. If we start using RBAC (i.e. an account is created and necessary RBAC rights are assigned), do you think the connection string wont have parameters which are currently there in above example, do you have any example where the connection string is used with RBAC?
  5. what should be the ideal way of communicating with EventHub

Thanks in advance !

Azure Event Hubs
Azure Event Hubs
An Azure real-time data ingestion service.
637 questions
{count} votes

Accepted answer
  1. PRADEEPCHEEKATLA-MSFT 89,386 Reputation points Microsoft Employee
    2023-11-27T07:04:30.15+00:00

    @Mahendra Sawarkar - Thanks for the question and using MS Q&A platform.

    Based on the information you provided, I can answer your questions as follows:

    The SharedAccessKey is not a SAS token, but it is used to create a SAS token. The SAS token is generated by the Azure Event Hubs service when a client authenticates with the service using the SharedAccessKey. The SAS token is then used by the client to access the Event Hub.

    In this flow, the SAS token is created by the Azure Event Hubs service when the client authenticates with the service using the SharedAccessKey. The SAS token is then sent to the client, which uses it to access the Event Hub.

    This flow is a recommended way of authenticating with Azure Event Hubs using SAS policy.

    RBAC is an alternative way of authenticating with Azure Event Hubs. When using RBAC, you would create an Azure AD application and assign it the necessary permissions to access the Event Hub. The connection string would then include the client ID and client secret of the Azure AD application, instead of the SharedAccessKeyName and SharedAccessKey. Here is an example of a connection string using RBAC:

    Endpoint=sb://uniqname.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=AHDFHAWEFJASDFHAEFRMVMBCb4N6t+ASDKFKAEJFJASDF=;EntityPath=uniqueeventhubname;SharedAccessSignature=SharedAccessSignature sr=uniqname.servicebus.windows.net&sig=xxxxxx&se=xxxxxx&skn=RootManageSharedAccessKey

    1. The ideal way of communicating with Azure Event Hubs depends on your specific use case and requirements. Both SAS policy and RBAC are valid ways of authenticating with Azure Event Hubs, and you should choose the one that best fits your needs.

    For more details, refer to Acessing Event Hubs with Confluent Kafka Library.

    I hope this helps! Let me know if you have any more questions.

    1 person found this answer helpful.

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.