By Korey Tibbs | Cloud Solutions Group Senior Engineer
What is Identity Aware Proxy?
Identity Aware Proxy (IAP) allows you to establish a zero-trust model by allowing users to access applications and services securely from anywhere, without using a VPN or requiring users to be on a specific network. It works by placing an authentication layer in front of the application or service, verifying the user’s identity using Google accounts, and enforcing access policies based on user attributes and context. More detailed information about IAPs can be viewed here. Access to applications and services will always be logged to Cloud Logging so you can rest assured that an audit trail exists if an issue were to arise.
Using IAP for TCP Forwarding
IAP TCP forwarding provides you fine-grained control over which users are allowed to establish tunnels and which VM instances users are allowed to connect to. Within this series we will be talking exclusively about using IAP TCP Forwarding. There are more security mechanisms that can be implemented to further secure SSH, RDP, and other traffic to your VM instances. This will allow you to evaluate each of the practices individually to see which works best for you and if it is even required.
For this post, we will be walking through the setup and explanation of establishing an encrypted tunnel over which you can forward SSH traffic to VM instances.
To setup this environment I’ve written some Terraform that will help deploy the proper configuration. You will need to change values to match your specific environment. If you don’t have a Terraform service account within GCP, I’ve written a script that creates a project and service account that will be used as the TF runner. To make sure the script runs successfully, you must initialize the Cloud SDK or use Cloud Shell with an account that has the ability to create projects within your organization (if you have one).
Environment Review:
In the image below, we can see that our Terraform (TF) created a new project and assigned itself some IAM Roles along with two personal accounts that I manage (korey.tibbs@gmail.com and zeropercentcool@gmail.com). korey.tibbs has the roles Compute Instance Admin and IAP-secured Tunnel User, these rules are required to use the tunnel to ssh/rdp into the GCE instances. Zeropercentcool simply has the Viewer role and will be used to demonstrate that although a principal can view a project and its resources, it won’t be able to access resources.
Now we see that we’ve created an instance within our project and it doesn’t have an external IP address so there is no way to ssh/rdp into the instance without a means of a Bastion Host or the TCP Forwarding tunnel.
Here is another image within the IAP service that displays the instance we’ve created (iap-instance2) is being managed along with the Role/Principal that has access through the tunnel. You can add principals directly within the IAP service or you can create IAM bindings (choice is yours). Next to the instance we are demonstrating we see a yellow warning sign - this happens to me off and on - it is basically saying that we don’t have the proper firewall rule within our VPC Network for this service to work but I assure you it’s there and the service works as expected.
IAP in Action:
Using the Cloud SDK signed into the korey.tibbs account, I run the gcloud compute ssh iap-instance2 command and after a handshake to add my ssh key to the instance’s metadata I am then connect through the TCP Tunnel and working within the instance. 
Now, still using the Cloud SDK, I switch to zeropercentcool and run the same command as before but after a few attempts to add my ssh key to the instance’s metadata I am presented with an error and a permission that is required for my actions to be successful.
Giving a Principal Access:
Since we’ve seen that zeropercentcool does not have access to ssh into iap-instance2, I will walk through manually what permissions are needed for the user.
Something to note really quick is that by default when enabling the GCE API, GCP creates a service account that has the Edit role over the entire project. To adhere to best practice, the Terraform code that was written for this lab creates a custom service account that is then used for the instance that was created.
So, first zeropercentcool will need to have the Service Account User role attached directly to the custom service account. It’s best to do it this way so that if there are any other service accounts created, this principal is limited to the one account therefore following the principle of least privilege.
Now we give zeropercentcool the Compute Instance Admin and IAP-secured Tunnel User role within the project’s IAM service.
Finally, the user is able to use the tunnel to SSH into the instance.
What's Next?
IAP for TCP Forwarding is just the tip of the iceberg when it comes to securing access to any VM Instances. Another mechanism that can be deployed at a per instance level is OS Login. OS Login adds an extra layer of security by pairing it with two-factor authentication, and manages access at the organization level by setting up organization policies.
Keep following along in this series to broaden your knowledge and protect your most precious resources.
To learn more about Trace3's Cloud Solutions Group and how we can help you translate your business strategy into the cloud approach that works best for your organization, click here.
