Tag: Azure

Azure

What is Azure Private Link?

Azure Private Link is a technology designed to provide private connectivity to selected PaaS services, customer-owned and partner offered services.

Private Link allows you to access services over a private endpoint deployed into your virtual network. All traffic privately traverses the Microsoft global backbone, eliminating any exposure to the public internet and increasing security.

With no need for additional network resources such as gateways, NAT devices and public IP address network complexity is also reduced.

There are two key components of Azure Private Link:

  • Private Endpoint – a network interface connected to your virtual network, assigned with a private IP address. It is used to connect privately and securely to a service powered by Azure Private Link or a Private Link Service that you or a partner might own.
  • Private Link Service – your own service, powered by Azure Private Link that runs behind an Azure Standard Load Balancer, enabled for Private Link access. This service can be privately connected with and consumed using Private Endpoints deployed in the consumer’s virtual network.

Benefits of Private Link

  • The service can be used to connect virtual networks with overlapping address spaces
  • Secures access to services over the Microsoft backbone
  • Allows private access to services running in Azure from on-premise or peered networks
  • The service can connect to resources running in other regions offering global reach
  • Ability to enable private link access to your services
  • Supports various PaaS, partner and customer-owned services

An up to date list of services that support Private Link and region availability can be found here.

How do Private Endpoints differ to Service Endpoints?

One key difference between the technologies is that although a Service Endpoint can be restricted to only accept access from a specific virtual network, it is still accessed over a public endpoint. This is in contrast to a Private Endpoint which is created with a private IP.

Service endpoints are also only locked down to a specific service, not a specific resource. Whereas with Private Link, the private endpoint allows more granular access to the specific sub-resource.

Creating a Private Endpoint

Private Link Center is the management tool used for creating and managing Private endpoints and Private link services. In the search bar at the top of the Azure portal type private link, then select the service from the dropdown menu.

To begin creating a private endpoint, select Private endpoints from the left menu. Then from the top ribbon click + Add to open the Create a private endpoint wizard.  

The first thing we need to do is name the endpoint instance and define where it is to be created. Not only geographically in terms of the region but also in which subscription and resource group.

Now we need to define which resource and sub-resource the private endpoint allows access. Selecting a resource in your own directory is done using drop-down menus. Initiating a connection request to a resource in another tenancy is achieved using the resource ID or alias.

In this example, we are configuring the Private Endpoint to provide access to Blob storage. File Shares, Queues or Tables will not inherit the same access permissions. This enables us to be prescriptive and secure resources to a level not possible using Service Endpoints.

The next step is to configure the virtual network and subnet where the endpoint will be deployed.

It is also advised that a private DNS record is created and used when accessing the service via the endpoint. This can either be hosted by your own DNS solution or integrated with an Azure private DNS zone.

To make testing in this example easier, we will choose to integrate with an Azure private DNS zone.

The penultimate step is to define any tags before clicking Review + Create.

Assuming that validation passes successful, the final step is for us to click on Create to kick off the deployment process.

Browsing to the newly created endpoint, we can see from the overview page details such as its network interface, the virtual network and subnet its connected, FQDN and assigned private IP address (10.0.0.5).

Jumping to the storage account the endpoint was linked with and expand the Firewall and virtual network tab. We see that the only access allowed is for trusted Microsft services.

Switching to the Private endpoint connections tab, we should be able to see listed the private endpoint that’s just been created. If configured correctly, the connection state should appear as Approved.  

Now everything has been configured, we can go ahead and test access to the storage account is only allowed through our private endpoint.

From a virtual machine connected to the same virtual network, open a PowerShell console and enter nslookup dns.name.of.private.endpoint. The command-line utility outputs DNS details including the IP address registered with the DNS name. In our example, the IP address output matches the private address assigned to our endpoint.

Another way to test the endpoint is working as expected is by using Azure Storage Explorer that can be downloaded here.

Open Azure Storage Explorer, right-click Storage Accounts and then select Connect to Azure storage from the popup menu. Enter the connection string that can be copied from the Access Key blade of the storage account and then click on Connect.

We now have access to blob containers and the ability to create, browse, edit and delete.

When associating a resource and sub-resources to the endpoint, we selected Blob within the storage account. Due to the increased granularity that Private Endpoints offer when attempting to browses File Shares, Queues or Tables, access fails as expected.

