It seemed like a strange request, when a colleague asked me to look into upgrading our Function Apps to use .NET 10, ‘isolated worker’. Since when was it possible to change their runtime version ourselves? And what on God’s Green Earth was an ‘isolated worker’? It was time to investigate.
There are a couple of important things to remember about Function Apps, as a starting point. Firstly, my colleagues and I had developed Function Apps exclusively as custom Logic App components, to handle more cumbersome data transforms.
After resolving the previous issue with the Content-Type defect in the Azure Logic App’s storage connector, I ran into a second problem: The Web pages being generated were populated with the correct content type, but the incorrect content. I quickly discovered that was partly caused by a race condition and with how memory is managed by Azure.
By default, a Logic App will run up to twenty instances of a ‘For Each’ loop in parallel, but this is multi-threading instead of true parallel processing.
One of our Logic Apps, which we developed as a static site generator, began writing the Web pages to the storage account as octet stream files, and I narrowed down the problem to a defect in the storage account connector.
I believe (but I’m not 100% certain yet) Microsoft’s developers hadn’t implemented the ‘"headers": {"Content-Type": "text/html"}’ code for the storage account connectors, and the file type, therefore, always defaults to octet stream.
After ensuring I didn’t misunderstand what I read, when I learned about Microsoft’s Co-Pilot Recall thing, I couldn’t help but ask myself the obvious question: ‘Just how the hell could anyone possibly believe it’s a smart idea?’. But I sort of know the answer: It’s because the obsession among corporations with pleasing investors by forcing ‘AI’ onto everything and everyone, whether we like it or not, and regardless of the ramifications.
The security configuration of Azure services is a fairly broad subject area, and this is more of an introduction to how it works for a Resource Group, in the context of a Logic App that needs to interact with multiple resources. If a DevOps team, instead of the developers, is managing the security, a considerable amount of time will be spent planning and designing services beforehand, and later trying to figure out which security configurations are preventing the services working.
One of the most important lessons I’d learned from working with Azure, over the last year or so, is that careful thought should be given to whether it’s better to implement a service as a ’low code’ solution, or as conventionally-developed software. The former isn’t always the fastest, cheapest or more efficient way to get something deployed.
I’m currently of the opinion that Azure’s Logic App system is quite good for integrations and basic scheduled tasks - and it has indeed made those kind of things easier to manage - and there aren’t any convoluted deployment pipelines to bother with.
A security incident was flagged this week. As it turned out, nothing was compromised, but it served as a valuable warning of how vulnerable an organisation using Microsoft Azure (or perhaps AWS) could be to a subdomain takeover that could be used in a more sophisticated attack.
The incident had something to do with a subdomain that was initially mapped to a staging Web site hosted on Azure.
The Web site was removed some time ago, but the mapping between the subdomain and the site’s public ‘azurewebsites.
Azure Key Vault is designed to store (and protect) secrets such as API keys, passwords, cryptographic keys, connection strings, etc. It can store the following categories of data:
Keys Certificates Secrets The Secrets storage can store arbitrary plaintext values, so Key Vault could potentially be used as a means of centrally managing a collection of usernames and passwords that could be copied and pasted straight from the Azure Portal. Is this a safe method of password management, though?
