Remote Access Using SSH Cryptographic Keys
Enabling remote access to Google Cloud Platform (GCP) Linux VMs can be done using SSH key-based authentication, and instance metadata can be used to limit the type of SSH keys that are available. Managing that metadata is key to controlling which types of public SSH keys are allowed for a specific instance. The two types of keys are
Project-wide public SSH keys: ability to connect to most instances in your project
Instance-level public SSH keys: ability to connect to a specific instance in your project
Project-wide public SSH keys are allowed by default. This is not a best practice if you have multiple users in your project, as access to login to individual compute instances should be granted with least privilege in mind. Turbot Guardrails recommends using instance specific SSH keys which give you more granular control over remote access controls.
This post looks at how Turbot Guardrails can help enforce blocking project-wide SSH keys across all of your instances in your GCP projects.
Traditional Workflow
GCP offers an option on each Compute instance to block or allow project-wide public SSH keys. By default this setting allows use of project-wide SSH keys. Changing this setting can be done manually; however, it becomes a challenge at scale (e.g. many instances in a multi-project model) to deploy and keep configurations consistent over time.
Our recommendation is that customers implement instance-level SSH keys only.
Get it done with Turbot Guardrails
Let’s look at how Turbot Guardrails automation can be applied globally to block project-wide SSH keys on all instances – in every project – across your entire GCP organization. Exceptions to this global setting may be needed, and this approach allows you to overwrite the setting on specific instances when approved.
By setting a single policy in Turbot Guardrails, we can ensure that use of project wide keys are disabled on all current and future instances:
After setting this policy, Turbot Guardrails automation will identify all instances that allow project wide SSH keys and then handle remediation (update the instance metadata to disallow project SSH keys).
If you want to evaluate which instances are at risk in your environment before taking corrective action we suggest setting the value to Check: Approved at the Turbot level. Once set, Turbot Guardrails will create alarms for instances that are not configured correctly. The team can then selectively apply an enforcement setting (e.g. to development and/or sandbox environments) to run the corrective controls.
Make it happen!
See for yourself how easy it is to block project-wide SSH keys from accessing your GCP Compute Instances. A ready-to-run Terraform template is available to enable this configuration from the Turbot Development Kit (TDK). If you need any assistance, let us know in our Slack community #guardrails channel. If you are new to Turbot, connect with us to learn more!