For completeness, let’s run Azure Storage Explorer on a machine that’s not connected to the same virtual network. Now when attempting to connect to the storage account, this action fails with the following error message.

To learn more about Azure Private Link, head over to Microsoft docs: https://docs.microsoft.com/en-gb/azure/private-link/

this photo by Evgeni Tcherkasski on Unsplash
Azure

The power of Azure Lighthouse

One of the biggest challenges facing partners offering support around Azure is how best to permission access across multiple customer tenancies. Specifically how to assign the correct level of permissions to users that require them and how to monitor the users once access is enabled.

Another problem that goes hand in hand with this is how to centrally manage and monitor large volumes of resources, spread across various customers, whilst using a single shared set of tools and dashboards.

Until Azure Lighthouse, access for support would often be configured in one of the following ways:

  • Dedicated accounts within the customer tenancy (Azure AD) for partners to use for support
  • Partner accounts added as guests to every customer tenancy using Azure B2B

Contacting customers every time the partner takes on a new member of the support team. Having permissions assigned to individual guest accounts rather than security groups. Support staff switching constantly between directories. Are just some of the problems that highlight that neither option is suited to offering support at scale.

CSP partner accounts with enough permissions can use Administer-on-Behalf-Of (AOBO) to offer support. AOBO offers access to customer subscriptions at an administrator level. This method of access is generally a concern to both customers and partners. Would you really want a backup admin having full access to all services?

Azure Lighthouse uses delegated resource management to project resources from customer Azure environments, into a single partner tenancy. Delegated partner accounts can then view resources from all customer tenancies within a single portal for centralised management.

At a high level, security groups are created in the partner’s tenant, based on support roles. Users are then assigned to those security groups. In the customer’s tenancy, the required amount of permissions can then be assigned to these security groups using RBAC roles. Delegate access for these groups can then be assigned at the subscription or resource group level.

Benefits include:

  • Resources spread across multiple customers can be managed from a single portal
  • Single instances of native Azure services can be used, for example, Service Health, Azure Advisor, Azure Monitor, Security Center (A full list of enhanced services can be found here)
  • Governance can be applied centrally across all of your tenants for consistency
  • Share dashboards can be populated with information from multi-customers
  • Azure security across the entire customer base is easily visible from one location
  • More opportunity for unified automation and reporting using scripting and APIs

Ultimately, this should enable easier management at scale across your entire customer base. No more switching directories!

Delegating access or “onboarding” can be done in one of two way.

  1. Deploying an ARM template into the client’s subscription to enable delegation management as defined within the template
  2. Customer offer that has been previously published to the Marketplace.

NOTE: It is not currently possible to do this via the portal, Azure CLI or cloud shell.

Using an ARM template to Onboard

Microsoft has made available various sample templates that can be found in this Github Repository. In the following example, I’m going to be onboarding a customer at the subscription level. I’ve downloaded the template that best fits this scenario and now need to modify it to represent the offer.

Each template comes with a parameters file which needs to be populated with the following offer information:

  • mspOfferName: Name describing the offer
  • mspOfferDescription: Description of the offering
  • managedByTenantId: Partner tenant ID
  • Authorizations:  Description of each entity (user/group/service principal) from the partner tenant being granted access to the customer deployment

Having gathered the information above, I can populate the parameters.json file.

Now that I have a template for the offer, I need to deploy the template in the customer’s tenant. Although I’m running it at the subscription level, if the customer has multiple subscriptions, this would need to be repeated for each.

I’m going to use PowerShell to kick off the deployment but it could as easily be done with Azure CLI.

Once the deployment has run, I can go ahead and confirm the delegated link has been properly established.

Logged in as the customer I can browse to the Service providers blade, click on Delegations and then select the respective offering to view what roles have been assigned to the partner.

The image below shows that the Tier 1 Support and Tier 2 Support groups have been successfully assigned with the roles outlined in the parameters.json file passed to the deployment.

Having seen how this appears to the customer, let’s now switch and take a look from the service provider perspective.

Once signed in to the Azure portal as the supporting partner, I browse to the My customers blade. From here I can see the customers who I have delegated access to manage, the role assignments and subscriptions or resources groups that the partner has permissions over.

If I switch to the Virtual machines blade, I can now view virtual machines provisioned across all of my customers from the single window. This shared experience is similar across all Azure services that are now integrated with Azure Lighthouse, for example, Azure Advisor, Security Center, etc.

Removing delegation

