Frame Networking Solutions in the Public Cloud

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

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

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

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

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.

© 2024 Dizzion, Inc. All rights reserved. Frame, the Frame logo and all Dizzio product, feature and service names mentioned herein are registered trademarks of Dizzion, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s). This post may contain links to external websites that are not part of Dizzion. Dizzion does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such a site. Certain information contained in this post may relate to or be based on studies, publications, surveys and other data obtained from third-party sources and our own internal estimates and research. While we believe these third-party studies, publications, surveys and other data are reliable as of the date of this post, they have not independently verified, and we make no representation as to the adequacy, fairness, accuracy, or completeness of any information obtained from third-party sources.