Microsoft Azure is a robust, feature-rich cloud platform used by a growing number of technology companies. With its vast array of services, a key challenge to administering an Azure environment is security. How can we ensure that our Azure infrastructure meets strict security standards? This course offers the answer.
In three concise units, the student will learn all about compliance and cloud security. The course delves into several key Azure components, including Azure DevOps, Azure Security Center, Desired State Configuration, and Azure Pipelines. After completing the lessons and watching the video demonstrations, the student will be equipped with the knowledge to automate critical security tasks to ensure a thoroughly hardened cloud architecture.
This skill set will serve infrastructure developers working with live environments or seeking to pass certification exams. Most importantly, it will help students understand cloud security in a comprehensive and thorough way.
For feedback, queries, or suggestions relating to this course, please contact us at email@example.com.
- Scan infrastructure using Azure tools to prevent drift leading to compliance violations
- Automate configuration using Azure Automation and Desired State Configuration
- Create secure and compliant software pipelines in Azure
This course is intended for:
- Those looking to learn more about the security and compliance features in Azure
- People studying for Microsoft's AZ-400 exam
To get the most from this course, you should already have a basic understanding of Microsoft Azure as well as some knowledge of programming and cloud infrastructure.
Okay, greetings once again, friends. Welcome to the fifth and final demo for our course on Azure Security and Compliance. This will be a very DevOps-focused video as we dig into Azure Pipelines. We'll learn how to set up a basic pipeline for CI/CD using the Pipeline service, and then we'll then add a gate to demonstrate how we can automate security compliance checks. So without further ado, let's dive right in.
So first off, we need to go into Azure DevOps. That's where the Pipeline service is set up. And like a lot of other Azure components, it's not enabled by default. You have to enable Azure DevOps. You'll go into your DevOps organization after you create it and you'll need to set up a project. This is also very simple, just point and click through. You can create a project. Here we have something called TestProject7. This will be our basic test project for this demo.
Now, when you first set up a pipeline, Azure DevOps is going to need to know where the source code is hosted. So for example, if we go to Pipelines and we click New Pipeline, very first thing it says is, "Where is your code?" So we have some options here for popular services like GitHub and BitBucket, but be aware, we have this really cool option Other Git, any generic Git repository. This is very helpful if you're using a less popular service. As of the creation of this course there's no option here for GitLab. And I hope they add that because I'm a big fan of GitLab. I love GitLab. So if you're using GitLab or if you're just hosting your Git repo at some random location, as long as you have the URL and its open, you can get to it using this Other Git option. Be aware that also if you are using BitBucket or GitHub or something like that, you have to authorize it. So if you click on GitHub, it's gonna ask for permission to pull code from the repository. So assuming you're logged in, it'll find your GitHub, it'll try to access it and it will request permission. You just have to click to grab that permission. It's just one click.
So we can actually see this in GitHub. We can go to our test project here and we can see this is our TestProject40. This is what we're connecting to Azure Pipelines. And to see the connection actually, we can go into settings and if we go to Integrations and Services we can see that Azure Pipelines is listed. That is connected to this repository and it has permission to pull from the repo. Now the actual pipeline configuration is defined in a file called azure-pipelines.yml. That's where we were a second ago. We can see that this config is actually really, really simple. All it's doing is printing to the console. It's doing an echo "Hello world" in an environment called QA. So not really doing a lot of work.
Now, the standard way to configure a build job like this is to have it run whenever a change is merged into a particular branch in our git repository. Now we can do that by either editing our YAML or editing the job in the console. And when we edit the YAML, we care about this word trigger here, by default it's set to master but we can actually customize the behavior to have it do pull request triggers or even scheduled triggers if we just want a job to run at specific intervals. So we go back to our pipeline here, we can see the amount of times it's run. And we can also run the pipeline manually by just clicking run pipeline here without having to worry about any triggers.
So let's give this a click. Let's see if it works. It's gonna by default work off of masters. We'll just click run. And it'll take a few seconds but it's a pretty simple build job. So we let it go through its deployment. And it should just be a second to finish. Let's try giving that a refresh. Ah, here we go. We can see the duration. We can see it's actually running. But it's just echoing output to the console so it should be pretty quick. And there we go, done, successful. We could actually see the logs of the deploy here as well.
Now from looking at this, as I'm sure you can tell, we could go into a lot more depth with Azure DevOps, the portal and the pipelines. It really is an incredible tool set, especially as a DevOps engineer. I really appreciate it so I do recommend checking out other courses on DevOps specifically. Since this is a security course though, we're gonna skip digging into all the YAML config and all of that and we're gonna focus on the most critical security feature in Pipelines, and that is automating security compliance checks. And in order to do that, we're gonna need to create a gate.
Gates are connected to releases in Azure DevOps. Thus far we've been working with a generic build pipeline with no real concept of releases and only one environment really to worry about. To show off how gates work, let's create a brand new release pipeline from scratch, right from the portal. And again, this all can be done with the CLI and scripting but we're gonna go from the portal here. We're just gonna click on the releases section and we'll do new pipeline. And what we do for our pipeline, we have to define stages. So you can see there's many different deployment types. We're gonna just do an empty job for stage one and then we'll add a new stage two, which'll also be an empty job. So you can note, we're not actually deploying any code anywhere. There's really no tasks to worry about but one thing that's worth noting is the variety of deployment types. So deploy to Kubernetes cluster, deploy to Azure Apps Service, Job App, Azure Functions, if we scroll down, there's a lot of deployment types here. But we'll leave this as empty for right now. Our interest is not on the specific content of the deployment job. Our interest is in what happens in between two stages. And that's really where we're gonna have a gate. So to create the gate, we're gonna click on this little icon here next to the stage with the little guy on it where it says pre-deployment conditions.
So we're gonna click on that. And what you'll see there are a few options here as well, triggers, after stage, after release. Our interest, again, is gates. So we're gonna click on gates. You have to enable it. So you click enable and then you're gonna click add. And so here we can see a few different types of gates show up. We can invoke an Azure Function between stages. We can query monitor alerts here. We can invoke a REST API. These are the ones that pop up right away. But here's the one we really care about, check Azure policy compliance. So we click on that and in order to make that work, we have to select our Azure subscription. So this our free trial subscription here. And then once that comes up, you have to authorize it usually. When you authorize it, be aware that it might have a pop-up block. I had to turn off my pop-up blocker for the authorization to work. So be aware of that. You can also select resource groups, to restrict it a little bit. It's not a requirement but once you have that done, you can just close this dialogue and now you have a pre-deployment condition defined for this stage. So you can click save. You can save it in a folder. We don't have to have any comment. And now we have a pipeline with automated security compliance checking. Now you might be wondering, what does compliant mean here exactly? If a release violates one of our policies it will throw an error and fail.
So really what compliant means is determined by your security center account. Whatever you have defined in your security setting, this is where you define your policies and so if you have a policy for some network rule or something like that and if it violates that in the pipeline, this is where it'll fail. So there you have it. We now have some understanding of how to work with Azure Pipelines to create CI/CD pipelines and most importantly, how to define security compliance gates for deployment. This is definitely something you're gonna want to play around with and experiment with on your own to understand the behavior. Check the Azure documentation links (below) for more info and some nice how-to guides. And thank you for making it this far in the class and good luck.
Course Introduction - Compliance & Security Scanning - Security Center Demo - Preventing Drift - ARM, Activity Log & Track Changes Demo - Desired State Configuration (DSC) - Azure Desired State Configuration Demo - Azure Automation State Configuration - VM Agents & Extensions - VM Agents & Extensions Demo - Security & Compliance Pipelines - Course Summary
Jonathan Bethune is a senior technical consultant working with several companies including TopTal, BCG, and Instaclustr. He is an experienced devops specialist, data engineer, and software developer. Jonathan has spent years mastering the art of system automation with a variety of different cloud providers and tools. Before he became an engineer, Jonathan was a musician and teacher in New York City. Jonathan is based in Tokyo where he continues to work in technology and write for various publications in his free time.