Summary: Learn how to use Windows PowerShell to create ACLs for Windows Azure endpoints.
Microsoft Scripting Guy, Ed Wilson, is here. Windows networking engineer, James Kehr, is back with us today to share more Windows Azure goodies. Now here’s James…
Imagine this if you will. I’ve written two rather large blog posts about creating endpoints and ACLs with Windows PowerShell in Windows Azure. Each one was long enough to be considered a good size short story in the literary world. If you would like a frame of reference for this post, here they are:
And then I see it. An update to the Windows Azure PowerShell module released the day before my deadline. Do I ignore it, or do I install it and make sure my script still works? Better safe than sorry…update goes on…
Test endpoint script. All good.
Test ACL script. Works great.
Test load balanced endpoint script. No problems found.
Awesome. All is well. “Hmmm,” I thought. “Hmmm,” I said aloud. “I wonder if they fixed the -VM parameter?” Sure enough, it works. Now comes the dilemma. Push back the publishing date and rewrite, or move on as planned? The script does work after all. What to do, what to do?
At this point, a committee was called to order with five executives, sixteen directors, and forty-two middle managers. After six hours of deliberations, a sub-committee of eighty-four Windows PowerShell and Windows Azure experts was created. The sub-committee then formed an action plan, signed in triplicate, carbon copied, emailed, responded to, and replied to all. This generated a massive email storm, which was lost to drive corruption, restored, rechecked, and brought back to the committee. They convened an independent review and gave recommendations to the sub-committee, which was waiting for a secondary audit from Vogon Consulting services, who gave a recommendation to the committee to rewrite the blog. The committee then ignored the recommendations and ordered the blog posts be published as is.
Or at least that’s how some people on the Interwebz might think it happened. In reality this is closer to what really happened…
Ed: Hey James, why don’t you just write a follow-up post with the shortened script?
Me: Sure.
Ed: Cool, thanks.
Which brings us to this post—the unexpected Part 3.
ACLs done quicker
This post focuses on making the endpoint and ACL script from Parts 1 and 2 shorter. Specifically how the fixed -VM parameter works and how it can make your script a bit more efficient. I will forego the technical nitty gritty. If you find yourself lost because of this omission, please read Part 1 and Part 2, which is where you will find the technical and script deep dives.
The first thing you need to do is get the newest Windows Azure PowerShell module. For this script to work you need at least the August 2013 update. The latest standalone installer can be found at: WindowsAzure/azure-sdk-tools.
This is also a great resource to see what cmdlets have been added since the previous update. This is important to know because the Windows Azure PowerShell module is in constant change, and features that weren’t there last month could very well be there this month. As the Windows Azure features settle and the Windows Azure PowerShell module matures, it won’t change as rapidly, but for now expect change.
The post-August 2013 Windows Azure PowerShell module script can be changed to this:
# create an endpoint for HTTP
$avm = Get-AzureVM -ServiceName Web01
# create a new ACL
$acl = New-AzureAclConfig
# add some rules to the ACL
Set-AzureAclConfig -AddRule -ACL $acl -Order 0 -Action Permit -RemoteSubnet "1.2.3.4/31" -Description "Allow App01"
Set-AzureAclConfig -AddRule -ACL $acl -Order 1 -Action Permit -RemoteSubnet "172.16.0.0/29" -Description "Allow corp proxies"
Set-AzureAclConfig -AddRule -ACL $acl -Order 2 -Action Deny -RemoteSubnet "0.0.0.0/0" -Description "DenyAll"
# create endpoint
Add-AzureEndpoint -Name "HTTP" -VM $avm -ACL $acl -Protocol tcp -PublicPort 80 -LocalPort 80 | Update-AzureVM
The big advantage to this technique is that you can make all your changes offline, and then push them to Windows Azure all at once. The AzureVM variable ($avm) stores all your changes. When you are done making changes, simply pipe $avm to Update-AzureVM. Or do what I did, and pipe your final change to Update-AzureVM.
The fixed -VM parameter also means that you can perform other endpoint and ACL commands without doing a lot of pipeline work.
# get HTTP endpoint
Get-AzureEndpoint -VM $avm -Name http
# get HTTP ACLs
Get-AzureAclConfig -vm $avm -EndpointName http
# remove the HTTP endpoint
Remove-AzureEndpoint -vm $avm -Name HTTP | Update-AzureVM
When you run commands this way, please remember that the changes are made to the AzureVMobject and not to the virtual machine. Because of this these cmdlets, using -VM will reflect the object, and not what’s in Windows Azure. If you need to see what’s in Windows Azure, using the older pipeline technique is still the best:
Get-AzureVM -ServiceName Web01 | Get-AzureAclConfig -EndpointName http
A little love for load-balanced endpoints
There is one gotcha with the -VM parameter that I would like to mention. It currently does not support arrays of AzureVM objects. This means the script for load-balanced endpoints is, at this time, almost unchanged. When you create a new load-balanced endpoint, you can shorten the script a bit, but you must still use the pipeline. The only real difference is that you can now create a variable that contains an array of Windows Azure VM objects. This allows you to queue several changes and then pipe the variable to the update command.
# get VMs in LB set
$avm = Get-AzureVM -ServiceName jak-az-12r2-tst
# create ACL
$acl = New-AzureAclConfig
Set-AzureAclConfig -AddRule -ACL $acl -Order 0 -Action Permit -RemoteSubnet "1.2.3.4/31" -Description "Allow App servers"
Set-AzureAclConfig -AddRule -ACL $acl -Order 1 -Action Permit -RemoteSubnet "172.16.0.0/29" -Description "Allow corp proxies"
Set-AzureAclConfig -AddRule -ACL $acl -Order 2 -Action Deny -RemoteSubnet "0.0.0.0/0" -Description "DenyAll"
# create new load balanced endpoint
$avm | `
Add-AzureEndpoint -Name "HTTPS" -ACL $acl -Protocol TCP -PublicPort 443 -LocalPort 443 -ProbePort 3443 -ProbeProtocol HTTP -ProbePath "/” -LBSetName "Web-HTTPS-LB" | `
Update-AzureVM
That does it for Windows endpoints and ACLs. I even kept this post down to short-short-story length. I hope to publish a few more Windows Azure PowerShell blog posts in the near future, so stay tuned.
~James
Thank you for sharing, James.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy