Automating NSG rules with an external IP in Terraform

· · , , , ,

Tagged: , , , ,

For some time, I have been using Terraform to create environments – and it’s something I rely on heavily for my own Azure lab environment. My lab is an ever changing picture – and thus I regularly create and destroy resources and environments, to test new things. I usually just run Terraform locally and have it spin up specific lab environments as and when I need them.

One thing I often do to make my lab environments easy to access is enable RDP directly to VMs – obviously this is something to be avoided in production, but very useful for quick and easy access in a lab or test environment. I have a standard home broadband connection – so my IP sometimes changes, which can make managing NSG rules challenging, and no one wants to update lab scripts when it can be avoided with an easy solution!

To make this more secure and easy, you can create a data source within Terraform, and then use this during deployment, so that the NSG rule is created dynamically. To do this, we use a data source in our code, and a URL from an IP check service:

#Get Client IP Address for NSG
data "http" "clientip" {
  url = "https://checkip.amazonaws.com/"
}

We can then use this when creating NSGs within Terraform – see line 15 where the external IP is used dynamically:

#Create NSG for dc01
resource "azurerm_network_security_group" "dc01-nsg" {
  name                = "dc01-nsg"
  location            = var.loc1
  resource_group_name = azurerm_resource_group.rg2.name

  security_rule {
    name                       = "RDP-In"
    priority                   = 100
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "*"
    source_port_range          = "*"
    destination_port_range     = "3389"
    source_address_prefix      = "${chomp(data.http.clientip.body)}/32"
    destination_address_prefix = "*"
  }

  tags  = {
    Environment  = var.Environment_tag
    CreatedBy    = var.CreatedBy_tag
  }
}

Once this resource has been deployed, the external IP at the time the Terraform was run will be included in the NSG. (IP address obscured below):

This is quick way to provide an automated NSG rule based on the external IP of the machine running Terraform. Any changes to the rule in the NSG done outside of Terraform, or changes to your client IP address will be updated when Terraform is run again. Thanks for reading – hope this helps! 🙂

Enterprise Scale considerations for Windows Virtual Desktop

· · , , , , ,

Tagged: , , , , ,

In my previous post I talked about Landing Zones and why they are an essential part of the Cloud Adoption Framework. Following on from that post, I wanted to elaborate on some of the considerations around Windows Virtual Desktop (WVD) in particular. WVD brings with it several unique elements that benefit from additional consideration and planning – particularly when designing for Enterprise Scale. A pragmatic way of looking at this, is that if you are considering Windows Virtual Desktop, it makes sense to spend some time getting the basic foundations in place, and hopefully this post will help.

A Landing Zone should enable scalable and modular growth, by considering and designing against common design areas. Previously I covered these from a general viewpoint – but in this post I will provide some thought around WVD for each of the design areas. Whilst Landing Zones are generic and all-encompassing in their nature, the Design Areas and Enterprise Scale considerations within are extremely useful for planning and designing Azure Services – and WVD is no exception.

Just to note – my lists/thoughts/ramblings here are not exhaustive, but just designed to provoke thought, with realistic examples of the considerations that may need to be made within each area. I’ve included links to reference documentation, community articles, and other items where possible. This article particularly takes the focus viewpoint of enterprise requirements – so for some smaller or less complex deployments, some of these will obviously not be required.

Landing Zone Design Areas – Thinking about WVD… 

Enterprise Enrolment

The key here really is making sure we have a suitable Enterprise Agreement in place to support our WVD needs, both now and in the future.

      • Agreements – To ensure we can consume the required resources for, and to support WVD. This goes beyond just hosting a workload – for example, ensuring we can consume services to support Profile Management, Networking and Security Services, and provide for any application requirements.
      • Subscriptions – How will these be structured to support business units/billing areas/regional requirements/dev/test etc? It is worth spending time planning these out to ensure they are specifically built to support growth at scale. Ensuring our plans won’t hit any limits is also worth considering.
      • Billing – Are we setup to consume WVD in a way that works for our financial needs? What about our needs in the future if we expand or change? It important here to consider any growth potential or likely changes – does the proposed design pass the “2020 test” (aka the “what if we need to scale this up/down quickly?”). Reserved instances should be considered here too.

