When initializing a service with NServiceBus (say, .net core and Startup.cs), you can specify a logical endpoint, instantiate an endpoint instance, and provide the connection string, along with the destination queue name and the error queue. That assumes that access key you’re providing is at the namespace level, and that access key can access both resources.
Our automation for creating our service bus queues and topics generates a shared access key per resource type, and the keys for the dev environments are distributed to the development teams. This is the process going forward, and we wanted to know how to can configure NSB to send destination messages using one key, and error messages using another key. Is this possible currently?
Could you share what kind of transport are you using? I guess it is ASB, but can you share is it thelegacy ASB or teh new ASB transport? And what versions are you using?
We are currently using Azure Storage Queues in one of our legacy projects, and the new Azure Service Bus transport for one of our newer projects. The supported functionality isn’t available in either transport.
Both projects are either using the latest .net core versions, or if they aren’t, can be updated to do so immediately and without issue, or to any specific version you want us to pin it to.
But for the purposes of the technical discussion, let’s assume we’re on the latest and greatest, because I’ll be creating a new reference project with the example usage that we want in place.
The scenario is to be able to specify a logical endpoint with a shared access key for the destination queue, as well as a different shared access key for the error queue (preferably regardless of transport), since the backing infrastructure is provisioned separately via Terraform, and given access rules per resource, rather than through NServiceBus installers or configuration.
Azure Storage Queues transport does not support a separate storage account to be used for the Error or Audit queues. While in the past it was possible to configure a different account for Error queue, that option was deprecated.
Correct me if I’m wrong, but it sounds more as a provisioning issue. Would it be possible to provision your resources (input and error queue) to the same storage account provisioned to the same storage account using Terraform? Also, looking at what you’ve specified
it would mean each logical endpoint would have its own storage account. While you can do cross-account routing, this does not apply to Error and Audit queues.
Hello Sean, it’s been a while! Hope you’re doing well, sir.
To the topic at hand, storage accounts as a transport are just one (legacy) use case, and I’m looking for specifically some sort of support or options in the nservicebus configuration to provide multiple credentials or connections. From my perspective, it shouldn’t matter what the transport layer is, so long as the destination point can have one set of credentials (shared access key for it) and the error point can have another (different shared access key for it). Based on what you said, it sounds like that option was available in the Storage Queue transport. I’m not sure why it wouldn’t be available (and I suppose subsequently deprecated) across all transports, but that’s neither here nor there.
We can’t help the provisioning scheme, since we can use Terraform to create things exactly the way we want them, and the way we are currently generating access keys is the direction that was provided by our security group. So, we don’t have much wiggle room to alter how we provision (nor does security want us to).
The point I’m trying to clarify is, in nservicebus, regardless of whether you provision a storage account or service bus queue in one subscription or namespace or not, can you provide different connection strings or at least access keys for the various destination centers, regardless of it’s for the actual destination queue, or the error queue? If not, then the software simply doesn’t support our configuration going forward, and we just need to find an alternative. That’s why I’m asking. We’ve been using it to great success so far, but only because it can do the things we need it to be able to do.
If it can’t support separate shared access keys for the multitude of physical endpoints, or within an “endpoint” it can’t support a separate credential set for the destination physical component versus the error physical component, then it can’t support any of the mr.cooper environments going forward for all of our apps / pipelines.
We are transitioning to the new Azure Service Bus transport. Does it support being supplied with shared access keys per destination/error point?
The Azure Service Bus transport is following the same rules as the Azure Storage Queue transport.
You cannot have a separate connection string for the endpoint. I’m not even sure how you’re planning to achieve that given that you can only have a limited number of Shared Access Policies you can have to use with connection strings (12 for a namespace or entity). If you’re planning to use per entity, that means your endpoint would need to have 3 policies - one for the endpoint’s input queue, one for the error queue, and one for the shared topic to publish to.
What you can do with the ASB transport is to use a custom token provider. Perhaps that’s something that will help you.