If support is no longer required by the customer, the offering or delegation can simply be removed. Browse to the Service provider blade within the portal, select the offering or delegation and then click on the Delete button.

As you would expect, it’s also possible to remove the delegation using PowerShell or Azure CLI as outlined in this Microsoft article. https://docs.microsoft.com/en-us/azure/lighthouse/how-to/onboard-customer#remove-access-to-a-delegation

Recommendations

When planning to integrate Azure Lighthouse for the first time, there are a couple of security recommendations and general best practices that are worth keeping in mind.

  • Multi-Factor Authentication should be enforced
  • Use the least privilege principle when assigning permissions
  • Consider using Privileged Identity Management (PIM)
  • Where possible try not to assign access to entire subscriptions unless required
  • Use Azure Policy to enforce standards across all of your customers
  • Include a user with the Managed Services Registration Assignment Delete Role
  • Any user who needs to view the My customer’s page in the Azure portal has the Reader role (or another built-in role which includes Reader access).

For a more in-depth look into the Azure Lighthouse service and what it offers, take a look at Microsoft docs: https://docs.microsoft.com/en-us/azure/lighthouse/overview

Azure

Azure Bastion – End of the Jumpbox?

A common headache facing customers migrating workloads to the public cloud is deciding how best to provide secure remote access to Windows and Linux VMs.

This is normally achieved using Remote Desktop Protocol (RDP) and Secure Shell (SSH) sessions connected over public IP addresses, either directly assigned to individual hosts or a shared Jumpbox. Another option is to only allow remote access from a trusted private network over an inter-site connection such as a site-to-site VPN or ExpressRoute.

Either way, enterprises are forced to compromise security or impact the user’s experience, limiting where they can access from or by forcing them to traverse numerous network levels to gain access to the required service.

The problem with adding public endpoints directly to a host or even to a Jumpbox is that it makes them susceptible to malicious attacks. Amongst other things, it’s possible to use port scanning to discover the public IP and then brute force attacks to compromise the machine.

In efforts to reduce risk, security features such as MFA, Just in Time Access (JiT) and ACL can be implemented, but this can be difficult to manage and not totally infallible.

Azure Bastion

In answer to this problem, Microsoft has released in public preview the Azure Bastion service. Bastion is a new managed PaaS service that provides seamless RDP and SSH connectivity for your VMs over Secure Socket Layer (SSL). The service does this without having to configure each VM with its own public endpoint.

Key features available during the public preview include:

  • RDP and SSH from the Azure portal: Initiate RDP and SSH sessions directly in the Azure portal with a single-click seamless experience
  • Remote session over SSL and firewall traversal for RDP/SSH: HTML5 based web clients are automatically streamed to your local device providing the RDP/SSH session over SSL on port 443
  • No public IP required on Azure Virtual Machines: Azure Bastion opens the RDP/SSH connection to your Azure virtual machine using a private IP, limiting exposure of your infrastructure to the public Internet
  • Simplified secure rules management: Simple one-time configuration of Network Security Groups (NSGs) to allow RDP/SSH from only Azure Bastion
  • Increased protection against port scanning: The limited exposure of virtual machines to the public Internet will help protect against threats, such as external port scanning
  • Hardening in one place to protect against zero-day exploits: Azure Bastion is a managed service maintained by Microsoft. It’s continuously hardened by automatically patching and keeping up to date against known vulnerabilities.

Is it ready for the Enterprise customer?

Whether VNets have been implemented due to project segmentation, business unit, location and so on, it’s very rare to encounter an enterprise customer that does not have to control VMs sprawled over multiple VNets.

At the time of writing, limitations of the Bastion service mean that it does not yet support VNet peering. It is also only possible to deploy a Bastion host within a single VNet.

The service roadmap highlights plans to add great capabilities like Azure AD integration, Seamless Single-Sign-on and Multi-Factor Authentication to the service. Further research of various blogs and community chat suggest that support for peered VNets is another feature also being explored.

For now, when trying to access VMs attached to VNets in unsupported regions or for customers that don’t wish to deploy a Bastion host for each VNet, the workaround is to simply adopt a hub-spoke network architecture. The Bastion host sits in the hub VNet which it shares with a Jumpbox, in essence replacing the need for a secure VPN connection. It’s then from the Jumpbox that remote access can be gained across the network peerings.

