wheretostart

Joe Carlyle

Azure Private Link – Where to Start?

Last week, Microsoft announced that the majority of Private Link is now GA. This means it’s now supported for production workloads, however, is it useful for your production workloads? Hopefully this post will help you understand the service a bit more, and whether it’s worth investing your time in exploring.

First up, what exactly is Azure Private Link (APL)? Well, it allows you to access Azure resources using a private endpoint in a virtual network. There are two possible component within APL.

  • Private Endpoint
  • Private Link Service

A Private Endpoint is a private IP that exists within your vnet and presents a service via APL. Traffic targeting a service via APL travels via the Azure backbone, removing the need for public access if it’s not required. The service could be Azure PaaS, or a service presented by yourself, or a Partner via Private Link Service.

A Private Link Service leverages Azure Standard Load Balancer frontend IP configuration to present as a service, for use by a Private Endpoint. The workload behind ALB could be your own, or a vendors.

Below is a somewhat complex diagram explaining this visually, from Microsoft

Private endpoint overview

So, let’s try break that down into simpler concepts.

First, it allows you to access PaaS services without the need to implement a Microsoft Peering for ExpressRoute. Which gives you greater flexibility as well as a simpler footprint should you have VPN connectivity.

APL maps to single instances of resources, rather than whole services, so you have a more direct and therefore secure connectivity footprint. For example, allow connections to an Azure SQL instance, rather than all Azure SQL instances. This is also relative to vendors providing a service, you can connect to just their presented endpoint rather than a broader or more complex connection.

All of the above can be done across regions and across Azure AD tenants, so if you are providing a service, you can offer it via APL at a global scale.

A lot of Azure PaaS is GA, but there are still quite a few in Preview, so be wary of your production requirements, a full list is here – https://docs.microsoft.com/en-us/azure/private-link/private-link-overview#availability

So what might an APL deployment look like in your environment? Below, I’ve put together a quick example from my own tenant. I have a very simple website, running from a Storage Account and I have a test VM I will RDP to to load the site.

I created an APL, connected it to the SA, which automatically makes a couple of changes and auto-approves the connection within the SA. So now, when I lookup the corresponding endpoint, it shows as a private IP within my vnet (10.55.1.5), and I can browse to it successfully (cert error is expected due to lack of DNS here).

Within APL, I can check the status of my Private Endpoint, which confirms settings as expected.

And on the SA itself, I can see that a Private Endpoint has been activated.

So all of the above seems quite simple and very usable. But there are some current limitations to be aware of.

For Private Endpoint, NSGs are not supported. While subnets containing the private endpoint can have NSG associated with it, the rules will not be effective on traffic processed by the private endpoint. When you create a Private Endpoint via the Portal, it automatically makes a switch to the subnet to disable network policies. Other deployment methods require a manual change, documented here – https://docs.microsoft.com/en-us/azure/private-link/disable-private-endpoint-network-policy

For Private Link Service, it must be a Standard ALB, only IPv4 and only TCP traffic. The above note about subnets and network policies is also valid, documented here – https://docs.microsoft.com/en-us/azure/private-link/disable-private-link-service-network-policy

Overall I think APL is a great addition to the network offerings and more closely aligns what Operations teams like to be able to control when working with PaaS. The options it introduces for vendors could also see some clever solutions brought to market, especially with the supported global capability.

As always, if there are any questions, get in touch!

Joe Carlyle

Converting Classic Azure Resources (ASM) to Azure Resource Manager (ARM) – Where to Start?

During a couple of recent client engagements, I realised there are still quite a few people using Azure Classic Resources. The simple reason for this is that they work and we all know in IT, if it ain’t broke…etc.

Now, if you only recently began working with Azure, you may never have even seen a Classic Resource. The change to Azure Resource Manager (ARM) started back in 2016. Classic Resources do have some similar objects now that they are fully in the “new” portal (yes there was an old portal, it was…odd) but the concepts are different. This is because the focus was on services, hence it being referred to as Azure Service Management (ASM). Now, Azure is focused on resources, therefore Azure Resource Manager (ARM).

Azure Cloud Services diagram
ASM Example

So if you discover, or own some classic resources and would like to move them to ARM, hopefully this blog post will help you make a start.

First, do you need to migrate away from ASM? So far, Microsoft has said no, they’re “not deprecating ASM in the near future”. However, if you note the use of “near” that could mean that as the Azure Roadmap progresses, ASM is eventually deemed redundant.

Updated 2020-02-28, Microsoft have announced deprecation of ASM VMs and dependent resources on March 1st, 2023.