Identity

Anyone who has ever worked on a Virtual Desktop Environment will know that identity is (quite literally) the key to everything. WVD has requirements for both Azure Active Directory, and Windows Active Directory. For WVD, we need to consider how access will be controlled and managed – and not just end user access, but also management access. We also need to ensure that our Session Host VMs can reach our Windows Active Directory Domain Controllers, so there is some crossover into other areas here.

      • Azure Active Directory – To support users/groups that need access to WVD, and to ensure we can take advantage of all the security and authentication features in AAD. Considerations here are likely to be around MFA requirements, group management, and managing security, as AAD is the first point of authentication for WVD.
      • Windows Active Directory – We need to have Windows Active Directory available for Authentication, Group Policy, and any application authentication requirements, so this needs to be considered in any location where we may wish to host WVD Sessions. Ideally the presence of Domain Controllers in the same Region, or at the very least, network access from the Subnets WVD will reside in.
      • Management Access – How will technical staff access Session Host VMs for everyday management, or to reboot a VM should there be a failure? It is important to think here about role assignments and access levels… delegation is key!
      • Supporting Services – Have we considered if any supporting services have authentication requirements? For example – are we using Azure NetApp Files with Active Directory authentication to store user profiles?
      • Applications – Do we have any applications that require Identity Management technologies that we need to consider alongside WVD – for example applications with specific authentication requirements.

Network topology and connectivity

Networking considerations for WVD are mainly around access, and connectivity to other services (applications and supporting services), but importantly, also need to account for inter-region connectivity and provide room for growth. Given that designing for scale is a key Landing Zone consideration – it is worth spending some time planning this out for a WVD deployment. Questions around growth and scaling for all technologies in the environment is a good starting point – for example, questioning each service in use with “what if our user base halves/doubles/triples?”.

      • Network Topology – What impacts will WVD have on our Network Topology? Have we considered the need to access backend applications across our Azure and on-premises estates? Have we considered our needs now and our potential needs in the future – thinking here about scaling! (Basic elements should be covered here – can our subnets provide enough IPs if we increase our session host count, for example?). A mapping exercise is also great option here – mapping out network paths and traffic flows for key applications that will run on WVD and ensuring the supporting network infrastructure is in place. The WVD experience estimator is useful for Client network checks.
      • DNS – DNS is critical for performant access to WVD, as Traffic Manager is involved and provides geographical routing based on the DNS lookup source.
      • Firewalling and Security – Firewall and Security implications for WVD go far beyond simply ensuring appropriate NSGs are in place. Considerations here need to be at an organisational level – and how any WVD environment will fit into requirements, and any security baselines or frameworks. Azure Policy is useful here to ensure deployed resources meet the required standards. Key considerations are around Firewalling, NSGs, Web Filtering, Traffic Analysis, access to internal resources etc. Azure network security best practises, and Safe URL list are worth referencing.
      • User access – User access is an important consideration around WVD – and specifically needs thought and planning around how users will access WVD. Will we advise users to use the HTML5 Client, the Desktop Client, or possibly an Android or iOS Client? What about unknown device types? It is worth spending some time here working on how you will communicate with and advise users, and roll out any required clients.
      • RDP Shortpath – Whilst RDP Shortpath is still a preview service at the time of writing, it has some great benefits for latency sensitive applications and input methods, therefore it could be considered as a potential future enhancement. Planning for the Networking, Public IP addressing and NSG changes required can save time in the future.

Resource organization

