Pester is a versatile testing framework built using PowerShell. In this article we are going to look at using Pester to audit our Azure infrastructure for security compliance.
We’ve previously discussed using Pester to test Azure resources in our infrastructure pipeline. In that article we used Pester to run against a deployed Azure environment to check what we thought we had deployed had actually been deployed. In this article we’re going to take this a bit further and look at using Pester to validate that we have setup our environment in a secure manner and look for areas of concern, essentially a security audit.
Don’t forget to check out the other parts in this series:
Part 1 – Version Control Part 2 – Testing Part 3- Build Defining Infrastructure as Code is becoming prevalent in all areas of IT, but none more so than in the cloud. Be this Azure Resource Manager Templates, AWS Cloudformation or third party tools like Terraform. Once you’ve gone down this route, you open up the ability to treat your infrastructure code like any other code, and because it’s just code you can now leverage some of the tools developers have been using for years in their software lifecycle.
Microsoft recently announced the introduction of Azure Free Accounts, these are credit and resources that are free for a certain time period. This is aimed at competing with AWS free tier and similar offerings. Before we take a look at what is on offer, there are a few caveats to check to see if you are actually eligible:
To claim the free offer you need to be a new Azure customer, so that means your account has never had a previous trial or been a paying Azure customer.
As expected, day 1 of Microsoft’s Ignite conference saw a large number of announcements across all products, including Azure. Below you’ll find my summary of Azure announcements I pulled in from the conference floor. There are a lot of quality of life announcements that didn’t necessarily make it into the Keynotes, but that could be a big deal if they impact you.
Also a quick reminder, if your at Ignite and have the time please feel to come see my sessions on Wednesday afternoon in community theatre 5, starting at 15.
It didn’t make it into todays Ignite Keynote, but today Microsoft released a preview of a new Azure service, Service Endpoints. It is now possible to take Azure services that have previously only had public endpoints, and restrict these to only allow access from a specific virtual network (or multiple networks), or even specific subnets.
This preview is starting out with Azure SQL and Storage, with more services to come along soon.
In an on premises world, with Active Directory, password expiry is easy. Set the required policy for your domain, make sure it’s applied and forget about it, AD will take care of enforcing password changes and compliance with your password rules. Moving your identity to Azure complicates things, and that’s what we are going to talk about today, and in particular password expiry and related processes in the world of Azure AD Connect.
Microsoft today released a public preview of a new service, Azure Container Instances. This may seem confusing initially, Azure already has a container service called Azure Container Services (ACS), but this is a somewhat different offering. ACS is a full container hosting solution, including orchestrators, deployed on top of multiple IaaS based Azure Virtual machines. Azure Container Instances (ACI) is not an orchestrator, it is a platform for deploying containers quickly and simply.
As your Azure usage increased you will inevitably need to grant rights to other users to create and manage resources. Often you need to apply limits to what these user can do with their Azure subscription. Role Based Access Control allows you to put users into roles which grant them access to specific top level resources (virtual machines, storage, SQL etc.), what RBAC doesn’t do however is limit what you can do with those resources.
In my last article we discussed the various different options for providing SMB shares in Azure given the lack of shared storage. One of the options we discussed for this was using a new feature of Server 2016 – Storage Replica, and in this article we will take a deep dive into how to setup this up in Azure. This Windows Server feature allows you to replicate data between two servers (or two clusters) and could potentially be a great solution for replicating shares in Azure, if you can cope with the limitations.
In an ideal world, all our cloud applications would be designed from the ground up to work with the cloud, they would be designed to work with cloud principals, make use of PaaS services and provide high availability. Unfortunately, this is often not the case. We are regularly tasked with moving existing on-premises applications into the cloud as a “lift and shift” type operation, until they can be redesigned to be cloud native.
