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.
If we go to the Azure portal, I've already got a container registry set up with a misspelled repository in it. What I'll do now is create an AKS Kubernetes two node cluster using Azure's CLI with the az aks create command. The last argument is attach acr, so AKS knows where to pull the container images from. While we're here, I wanna point out a bit of a glitch or problem that I had, and after some research found that I wasn't the only one.
I initially tried to attach an existing cluster to my container registry with the az aks update command and kept getting an error of could not create a role assignment for ACR. Are you the Owner on this subscription? I'm not the owner, and I'm guessing most Azure users aren't a subscription owner either. But I could attach to the container registry if I did it while creating the cluster. Strange, but there you go.
Okay, having created the cluster, let's get the service principal's client ID. Going back to the portal and looking at active directory app registrations, we can see it there. Next, I need to get credentials so I can start using the kube control commands. Because I've been through this process before, when I couldn't get AKS to attach to an existing cluster to my repository, I'm being asked if I wanna overwrite previous configurations which I will say yes to.
Now I'm going to apply the deployment RBAC yaml file of Azure active directory pod identity project to make my Kubernetes cluster aware of Azure managed identities. Having done that, I'm now going to create a managed identity which I will use to access the key vault. With the new managed identity created, I'm gonna give it access to read secrets from my key vault. So go into access policies through add access policy and from the template, I'll select secret management. Then in terms of permissions, I'll just set get and list.
Now search for my newly created identity and add it, and crucially, don't forget to save. So back at the CLI, I'm going to apply an Azure identity yaml file to my AKS set up. This file has the client ID of my managed identity as well as the resource ID. The meta data name doesn't necessarily have to be the same as the name of the managed identity. We're going to use that reference later in a binding file.
Okay I'll just apply the active directory pod identity yaml file. The next step is to bind that identity to our Kubernetes cluster with an Azure identity binding file. So I told the binding file about the managed identity yaml file and now I apply that binding file to my cluster. Here's the service principal ID that I created. I'm now going to do a role assignment of managed identity operator to that ID. Then apply my config map yaml file. And here I'm telling my deployment file all about the identity binding.
Finally I will apply my deployment file. Next I'll get my external IP address and will bring up the app in the browser. So if I go back into my configuration file, my config map file, and change the background color to red. And I'll go back to the key vault and replace the secret with another value. Just have a look at that changed value.
There we go, this is a changed secret. Back to the Azure CLI and I will apply the new config map file. I'll restart my container and will go back and refresh, and there we go. We got the red background and the updated secret value.
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.