The other reason for a migration may be that you want to avail of some of the features only supported in ARM or want to gain greater granular control of your individual resources. Whatever your reason, the approach is the same:

  • Plan
  • Validate
  • Prepare
  • Migrate
Plan

In this stage, you need to understand and most likely document all of the resources in scope for the migration. Once you have this, you can compare and contrast to options supported and changes required for migration to be successful. The following resources are supported for migration:

  • Virtual Machines
  • Availability Sets
  • Cloud Services with Virtual Machines
  • Storage Accounts
  • Virtual Networks
  • VPN Gateways
  • Express Route Gateways (in the same subscription as Virtual Network only)
  • Network Security Groups
  • Route Tables
  • Reserved IPs

The list for currently unsupported features is here.

While the migration operation for the most part takes place in the management plane, and there is therefore no downtime, you could proceed with a migration without impact to your users. However, I’d recommend either completing the migration out of business hours or planning a maintenance window to account for any unforeseen issues. I’d always rather have the window and not need it than the opposite!

It’s also important at this point to understand the order resources should be moved too. Microsoft have this flowchart, the lines are bit confusing but it’s accurate.

Screenshot that shows the migration steps

The most important point to take from the above is that if your VMs are all in the same vnet, well then you migrate the vnet, it will bring all dependent resources with it. Then your next step is any storage accounts.

Validate

Microsoft have provided a helpful validation operation within the portal and via Poweshell. This will give you a very quick look into your resources and their config to see if it’s compatible with a migration or not. However, it can not take into account all unsupported features, such as an issue on the ARM side, so ensure you complete your own checks!

Prepare

This is a key phase. The migration process occurs on the control plane, the data plane is unaffected at all times. The preparation operation allows you to create the ARM metadata while leaving your current ASM resources in place. This is represented in the graphic below:

Diagram of the prepare phase

Once the operation begins, the management plane is locked for the duration. This means you cannot make any changes to your resources. However, your users are unaffected. With one exception, if your VM is not in a vnet ( I know, crazy in ARM!) it will be stopped and started during Prepare.

If Prepare is successful, you can continue with the migration or, abort and fix any issues. The operation creates a non-editable Resource Group for each Cloud Service, copying the name and appending “-Migrated”. Nice and neat, relatively low impact and risk. Exactly what is useful during a migration! Remember, the management plane is locked, so if all is OK complete the migration to unlock. If not, abort to unlock.

Migrate

Once you’re good to go, the last step is to migrate. Again, this is only a control plane change. The operation is idempotent, so if it fails it can be retried. However, once complete you cannot rollback. Once complete, you will now be in the state represented below:

Diagram of commit step

The Classic Resources are removed and only the ARM versions remain. As the models are different certain services and aspects are renamed or incorporated in a different way, a full list of these mappings is here and is very useful during the Prepare phase and for future use once migrated.

All the steps required to migrate all VMs in the same vnet are documented and I’d recommend reviewing all steps before running any.

If you take your time and follow the recommended methods, you should be able to make your move from ASM to ARM pain free.

As always, if there are any questions comment or get in touch on Twitter!

Joe Carlyle

Azure Portal – Where to Start?

For most people, the Azure Portal is their first experience of Azure. And for the majority, it may be their only experience. Or for a subset, at least their primary method. In my opinion, there are two reasons for this:

  1. People love a GUI
  2. You can do quite a lot of work without needing alternative methods of access/deployment

Neither of these reasons could be considered good or bad, this isn’t a comment on peoples working habits! I firmly believe that you should use the tool that works for you.

For example, if you’re very comfortable with using a command-line, that may be your choice for Azure. Also, there are some more complex operations that are only available via command-line options so you may need to dip in for that. However, don’t let a dip-in for a couple of operations fool you into thinking you need to work differently.

In my opinion, the Azure portal is great. I obviously use it every day for many different environments. Regardless of how complex my deployment requirements are I still always have access to the Portal for that job. I work best visually and this is what suits me. So, if you’re like me, hopefully this post will help with some tips, dos & don’ts, and general time saving advice for when you’re using the Portal.

Search Bar

First up, I’m going to start with the feature that has saved me the most time over the last year and that is the search bar.

This magic little bar should be your go to location for finding and accessing Azure resources. It is lightning quick and returns results from multiple locations, including Docs. Notice the keyboard shortcut in the screengrab above? Yep, press those two keys on your keyboard and start typing. That easy.

Search across all aspects available
Keyboard Shortcuts

Speaking of keyboard shortcuts, you can access the full list via the top bar and the help section

Here you get a list of available shortcuts, my personal favourite being G+R

Organisation

Next up, make sure the Portal is organised to help you work how you work. There are a couple of visual options like themes, but the functional ones are important. So the original landing view was the Dashboard option as below

