Securing & Easing SSH to Google Compute Instance with Identity Aware Proxy(IAP)

SSH has become trivial but still a truth. In this post, we will talk about securing the ssh connection to compute engine instance as well as centralizing the access control by the use of Idenity-Aware Proxy(IAP). It is a part of BeyondCorp security model also known as zero trust to protect access to GCP’s internal resources through context-aware access capabilities.

image credit: akamai.com

The IAP model allows access to compute instance without the use of vpn by easing the process with a single point of control for managing user access to web applications and cloud resources without exposing them to public internet. Inn this post, we are going to focus on the ssh connection to compute instances.

By default, Google Cloud has firewall rule which keeps port 22 open for all public IPs which possess security risk. When we block the rule, we are left with two of the widely used options:

1. Bastion host
2. VPN connection

The management overhead of these option has its own complexity in terms of onboarding as well as different measures to connect(OS, VPN client, IP etc.). So, IAP eases the process by using google authentication measure to create ssh connection from local.

Two basic ways for giving ssh access to Google Compute Instances:

1. Compute engine admin or equivalent access
2. SSH access to specific user of specific instance

Let’s dig into each of these options.

Compute Engine Admin Access

This level of privilege provide entry to every compute instance which is handy if someone needs access for all VMs and networking. This gives the user access to all the machines which might not favor the ‘minimal privilege’ principal but handy way.

The access required is:

1. Compute Admin
2. Service Account User
3. IAP-secured Tunnel User

For the tunnel to work, we need to add the ingress from CIDR 35.235.240.0/20 with command:

gcloud compute firewall-rules create allow-ssh-ingress-from-iap \
  --direction=INGRESS \
  --action=allow \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20

Then, ssh can be done with

gcloud compute ssh --tunnel-through-iap [INSTANCE_NAME] --project [PROJECT_NAME] --zone [ZONE]

SSH access to specific user of specific instance

We can add the user’s ssh key on specific instance from the console itself through edit instance page which will create a new user with sudo access as well.

To avoid creating sudo user, we need to create a Linux user inside the instance and add the keys over there on ~/.ssh/authorized_keys

The firewall to allow IAP ip addresses to connect instance:

gcloud compute firewall-rules create allow-ssh-ingress-from-iap \
  --direction=INGRESS \
  --action=allow \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20

The user needs following privilege to connect the compute instance using IAP:

1. Service Account User
2. IAP-secured Tunnel User
3. compute.instances.get
4. compute.projects.get

The tunnel user permission is to be granted through Security-> IAP console.

If you want to allow the user to set the ssh key while attempting to connect, further privilege of compute.instances.setMetadata is required which prevents the manual addition of ssh keys to instance from both console or inside instance itself.

So, why go through the IAP?

One of the benefit is using IAP to control access is it centralizes the control. Let’s say if you need to give access for any google account user temporarily, then adding just ssh keys and opening 22 port will make it vulnerable because the access stays there idle even not in use and for removing the access, one has to go inside the instance and remove the ssh keys. But with IAP, even if there is ssh key, one cannot enter into compute instance because the connection is blocked by the Proxy itself. Even we don’t have to worry about the hidden keys or accesses if any.

Next benefit neither we need any further VPN or bastion host for controlling the access nor open port 22 for all IPs. The IAP access can be granted for required interval only easily from the console.

Easy Port Forwarding

Not only the ssh but there might be other services running inside the compute instance which needs to accessed locally. Tunelling TCP and RDP connection makes it handy

gcloud compute start-iap-tunnel INSTANCE_NAME 3389 `
    --local-host-port=localhost:LOCAL_PORT `
    --zone=ZONE

Read more about the forwarding from: https://cloud.google.com/iap/docs/using-tcp-forwarding