Before configuring the service, there are a couple of things with the public preview to bear in mind.

  • During the public preview, the service can only be deployed from the Azure Marketplace when accessed through the Bastion preview portal: https://aka.ms/BastionHost
  • The service requires a dedicated subnet called AzureBastionSubnet of at least /27 in size
  • The preview is limited to West US, East US, West Europe, South Central US, Australia East and Japan East
  • Supported browsers are limited to Microsoft Edge (Windows), Google Chrome (Windows, Mac) and Microsoft Edge Chromium (Windows, Mac).

Configuring a Bastion Host

1. Log in to the Bastion preview portal and from the homepage, click on +Create a resource.

2. On the New page, type Bastion in the Search the Marketplace box and then press Enter.

3. Select the Bastion (preview) offering, then click on Create.

4. Fill in the Create a bastion web form and finally click Review + create

Connecting to a VM

1. Now the service has been created, simply choose a VM and click on the Connect button as normal.

2. A new BASTION tab is now active on the Connect to virtual machine blade. Select the tab, fill in the username and password details before finally clicking Connect.

The following image shows the RDP session running within the boundaries of the web browser and the Azure portal.

The user experience is the same for SSH sessions.

Conclusion

With console access lacking in Azure and many planned features on the road map, for the most part, I’m really excited about the service. Whether it completely replaces customers needs for a Jumpbox or just offers an alternative to a secure connection to a Jumpbox in place of the normal VPN or ExpressRoute offering, it’s definitely a big step in the right direction.

The one slight concern I have is that Windows or Linux admins who have previously only had access to the client OS and may know little or nothing about Azure, are suddenly going to be exposed to the Azure portal rather than accessing the client directly. Making sure the portal is locked down and security features are configured and in place will be essential. I’m sure though as the service matures, it’s likely that improvements will address this.

To answer the question above, is the Jumpbox dead? My gut feeling is that for now, probably not. In the not too distant future, well it’s looking possible.

To learn more about the Azure Bastion service, head over to Microsoft docs: https://docs.microsoft.com/en-gb/azure/bastion/bastion-overview

Azure

Azure: Installing the Microsoft Antimalware and Log Analytics extensions on VM Scale Sets

I’ve been engaged with a customer over the the past few months that hosts multiple virtual machine scale sets across their Azure estate. For the most part, the scale sets are used to offer public facing web services.

Using scale sets allows them to provide redundancy and improved performance by distributing their web applications across multiple VM instances. Azure load balancers then sit above the scale sets distributing traffic.

Scale sets also give them the ability to scale the number of VM instances as required. Either manually or automatically using predefined auto scale rules based on resource usage like CPU, memory demand or network traffic. 

As with any virtual machine, it is important to protect the scale set VM instances by installing the latest security updates and running Antimalware to maintain a strong security posture. For scale sets running Windows 2016 VM instances , Windows defender is built into the OS but for Windows 2012 R2 this is something that needs to be managed.

The Azure marketplace offers many third party security extensions that can be implemented. But in this article I’m going to concentrate on the following two and how to go about installing them.

  • Microsoft Antimalware
  • Log Analytics

Installing the Microsoft Antimalware extension 

One way to install the Microsoft Antimalware extension is by browsing to the Extensions blade of the scale set, clicking on the + Add button and then selecting the extension from the popup list.

It’s worth noting that not all extensions are available via the portal so I tend to use the following PowerShell snippet which can be found on the Azure virtual machine scale set FAQ page. I have included the link for additional information.

https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-faq#how-do-i-turn-on-antimalware-in-my-virtual-machine-scale-set

Once the extension has been installed on the scale set reference image, the image then needs to be rolled out to all of the running VM instances. The simplest way I have found to do this is through the portal.

Browse to the Instances blade of the scale set and then simply select which instances need upgrading. Finally click the Upgrade button to upgrade them to the latest OS image. 

NOTE: If all instances are upgraded at once, the scale set will be offline during the upgrade process.  

Installing the Log Analytics extension

Having installed the chosen Antimalware extension, it’s important to have some visibility into the health of the scale set. Integration of scale sets into services such as Security Center and Log Analytics are still quite limited but viewing the logs that are produced can offer some invaluable insight.

Before we go ahead and install the Log Analytics extension, we first need to make note of the Log Analytics Workspace ID and one of the Workspace Keys. This can be found in a couple of ways, arguably the easiest is by browsing to the Advanced Settings blade of the chosen Log Analytics workspace.

