Windows Azure PaaS ACLs Are Here!

  • Article

Even though there wasn’t much fanfare about it in the release of the Windows Azure SDK 2.3, the PaaS Access Control List (ACL) feature was finally added after having this feature for Infrastructure as a Service (IaaS) virtual machines since sometime last year. I actually didn’t notice it myself, but I received a curious email from a colleague who read my recent Windows Azure team blog titled Network Isolation Options for Machines in Windows Azure Virtual Networks. In this blog I discussed the implementation of enterprise-level network isolation options for IaaS virtual machines in Azure virtual networks, but noted how at the time of the writing we had network ACLs for IaaS but did not yet have it for PaaS Web or Worker roles. My colleague sent me a link to the Azure Service Configuration Schema page, which you can find here, which clearly indicated that you could specify network ACLs for PaaS applications in the Service Configuration. Thus, I reached out to the product group to verify and, lo and behold, they confirmed that the PaaS ACL feature was indeed now available as of the release of SDK 2.3 on March 31. Hallelujah! Ok, enough celebrating. I will now show you how to take advantage of this feature, which is fairly straightforward, particularly if you have worked with endpoint ACLs for IaaS.  In case you’re wondering, the PaaS ACL functionality is absolutely compatible with the Azure Load Balancer.

As with IaaS ACLs, PaaS ACLs allow you to do the following:

  • Selectively permit or deny incoming traffic based on remote subnet IPv4 address range to a virtual machine input endpoint
  • Blacklist IP addresses
  • Create multiple rules per virtual machine endpoint
  • Specify up to 50 ACL rules per virtual machine endpoint
  • Use rule ordering to ensure the correct set of rules are applied on a given virtual machine endpoint (lowest to highest)
  • Specify an ACL for a specific remote subnet IPv4 address

Network (or Endpoint) ACLs are the key to protecting Web or Worker role public endpoints and controlling that type of access to them. So let’s get started learning how to use them. The first task is to install the Azure SDK 2.3 before getting started in Visual Studio 2013. If you don’t have SDK 2.3 installed, you may not have build problems initially, but at some point you will when you try to package or publish your PaaS application unsuccessfully due to schema issues in your Service Configuration file. I got schema errors when I tried to package the project that only went away once I installed SDK 2.3. So make sure you have SDK 2.3 and let’s get started. Create a new test Cloud project in Visual Studio 2013, as seen below.

image

Go ahead and add a Web role.

image

Choose whatever project template you would like.  I chose the MVC template below.

image

So now we have our project created and we’re good to go. Go ahead and build the project.

image

Let’s first look at the ServiceDefinition.csdef file, as seen below.  By default on a Web role we have an endpoint named “Endpoint1” on port 80.

image

Go ahead and open up the ServiceConfiguration.Cloud.csfg file, as seen below.  We will add the necessary ACL configuration here.

image

From here, you will add in the NetworkConfiguration element with the required ACL information within. Note that you would have already used this to deploy a Web or Worker role if it were participating in a Virtual Network. As seen below, we have a section for Access Controls, creating one ACL with two rules, followed by an Endpoint section that maps the newly created ACL to a specific role and endpoint. This is placed after the role(s) in the service configuration.

image

Let’s take a closer look at the NetworkConfiguration section we added, as seen below:

<NetworkConfiguration>
< AccessControls>
< AccessControl name="test">
<Rule action="permit" description="test" order="100" remoteSubnet="98.189.223.154/32" />
<Rule action="deny" description="test" order="200" remoteSubnet="0.0.0.0./0" />
</AccessControl>
</AccessControls>
< EndpointAcls>
< EndpointAcl role="WebRole1" endPoint="Endpoint1" accessControl="test" />
</EndpointAcls>
< /NetworkConfiguration>

I’m creating an ACL named “test” that will apply to the endpoint we saw above. In that ACL, I have created “permit” and “deny” rules, which will be evaluated by their numerical order. So rule 100 will be evaluated before 200. In the permit rule, I allowed my IP address to access the Web role (note that this must be in CIDR format, so I have to append with a /32 which denotes a subnet range consisting of this one IP address), but in the second deny rule, I’m denying any and all other IP addresses from accessing the Web role (which includes any Azure machines that access the public endpoint). Now look at the EndpointAcls section. You will see that I have first specified our WebRole1 role, our endpoint named “Endpoint1”, and have specified that this combination of Web role and endpoint will use the ACL named “test”. I then publish the project, as seen below. If there are any issues with your rules below, the publishing process will not complete and will let you know what you need to correct.

image

I now try to access the Web role using the browser from my office IP address, and I am successful.

image

I now try to access the Web role from a browser in one of my Azure virtual machines, which fails as it should.

image

Let’s now add a permit rule so this Azure virtual machine can access the Web role as well. Below, I add the permit rule ahead of the deny rule and publish the cloud service again.

image

We then return to the Azure virtual machine, and as you can see below, it now has access to the web application from the Azure virtual machine.

image

We’re all done now. I hope you will enjoy this cool new feature!