Exploring Azure Cloud Shell Private VNETs

One security concern often overlooked in Azure deployments is around the concept of administrator access. The problem can be summarized in the fact that users typically have one device (either corporate or non-corporate) and those users can access resources from various different security domains. Think of the typical cloud administrator who likely has access to development, test, and production resources, all from the same end-user device.

If we think about this in terms of a maturity model, level 0 would be that there are no specific controls placed on administrative users. They are allowed to use the same end-user device, use the same end-user credentials, and connect from anywhere.

As you go up the maturity level, you start to add location controls (such as locking down which IP addresses communication can come from) and enabling user controls (such as MFA) to strengthen the “validity” of the authentication request.

The next step would be to start enforcing some type of policy on the end-user device. For example, you could make use of conditional access policies to ensure that users are connecting from a corporate controlled device (rather than their home computer). You could also enforce other things, such as anti-virus and encryption checks, to get a warm and fuzzy feeling that the device using to connect to your resources is “relatively safe”.

Continuing on, you start to get in to the concept of privileged access workstations (PAWs). The core security benefit is that you are relying less on the state of the end-user device (it now becomes just an input/output device). There are many ways to achieve this goal (and likely another maturity scale within the types of PAWs). In Azure, one could make use of dev/test labs or windows virtual desktops to accomplish this. Another way, depending on the toolsets required to interact with production resources, to accomplish this is by using cloud shell.

As per the documentation:

“Azure Cloud Shell is an interactive, authenticated, browser-accessible shell for managing Azure resources. It provides the flexibility of choosing the shell experience that best suits the way you work, either Bash or PowerShell.”

One of the issues with the current cloud shell implementation is that you cannot control where the cloud shell container is deployed. Because of this, you couldn’t use cloud shell to effectively administer systems that make extensive use of firewall capabilities to control access. This new preview changes that.

Reliance on Azure Relay

I still remember being at Microsoft headquarters when they announced the idea of Azure relay. It was a security focused group, and the front of the room was super excited about this new way to work with internal resources from external sources. In the back of the room (where I was sitting) it was a different story. Many of us realized that Microsoft just created the industry leading data ex-filtration tool. A quick read of the basic flow will probably give you all you need to understand how an attacker can use this service to proxy traffic outbound to their target service. Likely, all this communication would bypass corporate firewall policies (who bans Azure addresses when they use them) or even better, automatically make use of express route connectivity for improved connection speeds.

Security issues aside, Azure relay used in this context is actually a super cool way to solve the problem of external connectivity to the cloud shell container. If this relay is in fact fully controlled by the deployment parameters, that would make it even better.

Conclusion

I think with this added preview feature, it is going to make cloud shell more usable in enterprise environments as a quick/easy alternative to managing full fledged desktops for administrative access. I’m looking forward to trying out this preview.

 

About Shamir Charania

Share This Article

Comments