Unlike the Antimalware extension, the Log Analytics extension does not appear in the list accessible through the portal and needs to be installed using either PowerShell or Azure CLI. 

The following script created by Tim Omta is the method I have tended to use. 

https://blogs.msdn.microsoft.com/timomta/2018/04/09/how-to-add-the-oms-client-to-a-vm-scale-set/

Alternatively the same things can be achieved by the following single line of Azure CLI

https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-faq#is-it-possible-to-integrate-scale-sets-with-azure-log-analytics

In the same way the VM instances required upgrading after the reference image had been updated with the Antimalware extension, the same is true for the Log Analytics extension.

In most production environments, I would recommend installing both extensions before upgrading the scale set once from the updated reference image.  

Deleting a virtual machine scale set extension

Having stepped through installing both extensions, it’s worth covering off how to remove them. Even though it’s not possible to install both via the portal, it is possible to remove them manually through the GUI.

For completeness, the following PowerShell script can also be used to remove extensions from VM scale sets.  

As a final note, I’m aware that over the coming months the integration between Azure Security Center and VM Scale Sets is likely to improve. As things change, I plan to feedback on the key improvements.

Active Directory

Azure: Azure Active Directory Business-to-Business (B2B)

As organisations move to the cloud, many try to adopt the same administrative processes and governance framework as they are comfortable with on-premises.

Most system administrators at one point or another have had the need to grant third party access to a businesses resource for either support or collaboration reasons. This probably involved creating a new account within the local AD and then permissioning the application using the newly created account.

In the past that might have been acceptable but not only is there now an extra account to manage for someone that the business has limited visibility of but the third party user has another set of account credentials to remember.

copyright Microsoft

With Azure AD B2B collaboration its possible to invite users from other organisations to access your resources, whilst using their own credentials.

Permissions can be assigned for guest users without the need to manage their accounts. The third party user is happy as they don’t have extra account details to remember and any account management such as password complexity or knowing when the user leaves the company and should have their account disabled is left in the hands of the users own organisation.

Key benefits:

  • Partners use their own credentials
  • No requirement for partners to use Azure AD
  • No external directories or complex set-up required
  • Provide access to any corporate app or data, while applying sophisticated, Azure AD-powered authorisation policies
  • No external account or password management

NOTE: If the guest user doesn’t have a Microsoft account or an Azure AD account, one is created for them when they redeem their invitation.

Manually adding B2B collaboration users using the portal

Manually adding a collaborated user is quite simple. Login in to the Azure portal and browse to the Users blade of Azure AD. From the top ribbon, select New guest user.

In the next blade, enter the users email address and if you wish a personnel message to be sent as part of the email invite. Finally click on the Invite button.

Once invited, the collaborated user will receive a welcome email containing any personnel message included in the original invite. Permissions can then be assigned in the same way as for any other user.

Should the guest user not receive their welcome invite, it is possible to resend. To do this browse to the users profile and click on the Resend Invitation button.

Using PowerShell to bulk invite users

Adding a single guest user through the postal is fine. For larger numbers it’s possible to use PowerShell to bulk-invite users based on the contents of a .CSV file. 

The first step is to create a .CSV file with the users names and email addresses. This should be in the following format.

       Name                                   InvitedUserEmailAddress
       John Smith                           jsmith@blueclouds.com
       Emma White                        ewhite@blueclouds.com

The next step is to import the details from the .CSV into Azure AD. The following Microsoft example script gives a good idea of how that can be achieved.

Licensing

Users invited as guests into your Azure AD can automatically make use of the capabilities that Azure AD Free edition offers. If you wish them to make use of a paid feature i.e. MFA then that user must be licensed. B2B collaboration guest users can be licensed in either of the following two ways.

  • The owner of the tenancy the guest user has been invited into has available paid licenses. These licenses can be used to cover the B2B users at a ratio of 5.1
  • The B2B guest user already has a paid Azure AD license assigned by their own organisation. 

For example: Inviting ten B2B collaboration guest users to access one of your LOB applications which is access using Azure MFA would require two Azure AD Premium P1 or P2 licences to be available.

NOTE: It is not currently possible to assign licenses directly to the B2B collaboration users. Licensing is automatically calculated and reported based on the 5:1 rule.

For more information on Azure AD B2B licensing checkout the following article https://docs.microsoft.com/en-us/azure/active-directory/b2b/licensing-guidance

Azure

Azure: Cost Optimisation – Enabling Hybrid Use Benefit (HUB)