Personally, I was never a big fan of this, I much prefer the new Home option:

But what’s important here is you have the choice. Work with both, choose which one suits you and stick with it. You set your default using the settings cog in the top bar.

Your next section that will really help day-to-day is the side bar. Again, the default here has changed recently, in the past it used to have a consistent docked list of favourites

This has now changed to a Flyout menu, which means this list is hidden unless you click to open it. This gives you more usable screen but obviously adds a step each time you want to use the side bar.

Speaking of the side bar, it comes with a default list of favourites. Spend some time removing those you don’t need and adding those you are constantly going back to. For me, my favourites list is different in every tenant as I work with multiple customers and each environment is unique. And remember, if you don’t like or use the sidebar, set it to Flyout in the settings cog and forget about it!

Portal App

A slightly different way of looking at it, but if you like the Portal, you can get access to a lot of features on your mobile phone via the App on Android and iOS. I’ve found the app to be surprisingly useful when out and about and need to confirm/change something quickly.

iOS App Screenshots from the store

Hopefully you’ve found something useful in this post. If you have any questions, or even any tips you would like added, get in touch!

Joe Carlyle

Azure Networking Security – Where to Start?

If you’ve read any of my blog posts regarding networking in Azure, you might have guessed it’s one of my favourite topics. For ITops, it’s one of the shifts in thinking required to make a change to cloud. As software-defined-networking is one of the core concepts required for a successful cloud implementation, it’s no surprise that the security of that networking is a close second.

Looking at it as simply as possible, good network security means allowing only required traffic and preventing everything else while logging what is useful for auditing. Azure offers several integrated services that can help achieve this.

With that in mind, there are three major scenarios to deal with when it comes to Azure networking:

  1. Azure Resource to Azure Resource
  2. Azure Resource to on-premises Resource
  3. Azure Resource to/from the Internet

I will reference each as we cover the different best practises available.

Access Control

Good network access control requires layering. In Azure, the most common networking concept is a vnet. A vnet does not, by default, get access to another vnet. However, within a vnet, every subnet, by default, has access to each other. So, the subnet layer is most likely where you will need to address access control. In Azure this can be done in two, free, simple ways. Custom Route Tables and/or Network Security Groups.

Custom Route Tables are exactly as they sound. They modify the system route table using routes you specify. If your route matches a system route, it will take preference, user defined routes always do. Similarly the lowest prefix match will always win. More on route tables here. CRTs are applied at subnet level and can quickly manipulate network traffic for your entire vnet. For example, preventing internet access by dropping traffic to 0.0.0.0/0.

Network Security Groups are a little bit more complex in application, but their concept is straight forward. They are an ACL for your network. They can be applied at subnet or network interface level. While NSGs allow you to create complex and granular rules quite simply, managing them at scale can be a challenge. More on them here.

Firewall

While the above allows for control of the network from a routing and access perspective, you may also need to control traffic by inspection and filtering. Within Azure, there are two main options for this; Azure Firewall or a 3rd party NVA.

Azure Firewall was released last year and is a stateful, firewall-as-a-service resource. It offers HA and scalability, however, it’s still a young product and therefore light on traditional network security options. More on it here.

Thankfully, Azure and network appliance vendors have been working better together recently. Most solutions you would expect are available in the Marketplace. The common gripe is that documentation can be light if not bad. However, if you need continuity with your local site, or a specific feature well then they are your best choice. My advice is to reach out to the Azure community if you are having issues, generally someone will have had the same issue and can help!

Perimeter

It’s best to start with some basic architecture decisions relative to your Azure perimeter.

  • Will Azure have a public perimeter?
  • Will it be inbound and outbound?
  • What requirements are there for a private perimeter?

Once the above are answered, you have a couple of well documented implementation options. They all operate on the same premise of layering. This allows for segregation of traffic most commonly with a firewall aspect. This combined with UDR can lead to a well designed and secure environment allowing only the network access required. Therefore layering everything that has been discussed already.

Monitoring

In Azure, there are two major tools to help you with this:

  • Azure Network Watcher
  • Azure Security Center

Network Watcher is one of my favourite tools in Azure. Within a couple of minutes, you can gain granular insights into your complex network issues with minimal effort. You can also integrate the output to other Azure services like Monitor and Functions to react to alerts and capture traffic automatically (*notes to self* must blog that).

Security Center, as it does for other infrastructure, offers insights into your network topology and can provide actionable recommendations at scale. Meaning you have a single pane to sanity check your network, regardless of how complex it may be.

If you take the time to understand and implement the above, you’re well on your way to having a secure networking environment. However, every single environment and workload should be treated as unique. The best network security is constantly auditing and reassessing itself. Be proactive to avoid having to be reactive!

