INTERVIEW In September, Microsoft will retire default outbound access for VMs in Azure. "It's not quite a Y2K moment," says Aviatrix CPO Chris McHenry, "but things will break."

Deploying applications in the cloud usually requires some form of internet access. Sure, a company might create an Azure Virtual Network (vnet) to roll out their applications, but at some point, access to public services will be needed.

"So to make that easy for developers - because developers don't typically understand networking - Azure's model has been if you deploy an app, by default, it has internet access," says McHenry, "You don't have to do anything."

Simple, right? Wrong.

The problem is security. While the security team could inspect and control internet traffic when applications were deployed on-prem, if a developer deployed to Azure and accepted the defaults, "the security team no longer has any visibility, and they no longer have any control."

By going for the defaults, Microsoft takes care of all the networking stuff and assigns an IP address. "So you don't know what your IP address is," says McHenry. "You don't really have the ability to control it."

"In September of this year, that will change."

"The thing that the developer was doing beforehand, where they deploy this virtual machine, now they try to deploy another one, or they try to scale that virtual machine out – like horizontal scalability, they want to increase the performance of their application – it won't work because they're retiring that behavior of default outbound internet access."

The upshot is that developers will need to know a bit more about networking, rather than blithely clicking through the defaults.

"Microsoft is doing the right thing," says McHenry. "Anything that is existing and already deployed, if it doesn't change, it will continue to work as it does right now."

"But as soon as the developer or the application owner wants to deploy something new or change the deployment that they have in their current environment, it will no longer get that outbound internet access."

"So [it] really has a chance to break a decent amount of pipelines."

As a company, Aviatrix is all about secure cloud networking. So McHenry and his team have been keeping a close eye and discussing the implications of Microsoft's change with customers.

"There are three kinds of perspectives on this," he says. "One is 'I wasn't aware of that, this is crazy, I almost don't believe you, I'm going to have to validate this myself.' That's a very, very common perspective."

"The second one is 'We're aware of it. This is scary, but I don't believe Microsoft is going to hold to their date so we're just gonna risk it.'"

"And then the third one is 'We're really freaking out and we're actively negotiating with Microsoft to see if they can kick that date down the road."

There is, of course, a fourth response to the change, which comes from organizations with mature architectures and a good handle on their network security. They might not be affected at all.

The problem is relatively unique to Microsoft. "GCP and AWS make you do some explicit setup to make these things work," explains McHenry.

"In AWS, you have to explicitly say, 'I want a gateway to the internet, and I want a route pointing to that gateway.' In Microsoft, the lack of any configuration indicates that you have internet access. So it's like you're going back and reversing a lot of config."

Microsoft has several recommendations for affected users. One is that old standby, the fixed public IP address. "When I mentioned that at Ignite," recalls McHenry, "there was a literal groan from the audience, because it actually moves your security posture backwards."

Or you could put a fixed public IP address on a NAT gateway on the vnet, so any workloads in the vnet can access the internet via the gateway. "Now, the problem with that model is that it still doesn't solve the visibility or control problem," says McHenry. "It's really not anything different than the existing behavior."

"And again, it costs money."

There's also an approach using Azure Load Balancers. Users could even opt for Microsoft's Firewall product. "I was very surprised in all of this that they aren't recommending their firewall offering," says McHenry, "because if the intent behind this is security, you would think that that would be one of their explicit options."

"My guess for the reason they're not doing that is because it's significantly more expensive."

"So they're making this global change, and they're saying things are gonna break, like, you have to do something, and the only options you have are to add cost."

Still, although working out how severe an enterprise's exposure might be – and simply freezing a company's network configuration in a dynamic cloud world is not particularly viable – McHenry sees opportunities for administrators. "This change," he says, "is an opportunity for organizations to reassess what their security posture looks like."

The change comes after September 30. Administrators running Azure workloads, unsure of what their developers clicked during self-service, could have a busy summer ahead. ®