Coding Azure 21: Managing Configuration Information with App Configuration

Let’s create and configure an App Configuration service to provide shared storage of information that various components of a loosely coupled application can reference.

In a previous post, Coding Azure 17, I described the power of creating asynchronous applications and went on, as an example, to implement one using Azure Storage Queues with a backend processor that read messages created by a frontend application.

Asynchronous technologies like Storage Queues position you to create distributed microservice-based applications as a collection of independent, loosely coupled components.

The Problem and the Solution

Except, of course, these components can’t be too independent: some sharing is required. For example, the frontend must write to the same queue that the backend is reading from. At the very least, that queue’s name must be shared between the frontend and the backend. Sharing a JSON Schema of the format of the shared message would also be a good idea to verify that the frontend component writes its messages in a format that the backend component expects.

In a standalone application, that queue name is the kind of information that you would normally keep in a configuration file where you would manage the name change as the application moves from development to test to production. However, in a distributed application, managing that name in separate configuration files for each component is just asking for trouble: Sooner or later the components’ queue names are going to get out of sync and the frontend will be writing to one queue while the backend is listening for messages on another queue.

This is where Azure’s App Configuration comes in: An App Configuration service provides a central point where all the components of a loosely coupled application can save shared information (App Configuration can also be used to implement Feature Flags but I won’t be discussing that option).

In this post I’m going to show how to create and configure an App Configuration service. In my next post, I’ll cover storing settings in it (there are a surprising number of options). In the post after, I’ll cover the code required in an application to retrieve those settings.

And, while I’m positioning App Configuration as infrastructure for distributed applications, it has enough features that you can’t get either with a JSON file or an App Service’s Environment Variables that it’s worth considering as your primary source for configuration information.

Creating an App Configuration Service

To create an App Configuration service, surf to the Azure Portal and search for App Configuration. When App Configuration appears in the dropdown search box’s dropdown list, click on that entry to be taken to your App Configuration overview page (do not go to Azure App Configuration, which is a completely different beast).

Once you’re on the App Configuration Overview page, click the +Create button at the left end of the menu across the top of the page—that will start the wizard that will let you create your App Configuration service.

Defining Your Service

As usual, on the first page of the wizard, you’ll need to assign your service to a resource group, place it in a region and give it a name. A configuration service does not have to be in the same region as the application components that access it (though you’ll get better performance if the service is in the same region as its clients). You’ll also need to pick a pricing plan.

Finally, on this page, you’ll need to choose whether you want to enable geo-replication to have your service’s settings copied to a different region. Enabling geo-replication helps you reduce failure. In addition, because you can pick the region (or regions) where your read-only copy/replica will be stored, geo-replication lets you create copies local to components in other regions, giving you a better performing application (though you’ll want to check out pricing.

Controlling Security Access

After you’ve completed the first page of the wizard, you can click the Next button at the bottom of the page to move to the Access Settings page in the wizard. On this page you can enable Access Keys which allows applications that present the right key to read settings in your service.

In my opinion, you’re always better off using Entra ID’s Managed Identities to control who (or what) is allowed to access any Azure resource. Turning on access keys doesn’t disable Entra ID but it does allow Entra ID to be bypassed by an application that has the right key. Since access keys are not time limited, any application with an access key will be able to access your service until you delete or change the keys. While you may be confident that you can control who has those keys, it’s worth remembering Benjamin Franklin’s wise words: “Three may keep a secret, if two of them are dead.”

With access keys disabled, you’ll have to pick the pass-through security option on this page.

Soft Delete

Clicking the Next button at the bottom of the Access Settings page will take you to the Advanced page. On this page you can decide how long a configuration setting (or the whole service) will be kept after being deleted.

It costs nothing to turn this option on, but you will be charged for the storage used by deleted keys that are waiting to be restored or, eventually, purged. Typically, the space taken by a setting or even a complete service is relatively small—you’ll just need to decide how much peace of mind you need.

Controlling Network Access

The next page in the wizard allows you to control Network access to your service. Your three options are:

• Automatic: With this setting, any application can access your service from anywhere up until you create a private endpoint to your service from a virtual network (which includes both Virtual Machines on virtual networks and App Services not on a Free or Shared plan). Once you create a private endpoint then your service will only be accessible through the private endpoints you create.
• Disabled: This choice limits you to using only private endpoints to access your service.
• Enabled: Anyone can access your service from anywhere, including over a private endpoint.

The first two choices are the more secure options, assuming you create at least one private endpoint for your service (there are charges associated with using a private endpoint). You can further enhance the security that a private endpoint provides by adding a firewall to it.

Picking Automatic would let you defer creating a private endpoint during development. However, picking Disabled disallows your service from becoming available to the world if its last private endpoint is deleted (the maximum number of private end points you can create on a single App Configuration service is controlled by your service’s pricing plan).

Separate from your application’s components when accessing the service at run time, you can also limit access to a private endpoint when managing your resource (e.g., adding/removing settings) by checking off the Azure Resource Manager Private Network Access checkbox. Checking this option, for example, means that your service could only be managed through Bastion.

Encryption

Clicking the Next button at the bottom of the page brings you to the wizard’s Encryption tab. All your settings are encrypted by default using encryption keys provided by Microsoft. This tab lets you choose to use your own keys to encrypt your settings.

Saving Changes

The wizard finishes with the usual Tags and Review + create pages. On the last page, click the Create button to start creating your service.

With your App Configuration service created, you might think that you’re almost ready to add settings to it.

Getting Access

Your next step in creating your service is to give someone a role that lets them add settings (by default, no one is granted any of those roles):

1. In the menu down the left-hand side of your service, click on the Access Control (IAM) node to open a page on the right.
2. In the page on the right, click on the Add role assignment button to open the Role tab of the Add role assignment wizard.
3. In the search box on this page, enter App Configuration Data Owner.
4. Click on the role to select it.
5. Click on the Next button at the bottom of the page to open the wizard’s Members tab.
6. In this new page, click the + Select members link to open the Select member panel on the right.
7. In the textbox in the Select members panel, enter the identity of the person who will be adding settings to the service (probably you).
8. Click on the name of the person you want to select it.
9. Click the Select button at the bottom of the page. The panel will close and return you to the Add Role Assignment page.
10. Back in the Add Role Assignment page, click the Next button to move to the wizard’s Review + assign tab.
11. Click on the Review + assign button at the bottom of the page to assign the role to the user you selected and return to the Access control (IAM) page.

You may have to take a break here because it can take up to 15 minutes for your new role to propagate through Azure.

You’re now ready to start adding settings, which is a meaty enough topic that I’ll cover that in my next post.