Resources

Arrow Image

Blog & News

Arrow Image

Frame Networking Solutions in the Public Cloud

Frame Networking Solutions in the Public Cloud

News & Blog

WRITTEN BY

Timothy Strobeck

Security Engineer

November 24, 2020

TABLE OF CONTENT

Introduction

Desktop and application virtualization is not new technology, but has become more of an essential component for businesses of all sizes for the better part of a decade. More and more customers see the benefits of virtual applications and desktops--you can read more about why they are turning to VDI and DaaS.

Transitioning virtual application and desktop environments from on-premises to the cloud in the past has been challenging due to security requirements, networking requirements, and overall unfamiliarity with cloud services. Our goal is to hide complexity and make end user computing (EUC) as simple and as easy as possible, while being flexible to support your own security and network requirements.

By the end of this blog, you should have answers to a few key questions that will get you started with public cloud Desktop-as-a-Service:

  • Am I or is my security team comfortable with having workloads directly on the internet with a public IP address?
  • Do I have network inspection or security tools that require traffic to run through my on-prem network?

Network Architecture

We often get questions from customers like “we know the core value and concepts of Frame, but from a networking perspective, what are our options?” These blogs will help lay out the full stack from network to application so you can securely configure your accounts, workloads, and network architecture.

Depending on the deployment scenario, the network architecture can vary widely due to the complexity of the environments and how each environment connects into existing infrastructure or to on-prem datacenters. This blog post describes a few commonly used deployment scenarios and discusses their network security impacts. To keep things simple, this post references AWS, but these scenarios can be replicated across other cloud providers [Microsoft Azure and Google Cloud Platform (GCP)].

Deployment Scenario 1: Workload VMs using Public IP Addresses

Frame was founded on the idea of fully utilizing the public cloud to deliver applications and desktops. The traditional deployment model is for Frame to provision into your hybrid cloud infrastructure account through an assumed Identity and Access Management (IAM) role. A Virtual Private Cloud (VPC) is created, subnets are placed in all availability zones (AZs), and Internet Gateways (IGWs) created to allow the workloads to talk out to the internet and talk back to the Frame platform.

Figure 1. Create Frame Account with Public IP Addresses
Figure 1. Create Frame Account with Public IP Addresses

The only ports that are opened by default are 443 from the internet to allow users to connect to the workload over TLS 1.2, and 8112 from three of the Frame IPs that correspond to our gateways. Each workload that users connect to will get an Amazon public IP for the duration of the session. Once the user disconnects and terminates the session, the instance is shut down and the IP is released back into Amazon's pool. From an administration standpoint, the model is extremely simple and easy to manage. But some security teams may prefer not to expose certain workloads directly to the internet. While the Frame Guest Agent (FGA) running on the workload has been hardened and requires authentication, other customer-installed software may not have the same levels of hardening. Further minimizing the attack surface can be achieved with the other deployment models listed below.

Figure 2. Frame Account Architecture with Public IP Addresses
Figure 2. Frame Account Architecture with Public IP Addresses

Deployment Scenario 2: Workload VMs using Private IPs with Secure Gateway Appliance (SGA)

From a networking standpoint, not directly exposing your workloads to the internet provides some protection against the shenanigans that happen on the internet. One option for addressing this is with Frame's private IP workload feature.

Figure 3. Create Frame Account with Private IP Addresses and SGA
Figure 3. Create Frame Account with Private IP Addresses and SGA

In this scenario, Frame provides an appliance called the Streaming Gateway Appliance (SGA) that acts as a reverse proxy to the private IP workloads. The Frame platform redirects the user to the Streaming Gateway appliance, and the appliance directs the user to the correct workload. In this scenario, there are public subnets and private subnets created in the VPC, an IGW placed in the public subnet, and NAT gateways configured to route traffic through the public subnet.

The Frame platform will spin up instances in the private subnets and will not directly expose those workloads to the internet. From a security standpoint, an attacker would need to know the private IP CIDR block of your VPC, know when those instances have spun up, and have a validated session token in order to start attacking. With any variation of the 10.X.X.X / 172.31.X.X / 192.168.X.X private IP space, that's a lot to query for. This layer of obfuscation helps to limit internet scanning activity and protect your workloads. As an additional validation step, the SGA will also validate your user session token before allowing you to pass through the SGA and connect to the workload itself.

Figure 4. Frame Account Architecture with Private IP Addresses and SGA
Figure 4. Frame Account Architecture with Private IP Addresses and SGA

Picking the right scenario

Let's return to the questions posed at the beginning of this blog and evaluate the pros and cons.

  • Am I or is my security team comfortable with having workloads directly on the internet with a public IP address?
    • Pros: Available anywhere on the internet, no special configuration required, easy to set up
    • Cons: Available anywhere on the internet, therefore attack surface can be greater
  • Do I have network inspection or security tools that require traffic to run through my on-premises network?
    • Pros: Leverage tools already in-place for network inspection
    • Cons: Latency can be introduced running from cloud to on-premises and back to the user

So, what choice should you make? As always, it depends on your use case and the applications or desktops you are trying to deliver. You should always consider networking requirements, security, and end user experience when evaluating new deployments of applications or desktops to your users. The flexibility with Frame to support the most demanding network architectures while keeping it as simple as possible is a great differentiator.

If you need recommendations or assistance from the Frame Team for deciding on the right deployment scenario, we would be happy to assist you! Please contact us here: https://www.nutanix.com/contact-us

Of course if you haven't tried Frame yet, take Frame for a 2 Hour Test Drive or sign-up for a free 30-day trial at My Nutanix.

About the Author

Dizzion

Dizzion was founded in 2011 with a visionary mission to redefine the way the world works.

In an era of legacy Virtual Desktop Infrastructure (VDI), Dizzion set out to challenge the status quo by making it simple for all customers to transform their workspace experience. By building a powerful automation and services platform on top of the VMware stack, Dizzion delivered virtual desktops as a service before Desktop as a Service (DaaS) even existed.

Timothy Strobeck

Security Engineer

More about the author

Subscribe to our newsletter

Register for our newsletter now to unlock the full potential of Dizzion's Resource Library. Don't miss out on the latest industry insights – sign up today!