I used to spend most of my time discussing with customers the benefits of moving business services to the cloud. Most no longer need to be convinced, in fact many have already dabbled with services and instead are looking for guidance on how to enforce governance and better manage costs.

Cost optimisation in Azure is a large topic and by adopting a number of technologies and processes it is possible to make rewarding cost savings.

Along with investing in reserved instances one of the biggest cost savers for Windows VMs can be make through the use of the Microsoft Hybrid Use Benefit (HUB).

What is Hybrid Use Benefit (HUB)

The Azure Hybrid Benefit helps you get more value from your Windows Server licences and save up to 40 per cent* on virtual machines. You can use the benefit with Windows Server Data Centre and Standard edition licences covered with Software Assurance or Windows Server Subscriptions. Depending on the edition, you can convert or re-use your licences to run Windows Server virtual machines in Azure and pay a lower base compute rate (Linux virtual machine rates).

* Actual savings may vary based on region, instance type or usage.

Paragraph from HUB FAQ

It’s worth noting that licensing entitlement is different between Windows Server Datacentre and Windows Server Standard editions.

  • Windows Server Datacentre with Software Assurance allows you to use the license on-premises and simultaneously in Azure
  • Windows Server Standard with Software Assurance allows you to use the license on-premises or in Azure

With both editions, each two-processor licence or each set of 16-core licences are entitled to two instances of up to 8 cores, or one instance of up to 16 cores.

Enabling Hybrid Use Benefit 

Hybrid Use Benefit can be enabled when deploying a Windows VM either from the marketplace, as part of an ARM template or PowerShell script. It can also be enabled post deployment.

I’ve focused on PowerShell and outlined below are a few commands that might be of use. Its also worth mentioning that its possible to do the majority of this through the portal or Azure CLI.

Dependencies

The first thing to do is make sure that you have the Azure PowerShell module installed.

If you already have the module installed, I would suggest checking that you are running the latest version. This can be done by running the following command.

How do I know if Hybrid Use Benefit is enabled on a VM?

Its possible to check if Hybrid Use Benefit is enabled on a machine by looking at the virtual machines blade in the Azure Portal.

Browse to the virtual machine blade, from the top ribbon select Edit columns and then add Azure Hybrid Benefit to the selected columns list.

Once the Hybrid Use Benefit column has been added to the blade view, its easy to scan down and see which machines have been enabled or not.


As you would expect, its also straight forward to pull back the same information across all machines using a simple PowerShell command.

The following PowerShell snippet outputs just the Windows machines that HUB is enabled for and ignores the rest.

This screenshot is of the above PowerShell snippet being run from within Azure Cloud Shell.

Converting an already deployed VM

For Windows machines deployed with Pay-as-you-go licensing, its a simple process to convert them to Hybrid Use Benefit. As before this can either be done from within the Azure portal or using a simple PowerShell command such as the one below.

NOTE: Changing the license type only updates the machines metadata flag. This means there is no downtime or service interruption to the system. 

Converting back to Pay-as-you-go Licensing

Reverting the VM to Pay-as-you-go licensing is done using the same command. This time, the licensing type needs to be changed to None before running.

Change the license type of every Windows VM in the subscription

Updating the license type of multiple VMs one at a time can be very time consuming. To speed things up, I would recommend reviewing the following script created by Neil Bird a Premier Field Engineer at Microsoft.

The script not only allows you to change the licensing type across all Windows VMs but it also offers a Simulate Mode where no changes are actually made. Instead, LOG and CSV export files are generated to show what changes the script would make if ran in Update Mode.

https://gallery.technet.microsoft.com/Azure-Enable-Hybrid-Use-1977e089

 

For more details checkout the Microsoft document site https://azure.microsoft.com/en-gb/pricing/hybrid-benefit/

Application Gateway

Azure: Application Gateway https to https redirect

One key feature of the Application Gateway service is its support for Secure Sockets Layer (SSL) termination. This feature means that the overhead of encrypting and decrypting traffic can be offloaded to the gateway, rather than have this impact performance on the backend web server.

This does however mean that communication between the application gateway and the backend web server is unencrypted which in some cases, perhaps due to security or compliance requirements, may not be acceptable. For those situations, the application gateway also fully supports end to end SSL encryption.

For the purpose of this article, the assumption has been made that SSL termination is enabled on the gateway. Standard web traffic should now be redirected to the https listener so that web requests don’t just fail when they are unable to traverse the application gateway over https.

