Securing with Secrets
Compliant Development Process
The course is part of these learning paths
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 email@example.com.
- 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.
Now, I wanna talk about how you would secure a build pipeline delivering containers to a Kubernetes cluster. So, going back to first principles, there are three main elements we would start with. We have a code repository with application code in it. We have a container registry, such as Azure Container Registry, and we have our Kubernetes cluster.
So, the question is how do we securely get our code into our container, and our container into our Kubernetes cluster while maintaining the security of the build pipeline? You need to control access and the ability to push images into your registry, and at the same time, you need to control or ensure that only images from your registry are deployed to a cluster.
Kubernetes has an element or piece of code called an admissions controller. The admissions controller validates all incoming requests to the cluster. We can configure the admissions controller to say that when it pulls an image, we wanna make sure that the image comes only from our container registry. Azure policy integrates with Kubernetes admission controller to provide seamless and role based administration of Kubernetes clusters. So, we secure the deployment of our images from our container registry. But what about pushing the images into our container registry? How do we control that?
We have a build pipeline that pulls source code from the repository and creates container images. Who has the permission to push images to the container registry? Because whoever has that permission also has permission to push any image to the Kubernetes cluster. We want to restrict the ability to push images to the registry through our build pipeline, and we do that with the key. We then know that all images that are pushed to the registry come from a verified source, that is our build pipeline. By restricting access to the container registry to the build pipeline, we are ensuring the integrity of the entire DevOps process.
So, everything that gets released has had to go through code reviews and unit testing as part of the pull request merge process. In addition, we can incorporate vulnerability and credential scanning as part of the build process, checking that any secretive or sensitive information has not been included in the source code.
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.