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.
So, we've set up these code analyzers, Roslyn, FXcop, and SonarCloud, and they are providing us with a wealth of information. But what we really need is this data to be used in preventing poor quality builds from being deployed. One way we can do this is set up branch policies so that pull requests to the main branch have to pass through certain quality gates for the code to be merged. I've created another branch called DBRework and I've made a bunch of changes to my code which I'm going to commit to the rework branch and then create a pull request to the master branch, which will have a branch policy set. The branch policy will use information from SonarCloud analysis to decide if the merge should be allowed.
If I go to branches and then to the context menu of the master branch, I can select branch policies. In a real-world situation, we would check require a minimum number of reviewers and we wouldn't let me review my own code, but obviously for the sake of demonstration, I will just leave those checkboxes unchecked. Under build validation, I'm going to add a build policy. I'll select the pipeline and give it a name and hit the save button. I've left the trigger on automatic so that the source branch will be built on changes committed, thereby triggering the SonarCloud quality gate.
To integrate SonarCloud into my branch policy, I'll need to get a token. So, I go into my user account settings, and under security, select personal access tokens. I'll give it the name SonarGateCheck. And I need to give it read and write access to my source code. So, this has been created, but I need to grab the access token that I'll use in SonarCloud to give access to my pipeline. Next, I'll go into my SonarCloud project and under administration menu, choose general settings and then pull requests. Under the provider, choose Azure DevOps, services and the personal access token. Paste that token that we've grabbed from the Azure DevOps account.
Right, so back in the DevOps project, I'll create a pull request to pull the commits from my DB rework branch to master, and it sets off a build. I know what you're thinking, so what? Nothing's happened yet. Well, we haven't finished. Let's go back to branch policies, and this time I will go down to require approval from additional services and click the add status policy button. Having set up the connection with the personal access token in SonarCloud, the quality gate is now available to choose from the status to check drop-down list, which was not the case before. I'll select my SonarCloud quality gate and save.
Back in Visual Studio, I'll make a few more code changes and commit them, and then sync those changes back to my repo. Again, that triggers a build, but this time data from SonarCloud is going to come back, and we can see Sonar comments are visible inside the pull request overview. More importantly, we can see here on the upper right, the quality gate check failed. I've been back into the code and fixed the bugs and re-run the build pipeline, and this time we can see it has passed the quality gate.
So, a little workaround to suppress those warning messages is to insert pragma warning disable and then the code of the rule you want to have suppressed. There is a full listing of all the analyzer rules on the docs.microsoft.com site with detailed explanations and examples of how the rule is violated and how to fix those violations.
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.