In my previous blog, I outlined how the Nutanix Frame™ Bring Your Own (BYO) Networking capability in Amazon Web Services (AWS) could be used to deploy a Frame account in a manner that would allow it to be connected to an existing private network. In that post, I deployed a RDP bastion server so that I could access those private Frame workloads from an internet based machine since I had no private network.
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.
Figure 1. Existing 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 Nutanix 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. Nutanix 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.
Figure 2. SGA Deployment Architecture
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.
Figure 3. Private Network with SGA dialog
Following the workflow described in our documentation, the Frame Platform will create pretty much the exact 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 off 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).
Sample of a SGA-enabled workload VM hostname
SGA Autodeploy - Networking
As noted above, the SGA Autodeploy, whether initiated via Nutanix 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.
Figure 4. SGA VPC
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.
Figure 5. Vendor ID
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.
About the Author
David Horvath is a Senior Solutions Architect with Nutanix Frame. He has been a part of the Frame team for almost 4 years and prior to that spent 20 years consulting on various Information Technology projects with the US Intelligence Community.
© 2021 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and all Nutanix product, feature and service names mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. 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 Nutanix.com. Nutanix 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. This post may contain express and implied forward-looking statements, which are not historical facts and are instead based on our current expectations, estimates and beliefs. The accuracy of such statements involves risks and uncertainties and depends upon future events, including those that may be beyond our control, and actual results may differ materially and adversely from those anticipated or implied by such statements. Any forward-looking statements included herein speak only as of the date hereof and, except as required by law, we assume no obligation to update or otherwise revise any of such forward-looking statements to reflect subsequent events or circumstances.