Setting an Endpoint ACL on a Windows Azure VM

A few days ago someone asked for help with a Windows Azure Service Management REST API problem. My first thought was that there was likely a problem with the payload, which can be a fairly complex XML document. Rather than look at code I thought it worthwhile to find some application that would allow me to make requests against the API. A quick search brought me to a post by Avkash Chauhan (@avkashchauhan), who has one of my favorite Windows Azure blogs.

Burp Suite

Avkash introduced me to Burp, a web-security product from PortSwigger. I installed the free version of Burp Suite which turned out to be more than sufficient for my needs. Burp is a Java application deployed as a jar. I launched Burp with:

  • java.exe -jar burpsuite_free_v1.5.jar

In the UI, I configured Options/SSL with an X.509 certificate that I had already configured to be used as a Windows Azure management certificate. On the Repeater tab, I configured the target to be:

  • host: management.core.windows.net
  • port: 443
  • Use HTTPS: yes

I was then able to start using the Repeater request pane to create and invoke operations against the Service Management REST API.

Access Control Lists for IaaS Cloud Services

Windows Azure supports access control lists (ACL) for IaaS cloud services (but not yet PaaS cloud services).  This is a significant new feature which allows more flexibility in the workloads that can be deployed into Windows Azure. For example, an enterprise can deploy a cloud service that was accessible only from its network – allowing the benefit of using a public cloud for a proprietary service.

I wanted to investigate the use of access control lists (ACL) with Windows Azure cloud services. It is not yet possible to manage ACLs on the Windows Azure Management Portal. Michael Washam (@MWashamMS) wrote a post showing how to manage an ACL using the Windows Azure PowerShell cmdlets. I was curious to know how to manage an ACL using the Service Management REST API.

Create Hosted Service

The Create Hosted Service operation creates a new empty cloud service – which can subsequently have either PaaS or IaaS deployments added to it.

I added the following to the top of the Request window in the Burp Repeater panel:

MY_SUBSCRIPTION is the GUID that identifies the subscription I want to use, and into which I had previously installed the management certificate.

I used the following request payload:

SERVICE_NAME is the name of the cloud service, and becomes the root of the cloudapp.net DNS name. AFFINITY_GROUP_NAME is the name of an affinity group I had previously created. I could have provided a location instead, but I prefer to use affinity groups since they make allocation easier – and they are also required by virtual networks (which I am not considering here). (Note that Buck Woody (@buckwoody) has a good post showing all the steps needed to deploy a Virtual Machine the right way.) The Label is mandatory and has to be Base-64 encoded.

The Create Hosted Service operation merely reserves the DNS name for the cloud service and pins it to a datacenter or affinity group. It does not deploy any VM and does not lead to any charges.

Create Virtual Machine Deployment

The Create Virtual Machine Deployment creates a deployment and then deploys a new VM into it.

I added the following to the top of a new Request window in the Burp Repeater panel:

MY_SUBSCRIPTION is the GUID Subscription ID and SERVICE_NAME is the name of the cloud service.

I used the following request payload:

The various parameters are as follows:

  • DEPLOYMENT_NAME – name of the deployment
  • COMPUTER_NAME – computer name of the deployed VM
  • PASSWORD – password for the administrator login
  • USER_NAME – username for the administrator login (do not use Administrator)
  • DISK_NAME – name of the OS Disk in the Disk repository (which I also used for the VHD blob name for the OS disk)
  • STORAGE_ACCOUNT – name of the storage account used to store the VHD blob.

A best practice is to use a storage account hosted in the same affinity group as the cloud service.

The Create Virtual Machine Deployment payload primarily comprises a number of ConfigurationSets – for VM provisioning and for endpoint configuration – and then a configuration section for the OS Disk (and any Data Disks). Note that the Name element for the Deployment is used as the DEPLOYMENT_NAME when adding additional VMs into the deployment.

The InputEndpoint configuration, which declares an RDP endpoint where both the public endpoint on the Windows Azure load balancer and the VM itself use port 3389. The novelty in the endpoint configuration is provided by the EndpointAcl section which adds an ACL rule permitting inbound traffic on port 3389 only if it comes from the 209.116.0.0./16 subnet. This subnet should obviously be configured appropriately (Since this particular choice came from Michael Washam’s post he might be the only person able to access my VM.)

The actual type of VM deployed is specified in the SourceImageName element in the OSVirtualHardDisk section. In this case I used a Windows Server 2012 guest OS from May 2013. in the MediaLink element I provided a name for the blob containing the OS Disk VHD, which would otherwise be provided an automatically generated name.

The astute reader may have noticed that the x-ms-version header is set to 2013-06-01 which is not listed on the Service Management Versioning page which was last updated in November 2012. The ability to provide a user name and configure an ACL is not supported in earlier versions of the Service Management API. Unfortunately, the documentation is currently a bit behind the reality. One of the benefits of OSS is that you can view the source – and the Windows Azure PowerShell cmdlets source is available on GitHub.

Add Role

The Add Role operation deploys a new Virtual Machine into an existing deployment.

I added the following to the top of a new Request window in the Burp Repeater panel:

MY_SUBSCRIPTION is the GUID Subscription ID, SERVICE_NAME is the name of the cloud service, and DEPLOYMENT_NAME is the name of the initial deployment into the cloud service.

I used the following request payload:

The various parameters are as follows:

  • SERVICE_NAME – name of the cloud service
  • COMPUTER_NAME – computer name of the deployed VM
  • PASSWORD – password for administrator login
  • USER_NAME – username for administrator login (do not use Administrator)
  • DISK_NAME – name of the OS Disk in the Disk repository (also used for the VHD blob name for the OS disk)
  • STORAGE_ACCOUNT – name of the storage account used to store the VHD blob.

The payload is similar to that for the Create Virtual Machine Deployment operation, except that there is no deployment section to configure. In this example I again applied an ACL to the RDP port. However, this time I used 5589 for the RDP port on the load balancer, instead of 3389, since I wanted to use port-forwarding rather than round-robin load balancing for my RDP ports.

Summary

In this post I provided a few examples of creating VMs in a Windows Azure IaaS cloud service, and showed how easy it was to use Burp to experiment with the payloads for the Windows Azure Service Management REST API.

About these ads

About Neil Mackenzie

Azure Architect at Satory Global.
This entry was posted in Service Management, Virtual Machines and tagged , , , , . Bookmark the permalink.

4 Responses to Setting an Endpoint ACL on a Windows Azure VM

  1. Pingback: Hybrid Cloud Infrastructure Design Considerations | Dan Gorman's Technology News Aggregation

  2. Anite says:

    Hi Neil,

    The post was very much useful for my Azure Management API research work, thank you.

    Anite

  3. Is there anyway to update network ACL for specific end point? It looks like, currently we need to send the entire ConfigurationSet of the VM to update ACL on single end point.

  4. Anjith – I don’t think it is possible to update the network ACL for a specific endpoint without doing a full configuration set update.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s