Start United States USA — software Google Cloud VMware Engine: Bastion Host Access With IAP

Google Cloud VMware Engine: Bastion Host Access With IAP

95
0
TEILEN

Learn how to deploy a Windows Server 2019 bastion host to manage our Google Cloud VMware Engine.
Join the DZone community and get the full member experience. Welcome back! This post will build on the previous posts in this series by deploying a Windows Server 2019 bastion host to manage our Google Cloud VMware Engine (GCVE) SDDC. Access to the bastion host will be provided with Identity-Aware Proxy (IAP). Everything will be deployed and configured with Terraform, with all of the code referenced in this post is available at https://github.com/shamsway/gcp-terraform-examples in the gcve-bastion-iap sub-directory. Standing up initial cloud connectivity is challenging. I walked through the steps to deploy a client VPN in Establishing an SDDC in Google Cloud, but this post will show how to use IAP as a method for accessing a new bastion host. Using IAP means that the bastion host will be accessible without having to configure a VPN or expose it to the internet. I am a massive fan of this approach, and while there are some tradeoffs to discuss, it is a simpler and more secure approach than traditional access methods. IAP can be used to access various resources, including App Engine and GKE. Accessing the bastion host over RDP (TCP port 3389) will be accomplished using IAP for TCP forwarding. Once configured, IAP will allow us to establish a connection to our bastion host over an encrypted tunnel on demand. Configuring this feature will require some specific IAM roles, as well as some firewall rules in your VPC. If you have Owner permissions in your GCP project, then you’re good to go. Otherwise, you will need the following roles assigned to complete the tasks outlined in the rest of this post: The VPC firewall will need to allow traffic sourced from 35.235.240.0/20, which is the range that IAP uses for TCP forwarding. This rule can be further limited to specific TCP ports, like 3389 for RDP or 22 for SSH. The example Terraform code linked at the beginning of the post will do the following: After Terraform completes configuration, you will be able to use the gcloud tool to enable TCP forwarding for RDP. Once connected to the bastion host, you will be able to log into your GCVE-based vSphere portal. To get started, clone the example repo with git clone https://github.com/shamsway/gcp-terraform-examples.git, then change to the gcve-bastion-iap sub-directory. You will find these files: Let’s take a closer look at what is happening in each of these files. Just like the example from my last post, main.tf begins with a provider block to define the Google Cloud project, region, and zone in which Terraform will create resources. The following data blocks, google_compute_network.network and google_compute_network.subnet, reference an existing VPC network and subnetwork. These data blocks will provide parameters necessary for creating a bastion host and firewall rules. The first resource block creates a new service account that will be associated with our bastion host instance. The google_compute_instance.bastion_host block creates the bastion host. There are a few things to take note of in this block. subnetwork is set based on one of the data blocks at the beginning of main.tf, data.google_compute_subnetwork.subnet.self_link. The self_link property provides a unique reference to the subnet that Terraform will use when submitting the API call to create the bastion host. Similarly, the service account created by google_service_account.

Continue reading...