Automated Deployment of a Streaming Gateway Appliance (SGA) with Frame Networking in AWS

In this blog, I will demonstrate how the Frame automated Streaming Gateway Appliance (SGA) deployment capability can be used to grant internet access to those same private workloads so that I no longer need the RDP bastion server to access the private network.

Private Network Configuration​

The diagram below shows the existing private network configuration.

In this scenario I chose to use a /24 CIDR for the VPC, in order to better accommodate the SGA requirement that the target private network has a network mask between 18 and 24 bits.

Streaming Gateway Appliance (SGA)​

The Streaming Gateway Appliance (SGA) is a reverse proxy, based on NGINX® software, that customers can deploy which allows internet-based users to connect to Frame workload virtual machines (VMs) that are on private networks. The architecture is described here. The SGA can be manually deployed by a cloud administrator on your private cloud in the network of your choosing (VPC, subnet) by following these directions. You will need to manage the wildcard DNS A record, the wildcard public key certificate for the SGA, and the load balancer (if you wish to have a high-availability SGA deployment).

Recently, Nutanix introduced a feature (Frame networking, private network with SGA) that automates the deployment of an SGA. This allows the Frame customer administrator to create one or more SGAs from the Frame Console during account creation. With this feature, the automation orchestration process creates both a Frame workload VPC and an SGA VPC, handles the wildcard DNS A record, the wildcard public key certificate, and the load balancer (if required). However, this capability is not appropriate for our BYO Networking case. The automation capability can be leveraged if you contact Frame Support with your Frame Account name, the CIDR that should be used for the SGA VPC, and the number of SGA's that you want deployed. Frame Support can kick off the process to automatically create the SGA VPC for you and peer it to your existing VPC.

In this example, I want 2 SGAs in a VPC with the 10.101.0.0/24 CIDR so that both VPCs will be routable to each other and any other private subnets I might create in the future. The automated SGA deployment process will end up creating a solution architecture, as illustrated in Figure 2.

Frame automatically creates the VPC, the peer, the subnets (one for each availability zone), the Internet Gateway, the NAT GW, the number of SGA's requested, and the load balancer (if more than 1 SGA is requested). It also sets up the routes. The only task that needs to be done on the Frame Account VPC is to check the workload security group and confirm that the SGAs have the ability to establish inbound connections to the workload VMs on 443 so the users on the Internet can stream from the workload VMs. In this example, I did that by allowing all 10.0.0.0/8 IP's to create inbound tcp/443 sessions in the workload security group.

Automating the Whole Thing​

As mentioned above, Frame has a new feature to automatically deploy and set up SGAs when creating Frame accounts using BYO AWS subscriptions. The feature, labeled ‘Private network with SGA', allows Frame Administrators to automatically deploy both a Frame SGA VPC and a Frame workload VPC in one easy step. The only additional information required from what is mentioned above is the VPC CIDR of the workload VPC.

Following the workflow described in our documentation, the Frame Platform will create the resources for the same architecture as the BYO Network case above. The SGAs will be placed behind a load balancer and “Let's Encrypt” certificates dedicated to the Frame Account will be created and automatically deployed. The subdomain used will be a subdomain of the nutanixframe.com domain and will include the “vendor ID” which is a unique identifier for a frame account (vendor id is 33957 in the example below).

SGA Autodeploy - Networking​

As noted above, the SGA Autodeploy, whether initiated via Frame Support or through the Frame Console, creates a new VPC dedicated to the SGAs. This separation has the benefit of creating a cloud-based DMZ where inbound connections to the private network can be focused and secured.

The Frame Administrator defines the CIDR block and a VPC is created with that block. This CIDR should be unique and routable on the Private network or Private VPCs that it needs to connect.

The autodeploy process will split this VPC into subnets based on the number of AWS Availability Zones (AZs) in the AWS Region. If more than one SGA is requested, Frame Platform will deploy the SGAs in multiple AZs, resulting in a high availability (HA) solution when a single AZ is inaccessible.

An internet gateway is attached to the SGA VPC and if required, a load balancer is provisioned in front of the SGAs, completing the HA setup. The final networking step creates the peer with the requested Frame account workload VPC and updates the route tables in both VPCs.

SGA Autodeploy - DNS​

The next step is to create a DNS subzone based on what is known in Frame as the “Vendor ID” as shown in Figure 5. Each Frame account has a unique ID found on the “Summary” page of the account.

The subzone will be subordinate to the nutanixframe.com domain and will be of the form sga-.nutanixframe.com. We use Route53 for our DNS so the subzone will be created and a single wildcard entry will be set up pointing to either the IP of the single SGA instance or the CNAME of the AWS Load Balancer.

SGA Autodeploy - NGINX Configuration​

The SGA VMs themselves are deployed with “userdata” which is a script that runs each time the SGA is booted. It uses environment variables set by the Frame Platform to customize the configuration.

If not configured, the first thing the SGA does is create a public or private keypair that is and sends the public key to Frame Platform. This pair is used to secure future communications between the SGA and the Frame Platform.

The script then contacts “LetsEncrypt” to get a challenge string which is then forwarded to Frame Platform. The Frame Platform takes the challenge string and stores it in the DNS subzone as a TXT record so that “LetsEncrypt” can validate the ownership of the DNS subzone.

The SGA script then polls the Frame Platform until it gets confirmation from the Frame Platform that the DNS update is complete. It then informs “LetsEncrypt” that the challenge can be verified. Once successful, LetsEncrypt completes the SSL certificate signing and returns the public key certificate back to the SGA where it can be used in the Nginx configuration.

A separate script takes the CIDR information provided and creates the appropriate entries in NGINX for each potential workload IP address.

Once all this is done, NGINX is restarted and the SGA is ready to go!

The Benefits​

Automating the deployment of Streaming Gateway Appliances (SGA) gives Frame administrators the benefit of additional security for their Frame accounts, without the hassle of obtaining and maintaining SSL Certificates and managing the wildcard DNS record. It also eases the connection between the Frame workload account and the private network by allowing administrators to control the private IP addressing of both the Frame Account and the SGA VPCs.