As always, get in touch with any questions or to chat about your go-to network security steps.

Joe Carlyle

Azure Policy – Where to Start?

One of the positives of Azure is that it can offer you so many possibilities when it comes to deployment options. However, if you don’t implement the correct governance, this can very quickly become a negative. Historically, Cloud has had difficulties when it comes to sprawl; Azure Policy is a service that will help prevent that.

Azure Policy isn’t only a tool for prevention either. With the right policies, you can audit and enhance your environment in terms of efficiency, security and compliance. This gives you greater insight into your Azure deployment and confidence in your requirements.

Governance in Azure is addressed in many ways; a good place to start for overall strategy is the Azure Architecture Center. It has specific sections on Governance as well as overall design guidelines.

So how does Azure Policy work? At its core, it is an assessment service. You create policies with specific rules and scopes. Once the policies are active, they audit all resources in the included scope for compliance. Policies can range in complexity; you can use the default templates or create a custom one to meet your needs.

There are two core areas when dealing with Azure Policy:

Policy Definition

Every policy must have a definition. The definition contains all the details of the conditions under which it’s enforced. It also has the defined effect that occurs if the conditions are met. Definitions are created using JSON and the full structure is defined here. You will need familiarity with this if you are going to write your own custom policies.

Allowed Locations Policy Example:

{
    "properties": {
        "mode": "all",
        "parameters": {
            "allowedLocations": {
                "type": "array",
                "metadata": {
                    "description": "The list of locations that can be specified when deploying resources",
                    "strongType": "location",
                    "displayName": "Allowed locations"
                },
                "defaultValue": [ "westus2" ]
            }
        },
        "displayName": "Allowed locations",
        "description": "This policy enables you to restrict the locations your organization can specify when deploying resources.",
        "policyRule": {
            "if": {
                "not": {
                    "field": "location",
                    "in": "[parameters('allowedLocations')]"
                }
            },
            "then": {
                "effect": "deny"
            }
        }
    }
}
Policy Assignment

A policy assignment is a policy definition that has been assigned to take place within a specific scope. Assignments range from Management Groups to a single Resource Group. The scope of the assignment refers to all the Resource Groups, Subscriptions, or Management Groups that the Definition is assigned to. Inheritance is enabled for all assignments. Therefore, a policy applied to a resource group is also applied to all resources in that resource group. However, you can include exclusions as a sub-scope of the assignment. For example, a Definition is assigned to a Subscription; all Resource Groups inherit the Definition but you need a single Resource Group excluded. Rather than redo the Assignment for each Resource Group, you can simply exclude it from the Subscription assignment.

Your First Policy

Now that you understand what Azure Policy is, let’s get started with our first policy. For this example, I’m going to prevent Public IP addresses being deployed within a Subscription. This is something I commonly add to IaaS projects that are connected to a local LAN.

Once you’ve logged in to the Azure Portal, make your way to the Azure Policy service, I normally use the search bar as below as it’s quick!

Once you’re on the Overview blade, a handy option for your first time is to click the Getting Started option. This details the steps to take and we’re going to start by browsing default Definitions so click that View Definitions option as below:

This will bring you to the Definitions blade. You will see a lot of built-in policies. To simplify things, click the search bar and enter “not allowed”, this will bring up the Definition we will use, then go ahead and click on the Policy name “Not allowed resource types” as below:

You’re now in the Definition page, where you can see the exact structure in JSON format. We’re going to jump straight to Assignment from here by clicking “Assign” as below:

This will bring you the assignment blade. Our first step is to set a scope. I’m going to go ahead and choose my Subscription and a Resource Group, then click “Select” as below:

We’re going to leave most of the settings as they are, but you can where you can set Exclusions below. We’re going to click the drop down arrow as highlighted:

This opens a huge list of resource providers and types. Thankfully, there is a search bar, so type in “public” to narrow the list and tick the checkbox for Microsoft.Network/publicIPAddresses, then click away from the list as below:

We’re almost there! You can see that publicIPAddresses are now defined as a parameter. So click the blue “Assign” button as below:

Now your policy is assigned, we need to give it a couple of minutes to propagate. Now, when I try to create a Public IP resource in my scoped Resource Group (I’ve used POSH in Cloudshell, but deployment method doesn’t matter) I’m told I cannot as it’s disallowed by policy:

You’ve now successfully applied your first Azure Policy! As you can see, even though this is a single Definition it is still very powerful. Your options to layer Definitions and apply custom ones allow for full control of your environment with very little effort. Azure Policy should be high on your list of priorities for your Azure deployments.

As always, if there are any questions, please get in touch!