If you are an infrastructure engineer responsible for managing an Azure environment, Azure Desired State Configuration is your friend. Desired State Configuration, or DSC for short, is a declarative PowerShell platform that lets you turn infrastructure into code.

Infrastructure as code is not really a new concept, but it is a powerful one. Cloud infrastructure has to be managed and accounted for somewhere. When it isn't in code, it usually ends up in a dozen other places, scripts, developer laptop BASH history, Chef server logs, and data bags, and YAML files on a forgotten server. The table in an SQL database, a product manager's email, a post-it note on someone's monitor, etc, etc. Managing infrastructure configuration is very hard when it isn't transparently all in one place. This is the problem the whole infrastructure as code thing is meant to solve. Ideally, our infrastructure is defined in a shared audited version-controlled repository in GitHub or somewhere like it.

DSC lets us do exactly that using Powershell. If you've ever worked with tools like Chef or Puppet or Terraform, then you can start to get a mental picture. In DSC there are three basic concepts: resources, configurations, and the local confirmation manager, or LCM. Resources are the things: Azure VMs, individual files, processes, and other Azure assets. Think of them as our nouns, the object of our configurations. Configurations then, as you may have guessed, are like verbs. They describe the desired state of our resources. Configurations can incorporate a wide variety of parameters. We will dive into an example in a moment. But let's go to lastly, the LCM, the local configuration manager. This is the brain of the operation, responsible for ensuring our resources are in sync with our configuration. The LCM continuously pulls the state of our infrastructure to ensure everything is running as defined.

Now here's a very simple example. Take a look at this. This includes a single named configuration referencing a single node called TEST-PC1. Node resources are our Azure VMs. These are Windows host and the configuration type here is a Windows feature. Each gets its own block and we're defining a parameter for that feature. Here specifically a flag, ensuring a named feature is present.

So how do we actually use this configuration code? There are two prerequisites both of which, thankfully, can be done right from the web browser. First of all, the VMs needs to be connected to DSC. This just requires going into your automation account, clicking on DSC, and then selecting add to connect the node to DSC. Secondly, you need to upload and compile the configuration code. So you have your .ps1 config text file locally on your laptop and what you can do from the dashboard is upload it or copy paste it using the configuration editor. You can also do this using CLI tools. Once the config is uploaded you need to compile it. 

Now, this just makes sure that there are no syntax errors or problems before the config is applied. Once these two steps are done, connecting the VM to DSC and then compiling the config after uploading it, you can just apply the config to the desired node right in the web portal with a simple point and click. Now, this should give you a sense of how configurations and resources look in actual code.

But we can't forget about the third element, the LCM. The local configuration manager actually has its own configuration. We can adjust how frequently the LCM executes configurations and we can toggle the LCM back and forth between the push and pull model. The push model is the default, where the LCM server will just regularly push configurations out to all designated resources. The latter pull model allows for more flexibility as this requires you to define some form of pull service. This lets you specify for individual resources exactly which pull service endpoint to use for config or resources.

And then finally we should mention that DSC has support for partial configurations. That is pulling configuration from multiple sources and then combining them into one complete config. This might sound strange but there is a reason for this use case. It can be done in both a push model and a pull model. Now this more complex use case, what it does actually is it adds a really interesting flexibility to your configuration management paradigm.

So here's an example scenario where this might be helpful. Imagine you're in a larger team with different groups of developers and these different groups of developers have specific responsibilities. So for example one team is responsible for the database config and another team is responsible for app config. Using partial configurations, each team can define their own part of the system and then use DSC to assemble it all come deployment time.

Okay, so now we have some basic understanding of Azure DSC. This is crucial before we move on into the next level of automation. DSC is really just a subset of our Azure Automation Account. Before we can see how it relates to security compliance we'll need to explain how we can effectively administrate DSC infrastructure, how we can manage it. The next lesson will cover that and include a demo showing how to actually utilize DSC scripts. See you there.

 

Useful Links

https://docs.microsoft.com/en-us/azure/automation/automation-dsc-overview

https://docs.microsoft.com/en-us/powershell/scripting/dsc/managing-nodes/metaconfig?view=powershell-7

Lectures

Course Introduction - Compliance & Security Scanning - Security Center Demo - Preventing Drift - ARM, Activity Log & Track Changes Demo - Azure Desired State Configuration Demo - Azure Automation State Configuration - VM Agents & Extensions - VM Agents & Extensions Demo - Security & Compliance Pipelines - Azure Pipelines & Gates Demo - Course Summary