NServiceBus.AmazonSQS
NServiceBus.AmazonSQS copied to clipboard
Particular
Implement queue creation as installers to allow least privilege at runtime
When the SQS transport was transferred to Particular, one aspect of the original design decisions that was baked into the transport was that queue creation was that endpoint queue creation would always be done at endpoint startup. The process does not use INeedToInstallSomething and it cannot be opted out of.
Now the transport includes a CLI tool that enables queue creation, which changes the assumptions underlying mandatory queue creation on startup.
Especially given that there is now a Preview for AWS Lambda, those assumptions should be reevaluated. All users of the transport should be able to provision the necessary queue structures via the CLI tool, and then use a less-privileged IAM policy to run the endpoint without permissions to create queues.
The obvious implementation for this is to use INeedToInstallSomething, although this would present a breaking change as endpoints would no longer create queues by default unless endpointConfiguration.EnableInstallers() was called.
While working on something else (#1643), we had to find a way to prevent endpoints from trying to deploy the infrastructure/topology. We crafted a spike (https://github.com/Particular/NServiceBus.AmazonSQS/pull/1665) that does that. It's not using the installer API because that introduces some issues with the way tests run at the moment, so adhering to the installer API requires more work. #1665 also uses a hack to prevent the AutoSusbscribe feature in Core from always creating subscriptions (and thus topics in SNS). I have a feeling that to properly support installers, the Core ISubscriptionManager interface should be able to tell what's the context in which it's invoked.
Note that we have moved away from using installers to create transport-level infrastructure. We rely on HostSettings.SetupInfrastructure to decide this in the TransportDefinition.Initialize().
