Michael S. Collier

I was recently asked how to change Azure Functions’ system keys, such as the ones automatically created by the Event Grid or Durable Functions extensions.

It’s possible to change these keys via the Azure portal. There is a button in the portal to generate a new key.

What if you want to change the keys programmatically? I couldn’t find official documentation which stated how to do so. After a bit of splunking through GitHub issues (here, here) and reading Mark Heath’s excellent blog post on Azure Function keys, I think I found an approach that, so far, seems to work.

I recently ran into a situation using the Azure Functions default host key where I did not understand the behavior I was observing. Thanks to the help of some fantastic colleagues, we figured out what was going on. I understand what is happening now. I want to share here in hopes that my experience will help others that may run into a similar challenge.

Scenario

I needed to create an Azure Function app via an ARM template. The ARM template should create the Function app resource and set the necessary application settings. One of those app settings should be a Key vault reference to a secret which contains the default host key for the function app. My function’s application code would retrieve that and invoke another function in the app.

A few months ago one of the greatest scandals to hit Azure Functions erupted . . . ASCIIartgate!

#teamAsciiArt became a trending topic on Twitter. Maybe.

The Big Deal

In an effort to reduce the verbosity of logging output by func start in the Azure Functions Core Tools, the decision was made to remove the famed ASCII art. To be fair, running func start did output quite a bit of logs. The ASCII art version of the Azure Functions logo was just one of those logs. It just happened to be the most famous of those logs. The logo was the thing of highly coveted t-shirts!

Earlier this year I wrote a post showing how to set up private site access for Azure Functions. To briefly recap, private site access refers to setting up a virtual network service endpoint to restrict HTTP-based access to the function to be only traffic from the designated virtual network (i.e. inbound HTTP requests). Attempts to access the public endpoint (e.g., https://contoso.azurewebsites.net) result in an HTTP 403 Forbidden message. Service endpoints are great, but they are not without some drawbacks (use a public IP address, doesn’t work with connections from on-premises resources (i.e. ExpressRoute), limited RBAC features, etc.)

I’ve moved my blog again! Well, sort of. Not a new engine this time. I’ve moved to a new host!

I’ve moved my blog to Azure Static Web Apps. The docs for Static Web Apps (SWA) include a good tutorial on using Hugo with SWA. I followed that tutorial.

Once I got the content set up and GitHub action publishing working, it was time to set up the custom domain name. Again, the Microsoft docs help there too. I was able to follow the instructions for setting up a custom domain with SWA, and then Burke Holland’s post on using CloudFlare for setting up a root domain.