As a marketer in the SaaS industry, you’re constantly under pressure to not just have a predictable funnel and deliver pipeline but to also showcase marketing attribution , all while staying under a…
Azure functions are getting improved, and updated more frequently now. Recently it has been upgraded to support identity based triggers and bindings.
The Azure function will be provided only the required roles to access the resource so that its more secure. Although, still its always best to access sensitive data through a key vault if you cannot do so using identity based connections.
For an example, if you are implementing a service bus triggered Azure function without identity based connections, the connection to the topic had to be saved in a key vault and then provide access to the Azure function app to access the key vault through managed identity. But with the new changes now, you can use RBAC to provide access to the function app directly to access the service bus topic securely.
In this demo we’ll be creating a service bus triggered Azure function with identity support.
Once we deploy the Azure functions, and if we didn’t use identity based connections the configuration section in the Azure function app will look like below.
Also if you can refer the other configurations marked in red boxes they represent the read/write access to the service bus to be used in the Azure functions. Although they are securely accessed through a key vault, it would be better if the function app itself have the required access to the service bus so that a key vault will be unnecessary in this case, and it will be more secure.
“More secure” also means that the actual value in the key vault can be anything, and it might not be the correct access connection string or it could be tampered. But with managed identity once the access is provided with the correct roles you don’t need to worry anymore.
When we design and build a solution we would like to use good design principles. Especially if you are following the
S.O.L.I.D principles you will be decoupling responsibilities across multiple contexts. One context you will be considering here is decoupling
infrastructure related implementations such as publishing to a service bus, event hub or to a database. Simply you should not be implementing it in the same
presentation layer . That is, in Azure functions perspective where you define your Azure functions.
But with Azure functions
output binding support, you will be tempted to bind the infrastructure component and then pass it down the layers where the actual operation happens.
This is how you would create a function which uses output binding and passes it through the lower layers.
messages is an output binding and it’s passed down to the lower layers (
IReceiveOrderRequestHandler in the application/domain layer) to perform actions of it. This creates an unnecessary coupling in the application/domain layer where it directly coupled with a library and, the only reason to do this is to use the output binding support.
The Azure SDKs are frequently updating with improved features and support. In here we’ll be using the required SDK support in the
infrastructure layer and, of course we’ll be using the identity support which are already available in those SDKs.
The solution is designed based on the
clean architecture patterns and the solution is organized as below.
Let’s emphasize on the
infrastructure layer and as illustrated above the
ReceiverOrderFunction will need to publish a message to the service bus topic. The publication of this message is implemented in the infrastructure layer.
ServiceBusClient is from the nuget package
Microsoft.Azure.WebJobs.Extensions.ServiceBus and you can register the client as a dependency in the
When registering the service bus client we are explicitly stating to avoid the other authentication mechanisms. This is important so that the code will use only Azure CLI, and managed identity.
The service bus triggered function will be using identity based connectivity to get triggered. As you could see the code is not different to an implementation without identity based. It will be at the deployment stage that these access rights to be provided. This will be explained towards the end of this article.
Since the application needs access to both read and write from the service bus topic/subscription both the application and the user of the IDE needs to have
Azure Service Bus Data Receiver and
Azure Service Bus Data Sender roles assigned to them.
I was able to successfully “publish” messages to the topic using managed identity from my local environment but unfortunately I wasn’t able to “trigger” the service bus triggered Azure function in my local environment. So I had to use the service bus connection string “only” in my local environment.
local.settings.json should be set as below,
In here we are using a
YAML based multi-stage pipeline to build and deploy the solution to Azure. The resources to be deployed are declared using
Azure Bicep .
The CI/CD pipeline, and how it’s organized is explained below,
This contains all the stages and the environments which the pipeline will build and deploy the solution.
This is the build pipeline. All the steps required to build and test the solution along with the artifacts to be used in the deployment pipeline.
In this folder we will include all the variables to be used in the CI/CD pipeline. The variable files are named after the environment they will be used. There’s a file called
common.yaml where you can define all the variables which can be shared among all the environments. The benefit of having such a file is that, then in the environment variable files you only need to define the variables which are specific to that environment or if there are values which you would like to be overridden from the
common.yaml variable file,
dev.yaml variable file with it’s own variable declarations and the overridden value from the
common.yaml variable file,
Although we deploy only to the development environment (dev) you can add any environments as you would like.
All the resources which will be used to deploy this solution has been organized into their own folder and inside it contains the Azure Bicep template which will be used to deploy the resource.
For an example the
ApplicationInsights folder contains the bicep template which will be used to provision an application insights instance.
This is the master bicep template which will orchestrate all the other bicep templates which will be used to deploy the Azure resources. As you could see we use
bicep modules feature to reference the resource templates and define dependencies. Azure Bicep has made this really convenient with the modules support.
You can do the same using
ARM templates as well, but then you’ll need to use “linked ARM templates”, and to do that you’ll need to upload all the ARM templates to a storage location and access them through a SAS token in the deployment pipeline. This can be completely avoided by using bicep modules.
Once all the resources are provisioned now the deployment pipeline needs to provide RBAC to the resources to collaborate.
When we provision the function app and its staging slot the deployment will output the resource ids of them as shown below.
So in the script above it uses this deployment as a reference and get the resource ids of both the function app and its staging slot, and then assign the required roles.
The configuration settings of the deployed Azure function app will be like below,
As a next step on my academic journey, I was asked to compose a statement of my teaching philosophy. Here’s how I responded: I’ve mellowed as a teacher over the years, and I remember exactly the…
Octoin is international, multi-featured cryptocurrency tracking platform. The platform caters to the crypto community in general. With a number of features and investment tools for earning, the main…
We are now well over a decade into the social media era, during which the cultural zeitgeist has become increasingly shaped by public discourses that unfold across social platforms, resulting in…