Organising Resources is essential for ensuring optimal deployment and ongoing management of Azure Services. Resource Organisation has implications in many areas – from everyday management, to future growth, to billing.

      • Locations – For location it is important to consider the Azure Region that your WVD Session Hosts will run in. Usually this is a case of providing a balance between end user location and application data/backend locations. In some cases, having multi-region deployments is appropriate. It is also worth putting some thought here into whether a secondary region is needed to provide resiliency.
      • Resource Groups – Resource Groups can be used in a variety of ways, however for WVD the considerations should ideally be around ensuring appropriate levels of resource management, control, and ensuring that this follows any existing group arrangement or strategy. Most services are grouped together, and sometimes split further down by location – this also works well for WVD.
      • Business Areas – Business Areas may also need to be split into different Host Pools, across different locations, with different settings. Mapping out the Business Area requirements prior to any deployment, with a view around current and future needs is a worthwhile exercise.
      • Tagging – Tags are a great way to optimise resource management, and any WVD environment should have a tagging approach in line with the wider organizational strategy. Consider, for example, how WVD Resources will fit into the wider Azure Resources already deployed.

Governance disciplines

Governance requirements vary hugely from business to business, and workload to workload. It is also sometimes the case that various services have different ongoing management requirements that need to be adhered to. In the case of WVD it is important to consider organisational requirements, and plan how these might be applied to and controlled in WVD environment.

      • Management Groups – Management Groups are a key part of any architecture designed for Enterprise Scale. With WVD they are a useful option for grouping WVD Resources under a management structure.
      • Security Requirements – Security Requirements should be given consideration when planning for Governance. Azure has a range of tools (Like Policy, Locks and Tagging), to ensure these are met – and various Blueprints that can help too.
      • Azure Policy – Can help to enforce standards and evaluate compliance across your estate. Azure Policy, when built into a Landing Zone, is a great way to ensure resources are deployed in accordance with organisational governance. For example, restricting deployment to specific regions, or preventing Public IP addressing.
      • Locks – This one is fairly self-explanatory – but Resource Locks can prevent accidental deletion or modification of resources, and should be considered for any critical resources.
      • Tagging – I have already covered tagging in the section above – but they are also extremely useful for Governance, ensuring Resources are categorised and managed in appropriate ways.

Well worth a look is the Cloud Adoption Framework Governance Benchmark Tool

Operations baseline

Monitoring is essential for any technical resource, whether it is on-premises or in a Cloud platform. However, with a Virtual Desktop environment like WVD, monitoring is critical. Not only for ensuring the health of the environment, but also ensuring the performance for end users.

      • Monitoring – Azure Monitor and Log Analytics provides almost endless possibilities for working with log metrics and data. The key for WVD is identifying the key metrics and creating ways to interact with that data that provide the level of insight required by your organisation. There are some great options detailed for this – like this dashboard. 
      • Service Health – Service Health is a great way to be notified about incidents and planned maintenance within Azure. It is essential that anyone managing a WVD environment is getting alerts from Service Health. The good news – it takes only a few minutes to setup.
      • Monitor Insights – Getting Log and Performance Data out of your WVD Session Hosts, and any supporting services is critical for ensuring performance. As we all know, managing issues and providing evidence of faults or potential resolutions relies on accurate data. Getting agents and data collection setup is important, but so is identifying key metrics and technical KPIs for your environment – and then visualising the data using a dashboard, or another toolset.
      • Ongoing optimization – Ongoing optimization is an area that needs consideration for any environment built to scale. With WVD the needs are likely (in the longer term), to be around patching, application management and scaling of the environment. Considerations here need to be around how patching will be managed, how applications will be updated, and any specific requirements in terms of scaling and ongoing tweaking.

Business continuity and disaster recovery (BCDR)

