This is the second of a two-part blog series about running Linux on Azure. In the first blog post I discussed the basics of running Linux on Azure. In this post I am going to go a little deeper into some of the important concepts that I have discovered while experimenting with Linux on Azure for the last several months.
One of the cool things about running Linux on Azure is the extensions that tie Linux virtual machines into the Azure environment. This is another feature that frankly surprised me a bit. I expected Microsoft products to fully integrate with Azure (and they do) but I expected the Linux integration to be clunky.
That turned out to not be the case. There are Linux extensions that integrate directly into Azure. These extensions are tested on most Linux distros. You can start, shut down and even monitor Linux resources from within Azure. Things like boot logs and performance metrics are recorded in Azure and can be viewed from within the Azure Portal.
There are other extensions as well, such as a scripting extension that allows scripts to be injected into a Linux virtual machine.
For me, scalability is a key benefit of cloud computing. Provisioning capacity when needed and de-provisioning the capacity when no longer needed is a cornerstone value of cloud computing. While virtual machines can certainly be added on the fly with an on-premises data center, cloud computing generally simplifies the process while eliminating the need to maintain the hardware and software to support it. Azure supports virtual machines that automatically scale up or down based on load, on a schedule or on an ad-hoc basis. This capability is available for Windows and Linux virtual machines in the form of scale sets. Linux scale sets can scale out or in in response to basic performance metrics such as processor or memory pressure. The Linux Azure extensions report basic performance data from the virtual machine scale set to Azure and at that point the Azure autoscale capabilities take over. All of this is completely transparent to the workload running on the virtual machine. Again, the story here is that Linux scale sets are created and operate the same as Windows scale sets.
Obviously, Linux virtual machines have all of the security features of the platform. Beyond that Microsoft has invested and continues to invest heavily in security. This isn’t some altruistic gesture on the part of Microsoft. Cloud providers need to have a higher level of security than anyone else. If there is a data breach at a retailer then that retailer will take a hit but will likely survive because data isn’t really their primary thing. If there is a major data breach in Azure, then Azure is likely dead. If customers do not feel that their enterprise assets are safe in Azure, they are not going to use Azure. Microsoft has made it pretty clear that they do not want Azure dead.
There are two ways to look at security within Azure: security implemented under the hood and security under your control. Under-the-hood security complies with a host of industry certifications. I’m not a security guy but the list of Azure security certs just looks really impressive to me.
If there are specific security certifications that you need there is a good chance that Azure has them, or will soon. You can get an interactive list of Azure security compliance certifications at https://www.microsoft.com/en-us/TrustCenter/Compliance/default.aspx.
This is just a quick screen shot of some of the current Azure compliance certifications.
In addition to the physical and data security measures implemented within Azure itself, you have several security features that can be applied to your Linux workload in Azure:
- Network Security Groups. Network Security Groups or NSGs act as firewalls within Azure virtual networks. NSG rules can restrict inbound and outbound traffic by source and destination based on address and port. NSGs can be applied to individual virtual machines or to entire subnets.
- Routing Rules. Routing rules allow you to route traffic through specific end points or addresses based on source, destination and port. If you have your own firewalling or audit machine you can easily provision a virtual machine and configure routing rules to push traffic through the device.
- Public IP Addresses. Virtual machines run in virtual networks. By default these networks are not available to the internet. A public IP address is required for any direct internet-based access to a virtual machine.
- Encrypted virtual hard drives. Virtual hard drives can now be encrypted in Azure providing data-at-rest protection. Linux virtual hard drive encryption uses the DM-Crypt feature and is available for virtual hard disks (VHDs) created in Azure or VHDs that were already encrypted and migrated to Azure.
For the DevOps in the room, automation and repeatability are key. Fortunately for Microsoft, there is a growing list of capabilities that provide both. Azure has native support for Chef and Puppet. Azure also has its own automation system that supports PowerShell workflows. Automation extends into the Linux virtual machines via script injection and desired state configuration. Wrap that together with a JSON-based declarative framework for creating all Azure resources and a REST-based API for all Azure functions and there is a strong story for automation and DevOps.
Learn a bit more
If you are interested in learning more about running Linux workflows on Azure, Global Knowledge has put together some short, innovative courses specifically targeted to running Linux on Azure. The courses are based on challenges rather than taking you through detailed step-by-step labs. The courses give you broad goals and tasks and allow you to implement your own solution. The challenges give you progressive assistance as needed, from task definition to demonstrations and detailed instructions for any task you may need more help with. You get to choose how much help you need, and when you complete a challenge you submit it for review by a subject matter expert.