Enabling https to https redirection

When an application gateway is configured with SSL termination, a routing rule is used to redirect https traffic to the https listener. The remainder of this article steps through configuring this routing rule.

Assumptions

The following assumptions have been made:

  • https and https listeners already exist
  • Azure PowerShell module version 3.6 or later is installed.

NOTE: To check what version of PowerShell is installed and for help on upgrading it if required, see Install Azure PowerShell module.

Configuring the routing rule

1. The first thing we need to do is get the application gateway object and store it as a variable

2. Get the existing https listener

3. Get the existing https listener

4. Now create a redirection configuration using a permanent redirect and targeting the existing listener

5. Get the newly created redirect configuration

6. Add a new rule to handle the redirect from the https listener

7. Finally, update the application gateway

To make it a little simpler to copy all steps, they have been combined into one script below. A copy of the file can also be downloaded from my GitHub repository app-gateway-https-https-redirect.ps1

More information about the application gateway and all of its features can be found by following the link to Microsoft document repository – https://docs.microsoft.com/en-us/azure/application-gateway/

Automation

Azure: Using Azure Event Grid to trigger Automation Runbooks

A relatively new service that so far has been somewhat overlooked by many of the customers I have spoken with, is the Azure Event Grid. Event Grid closely resembles Amazons Simple Notification Service, albeit under the hood they function a little differently.

With the cloud becoming increasingly event-driven, Event Grid has been labelled as the event messaging service for the modern application.

Essentially, the service can be used to intelligently route events between event publishers and event subscribers. Using Event Grid, events generated by Azure resources can be subscribed to, in turn used to trigger a reaction using one of the serverless technologies like Azure Automation or Logic Apps.

The Microsoft graphic above gives a basic representation of the service, including some of the event sources and event handlers available at the time of writing. As with everything in Azure, Microsoft are continuously working behinds the scenes to develop the service further. As such, other event sources and event handlers are planned for later this year include Azure Active Directory, API Management, Azure Data Lake Store, Azure Cosmos DB, Azure Data Factory, and Storage Queues.

For the latest event sources and event handlers refer to the following Microsoft blog
https://docs.microsoft.com/en-gb/azure/event-grid/overview#event-sources

Use cases

Event Grid can be used to develop Serverless Application Architectures, Ops Automation and Application Integration with Ops Automation being the focus of this article.

To give a few examples of how the service might be used for Ops Automation:

  • Notifying when Azure resources have been created or changed i.e. Virtual Machines or SQL Databases
  • Converting Virtual Machines deployed using unmanaged disks into managed disk machines
  • Assigning resource tags to resources when deployed to specific Resource Groups.

Using this style of serverless architecture, opens the door to designing solutions with almost limitless functionality.

Using Event Grid

The remainder of this article steps through implementing a very basic Event Grid deployment. In the demo, every time a Virtual Machine is deployed to a specific Resource Group, Event Grid, using a Webhook, triggers an automation Runbook which sends out email notification.

Assumptions

The following assumptions have been made:

  • Azure Automation Account has been created
  • Runbook with the required workflow has already been created and published.


The first thing to do is add a Webhook to the Runbook that will be triggered on an event being raised. To do this, browse to the Runbook and from its blade select Webhooks.


Next click + Add Webhook.


Give the Webhook a name and copy its endpoint URL to one side to be used later. Then Click OK to move onto configuring parameters and run settings for the selected Runbook. In my case, I can leave all parameters as default for the purpose of the demo.

Finally go ahead and create the Webhook by clicking the Create button.


The next step is to plumb all the components together, which is done by configuring an Event Grid subscription.

Selecting the Automation Account in which the Runbook we need to trigger is associated, click on Event Grid from the blade of the Automation Accounts overview page.


Click on the + Event Subscription button at the top of the Event Grid window.


Start by giving the subscription a name and then fill in the remaining options. For the purpose of this article, the following configuration was used:

  • Topic Type – Azure Subscriptions
  • Subscribe to all event types – unchecked
  • Event Topics – Resource Write Success selected only
  • Subscriber Endpoint – Webhook URL made note of earlier
  • Prefix Filter – Location of where the new VMs will be created.
    /subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.Compute/virtualMachines

Once all required options have been completed, finally click Create to deploy the subscription.


Now it’s time to test!