When designing for scale and growth, it is vital that resiliency and continuity are considered. As well as ensuring access to business-critical resources is maintained, considerations around backups, and the need to retain data for legal purposes should also be considered. In most cases, a WVD environment will not be storing any business critical data but will be the access method for it – so usually the considerations here are around ensuring continuity, security, and regional resiliency.

      • Local Resiliency – WVD resources should be protected within regions using Availability Sets and Zones where applicable. Consider protecting supporting services too as these are often overlooked – for example, networking links back to on-premises resources or supporting services within Azure.
      • Regional resiliency – Thanks to the flexibility of the Azure Platform, it is simple to deploy host pools in different regions and use VNET Peering to build out topologies. Consider having a host pool ready to spin up in a DR Region should there be an issue with the Primary Region.
      • DR plan – Goes without saying really – but a plan of the actions and who will action them, for invoking DR operation for a WVD environment should be considered essential. Ensuring that any DR plan will not be impacted by limitations, for example, API limits is important (WVD Specific Limits are here). (Thanks to @crod for highlighting!)
      • Backups – Backups are an essential consideration for any WVD environment. Considerations here need to be around protecting any custom images or supporting services – so that they can be protected effectively and brought up in another region should the need arise.

Deployment options

Deployment options are another area where there will be large variation in approaches between different organisations. However, considerations around deployment have implications for the whole environment moving forward – management and flexibility are impacted greatly, for example. Spending time at the start getting these elements right, and exploring the different options available, can really save lots of time in the future.

      • Azure Portal/CLI/PowerShell/JSON/Terraform – Have we considered all available methods for deployment/ongoing management or changes to the infrastructure? If time permits have any other options, not previously tested, been evaluated? This is more for awareness – but helps to give a balanced view of available methodologies and toolsets.
      • IaC/DevOps – Could we consider an infrastructure as code or DevOps approach for our deployment? There are numerous toolsets that could assist with this, and it largely depends on organizational readiness and other methodologies already in use. As per all the points in this article, it is worth evaluating options and making decisions with long term growth and scaling in mind.
      • Disk Images – What needs do we have around updates/changes/patching to our images? Do we have a robust test plan in place, prior to rolling out any changes? How are we managing any backups for templates/images? An important consideration here for WVD is around managing applications within Images and Session Hosts – could existing tools e.g., could SCCM be used for example?
      • 3rd Party Tools – There are a number of 3rd Party tools for WVD that enhance the deployment and management process. Nerdio and NetApp VDS are potential options.

Summary

If you have made it this far down the article – congratulations! I hope this has been a helpful and thought provoking look at various areas that can be considered for the scale and growth of a WVD Environment. As always, if you have any questions, please feel free to reach out either via my contact page or via twitter @jakewalsh90. Until next time – Thanks!

Why you need an Azure Landing Zone

· · , , ,

Tagged: , , , ,

A defined and structured Landing Zone is key component of the Microsoft Cloud Adoption Framework. But what exactly is a Landing Zone, and why is using one important? I’ll try and provide an overview and give some specific examples of the Design Areas, as well an overview of options around enterprise scale in this post.

What is a Landing Zone?

A Landing Zone is a method of achieving scalable and modular growth within Microsoft Azure. A Landing Zone does this by providing common design areas that need to be considered for the majority of Cloud Adoption journeys. Essentially, Landing Zones provide a foundation for growth, but in a scalable and modular fashion – acknowledging that there is no single technical solution for all types of environment.

It is important to note that some Landing Zones vary significantly compared to others – because they are modular, and vary with business and technical requirements. This variation is to be expected, and the Landing Zone concept breaks this down using it’s modular approach – by covering specific design areas.

The Landing Zone concept is essentially all about getting the right foundations in place to allow growth at scale – with the right elements (Design Areas) in place to support your growth. For an enterprise public cloud environment this is an essential part of the adoption journey.

Landing Zone Design Areas

