Need secure & simplified GCP VMs access — OS Login at rescue

OS Login for Rescue

Compute Instances are the most sought compute resources in GCP. They are used by all the teams irrespective of their size or cloud strategy. Secure and simplified access to these resources is always been a challenging tasks for teams. Let’s examine various ways to access these resources in GCP and see which way is the most recommened one to access them.

Connect me on LinkedIn

How do we connect to GCP Compute Instance?

• Over direct SSH
• With IAP tunnelling over TCP
• OS Login

Over direct SSH — Anti Pattern

• This requires creation and setup of key pair by the user or by running gcloud compute ssh command.
• Setup of public key as VM or project metadata.
• When supplied to VM as metadata, user will be able to connect to that VM using the corresponding private key.
• When supplied to project as metadata, user will be able to connect to any VM in that project using the corresponding private key.

Issues & Limitations

• For connection from outside VPC, the VM should have a public IP.
• Since the VM is exposed to internet, the appropriate ingress rules should be setup.
• Key management becomes an issue and user needs to protect it’s private key. Anyone having access to private key can access the VM if firewall rules are not setup appropriately.
• This method of connection is not linked to the IAM permissions granted to the user.

This way of connecting to VM is considered an anti-pattern and should be avoided if possible.

With IAP tunnelling over TCP — Pattern

One of the issue with direct ssh connection is that the VM instance is required to have public IP. This makes the VM vulnerable to security attacks. Connecting using IAP tunnelling over TCP remediates this problem.

Features

• Connection to VM can be made using internal IP address. Please specify --tunnel-through-iap flag while running gcloud compute ssh .
• Key setup is done by gcp automatically during the first execution of gcloud compute ssh command. Public key is by default setup as project metadata and key pair is stored on the users machine under $HOME/.ssh directory
• Allows fine-grained control over which users are allowed to connect to which VMs.
• Set the Ingress from the IAP IP range (35.235.240.0/20). Apply this ingress only to VMs that you like to be accessible via IAP.
• The IAM permissions are used to allow users to connect to VMs. Roles required are — roles/iap.tunnelResourceAccessor & roles/compute.instanceAdmin.v1 . Grant these roles only to users who should be allowed to administer the VMs over IAP.
• Documentation can be found here.

Issues & Limitations

• 2 factor authentication is not supported using this method.
• The connection speed is relatively slow when connection is made through IAP tunnelling. This could slow down the deployment with CI/CD pipelines.

This way of connecting to VM is an acceptable pattern but still lacks the sucurity requiments of many organizations like 2 factor authentication.

OS Login — Pattern (Recommended)

Features

• The setup is done at profile level which means key setup is only done once per user profile and not for every project.
• Access to VM instance is controlled using IAM permissions.
• Seperate access can be setup for developers and admins by granting roles roles/compute.osLogin and roles/compute.osAdminLogin respectively. Admin are allowed to sudo to root.
• Connection works on external IP.
• Connection works on internal IP using TCP-IAP forwarding.
• 2 factor authentication can be enabled using OS Login. More details about how to enable OS login and setup 2 factor authentication can be found here.
• Access to individual files can be controlled using OS Login linux group.
• Documentation can be found here.

Issues & Limitations

• If not setup from the start, the pipelines and other schedules actions will require some rework. This needs to be planned accordingly.
• Only supported for Linux VMs.
• If 2 factor authentication is enabled with OS Login, then the user connecting to VM should have 2 step verification setup on your google account.
• The user has no control on the username on the VM instance. It is automatically drived using the email address of login user. eg: If login user is abc@org.com then user on the VM instance will be abc_org_com.

This way is the most recommended way to access VM instance.

This is all for you. Hope you find this useful to access the VM instances in secure manner.