Go ahead and create a new Virtual Machine in the Resource Group that was specified in the Event Grid subscription. In my case Production-VMs.


If everything has gone to plan, on completion, a Resource Write Success event was raised which the Event Grid subscription successfully intercepted. This in turn used the Webhook to trigger the Automation Runbook to send out email notification.


In my case the notification was very basic and prepopulated with static content but this could be updated to include Virtual Machine names and other more useful information.

As you can appreciate, this is a very basic example of what the service is capable of when in reality, the sky is the limit!

Pricing

Event Grid price model is based on operation performed, so you only pay for what you use as with many other of the Azure services. Operations can include ingress events, advanced match, delivery attempt and management calls.

  • The first 100,000 operations per month are free
  • Price per million operations £0.448 *

* Based on West Europe pricing on the 6th April 2018

The only thing to keep in mind is that although more regions will no doubt come online soon. At the time of writing, Event Grid is only available in the following regions:

West US, East US, West US 2, East US 2, West Central US, Central US, West Europe, North Europe, Southeast Asia, and East Asia.

SLA

Guaranteed 99.99% or greater uptime.

For more information on Event Grid checkout the following Microsoft Blog https://docs.microsoft.com/en-gb/azure/event-grid/

Azure

Azure: Using Service Health to alert about planned maintenance

Microsoft periodically perform updates to improve the reliability, performance, and security of their global cloud platform. Most of the updates that Microsoft apply have no impact on the hosted virtual machines and go unnoticed. However, there are some instances where the running virtual machines are affected, the most recent example of this being the Spectre and Meltdown CPU vulnerability.

When an update like this is applied, depending if the maintenance requires a rebooted or not, it can affect running virtual machines in one of two ways:

  • In-place migration – During an in-place migration the affected Azure virtual machine is paused (typically for 30 seconds or less) to preserve memory in RAM while the host environment is updated. Once the upgrade is complete the virtual machine is resumed and the system clocks synchronised
  • Maintenance requiring a reboot – During reboot maintenance, the virtual machine is moved to a node that has already been patched and then powered back on.

Under normal circumstances, when a virtual machine needs rebooting, you are notified in advance and given the option to start the maintenance at a preferred time during the initial self-service window. If the self-service window is missed, the scheduled maintenance window begins and it is no longer possible to manage the process.

NOTE: Datacentre in paired regions will not have maintenance performed at the same time; therefore, workloads balanced across paired regions will be unaffected.

Azure Service Health


Azure Service Health (in public preview at the time of writing) can be used to view problems with Azure services that may impact any of your cloud services. Service Health monitors three types of health event:

  • Service issues – Azure services that are currently experiencing problems
  • Planned maintenance – Any known future maintenance that may affect the availability of your services
  • Health advisories – Changes in services, for example, deprecated features or exceeded quota usage.

Using the Service Heath service, it is not only possible to view in one location any service problems but also setup Health alerts which are a vast improvement on the basic email notification. Service alerts can be configured to:

  • Send Email/SMS/Push/Voice notification
  • Send Webhooks to third party app i.e. ServiceNow or Azure Logic App
  • Send an IT Service Management Ticket
  • Trigger an Automation Runbook.

Creating planned maintenance alerts using Azure Service Health

To demonstrate the alerting capabilities of the Health Service, the rest of this article steps through the process involved in configuring a basic email alert to notify of any planned maintenance events.

1. Login into the Azure portal and select Service Health.
2. Select Health alerts followed by + Create service health alert from the top of the window on the right.


3. In the Edit Alert blade, give the alert a Name, Description, check the subscription is correct and choose a resource group.


4. The next step is to work through the Criteria section choosing which services, regions and types of event alerts should be monitored. For the purpose of this article all services and regions have been checked but only planned maintenance events.


5. Select or create an Action group. (An Action group is a group of actions to be taken, should an event be logged.)


6. Configure the actions to be taken. We are only configuring an email alert, so we first name the action, then chose Email/SMS/Push/Voice from the drop down list.


7. Enter the name and email address of the person who will be sent the notification. Then finally click OK twice to add the activity log alert.


It should now be possible to see the newly created alert, listed in the Health alerts blade.


Should action groups need to be edited or new actions added, either click on Edit this action group from the lower half of the Health alerts blade or browse to the Monitor service and select the Action groups tab.

For more details checkout the Microsoft document site https://docs.microsoft.com/en-us/azure/service-health/service-health-overview