Whether you are designing for a large, multi-location, enterprise hybrid-cloud deployment, or deploying a simple, isolated test environment, each of the design areas below should be considered within your Landing Zone. Note: I’ve provided some example questions against each Design Area here for thought, but these are not exhaustive in any way!

  • Enterprise enrolment – Do we have a tenant in place that will support our growth and needs moving forward? Will we use EA/CSP/PAYG etc? How will we structure our subscriptions?
  • Identity – How will identity and access be controlled and managed?
  • Network topology and connectivity – What will our network topology be? How will our resources and locations be connected? What will our needs look like in days/weeks/years to come?
  • Resource organization – How will we organise our resources to allow for growth without red tape? Considering our needs around management groups, subscriptions, our business areas, different teams and more.
  • Governance disciplines – How do we stay compliant? How do we enforce security requirements? How do we ensure our data sovereignty?
  • Operations baseline – How will we manage, monitor and optimise our environment? How will we maintain visibility within our environment and ensure it operates as required?
  • Business continuity and disaster recovery (BCDR) – How will we architect for continuity and protect our data? Have we considered the need to replicate data or provide a method of restoration? Do our proposed methods meet the RPO and RTO objectives of our organization?
  • Deployment options – How will we deploy our Landing Zone and resources moving forward? Will this be a manual process? Will we consider Infrastructure as Code? What methodologies for deployment could we use? 

You can read more about these design areas within the Cloud Adoption Framework: Design areas of a well-architected landing zone – Cloud Adoption Framework | Microsoft Docs

What about Enterprise Scale?

For me – this is perhaps the most relevant area, as the majority of customers I work with, have enterprise needs. Thankfully, the Cloud Adoption Framework also covers Landing Zones for enterprise scale, including reference architecture (to demonstrate design areas and best practices), and Azure Resource Manager (ARM) templates to accelerate the process.

There are a number of example implementations for enterprise scale Landing Zones available – and these also include ARM templates and documentation to provide straightforward deployment. For example: https://github.com/Azure/Enterprise-Scale/blob/main/docs/reference/wingtip/README.md 

Image from GitHub Link above

Enterprise Scale – Design Principles

Enterprise Scale design principles serve as pointers for organizational decisions towards achieving your required Azure growth. These are the critical principles that need organisational decisions to achieve enterprise scale, and the provided reference architectures (above), are based on these Principles.

  • Subscription democratization – Considering how Subscriptions can be used to enable management and scale aligned to business needs and units.
  • Policy-driven governance – Using Azure Policy correctly to provide compliance, whilst ensuring application owners are not hindered in migrating their workloads and applications. 
  • Single control and management plane – Providing a consistent experience for operations teams, utilising role-based access and policy-driven controls.
  • Application-centric and archetype-neutral – Using a focus on application-centric migration, rather than a lift and shift mentality. Also focusing on providing a foundation for all application types that the enterprise could deploy. 
  • Align Azure-native design and roadmaps – Using Azure-native services and capabilities, ensuring that the enterprise can benefit from new capabilities.
  • Recommendations –  Balancing functionality, using preview services for testing/development/future enhancements, and using technical roadmaps to allow migration. 

You read more about the Design Principles here (Microsoft Docs).

Enterprise Scale – Design Guidelines, and Critical Design Areas

Enterprise Scale Design Guidelines provide an enterprise viewpoint for each of the Critical Design Areas. These viewpoints provide an important reference for anyone starting to design a Landing Zone for an enterprise environment.

Any decisions made against the Critical Design Areas will have a significant impact. Many of the areas are heavily linked, so decisions made in one area impact others, and vice versa. These interrelations and interdependencies necessitate time spent evaluating each Critical Design Area, both individually and as a group – ensuring that there are no conflicts or missed requirements, for example.

The Critical Design Areas are:

I have linked each Critical Design Area above to the Docs page for each, which provides more detail, Design Considerations, and Design Recommendations.

Summary

Congratulations if you have made it this far! I hope this has been a useful look into Azure Landing Zones, the considerations for each Design Area, and the Enterprise Scale elements that need to be considered.

A Landing Zone provides an organization with a scalable and modular platform, built on solid practises, reference architectures, design considerations, and more. A  Landing Zone is a key component of the Cloud Adoption Framework – ensuring the cloud journey starts in the right way.