Securing with Secrets
Compliant Development Process
The course is part of this learning path
Configuration is an important aspect of determining an application’s behavior. Settings files often include sensitive information like passwords and API keys. In this course, we will look at how to protect that sensitive information while the app is being developed and when it is in production.
Azure’s App Configuration Service allows you to manage access to settings data and we will see how to use it within a .Net application. We will look at using Azure Key Vault in conjunction with App Configuration Service, and how to access Azure Key Vault directly from your application and from apps running in a container within a Kubernetes cluster.
Next, we look at the idea of shifting left security testing within your development process, and how we can automate security testing as part of implementing a compliant development process. Much of this will involve using extensions from the Azure marketplace within your DevOps build pipeline.
This course contains numerous demonstrations from the Azure platform so that you can get a first-hand look at the topics we will be covering. If you have any feedback relating to this course, please contact us at firstname.lastname@example.org.
- Learn about app configuration
- Run and deploy apps with the Azure App Configuration service
- Use Azure Key Vault to store secrets and certificates
- Access Key Vault directly from your apps, including those running within a Kubernetes cluster
- Create a compliant development process by integrating code analyzers, branch policies, quality gates, open-source library scanning, and automated penetration into a build pipeline
- Intermediate-level developers, DevOps engineers, and product managers
- Anyone interested in learning how to implement secure app configurations and development pipelines
To get the most out of this course, you should have some pre-existing knowledge of software development and of using Microsoft Azure.
Up until now, I've been treating app configuration as you would an appsettings.json file for a single application, but this isn't how App Configuration is designed to be used. You can have multiple applications using the one App Configuration by implementing something like namespaces. What I'm going to do is first is show you creating an App Configuration using the command line interface and then creating a key with namespaces. Let's open a CLI command prompt. The command for creating an app configuration is
az appconfig create -n for new and then the name of your app configuration followed by
-g for the resource group, then
-l for the location and then we have to specify the SKU which is either standard or free. Now that's done I'm going to create a key.
So once again
az appconfig, now
kv for key value, set -n app configuration. I'm guessing that's for set a new kv in this configuration, not entirely intuitive. Now the name of the key with the namespaces separated by semicolons. So app name then settings then key, with the value of 0. If we go back to the portal and into the newly created App Configuration we can see the key. Instead of manually entering the rest of the settings I'm going to import them with the import/export feature.
Before I do this let's have a look at the settings file. This is obviously not the same as the appSetting.json that gets produced when you create an app with the Visual Studio Wizard, but it's in a format that will conform to the namespaces I want in the app configuration. Importing is straightforward, It's a JSON configuration file for a .Net app. Before the data is saved to the configuration you have the opportunity to change the namespace separator and prefix a namespace if you want.
Because I'm using managed identity to connect to the App Configuration I've given the app service that will be reading these app settings the App Configuration Data Reader role on this resource. Right, back to the app to see what changes we need to make. First off we need managed identity credentials and now I'm connecting with just using the endpoint url. Using managed identity credentials means you won't be able to run the app locally, it needs to be run from the app service to work. The refresh key is the new fully qualified namespace and I'm using the demoApp scope just to retrieve settings for this app.
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.