Google CloudOverview
It is recommended to use Instance-specific SSH key(s) instead of using common/shared project-wide SSH key(s) to access Instances.
Rationale
Project-wide SSH keys are stored in Compute/Project-meta-data. Project wide SSH keys can be used to login into all the instances within project. Using project-wide SSH keys eases the SSH key management but, if compromised, poses a security risk which can impact all the instances within project. It is recommended to use Instance-specific SSH keys which can limit the attack surface if the SSH keys are compromised.
Impact
Users already having Project-wide ssh key pairs and using third party SSH clients will lose access to the impacted Instances. For Project users using gcloud or GCP Console based SSH option, no manual key creation and distribution is required and will be handled by GCE (Google Compute Engine) itself. To access Instance using third party SSH clients Instance specific SSH key pairs need to be created and distributed to the required users.
Remediation guidance
Using Console
- Go to the VM instances page: https://console.cloud.google.com/compute/instances
- Click on the name of the impacted instance
- Click
EDITin the toolbar - Under
SSH Keys, check theBlock project-wide SSH keyscheckbox - Click
SAVEat the bottom of the page - Repeat the steps for every impacted instance
Using Google Cloud CLI
To block project-wide public SSH keys, set the metadata value to TRUE:
gcloud compute instances add-metadata <instanceName> --metadata block-project-ssh-keys=TRUE
where instanceName is the name of the instance that you want to block project-wide public SSH keys for.
Default Value
By default, Block Project-wide SSH keys is not enabled.
References
- https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys
- https://cloud.google.com/sdk/gcloud/reference/topic/formats
Additional Information
If OS Login is enabled, SSH keys in instance metadata are ignored, and therefore blocking project-wide SSH keys is not necessary.
Service-wide remediation
Recommended when many resources are affected: fix the platform baseline first so new resources inherit the secure setting, then remediate the existing flagged resources in batches.
Google Cloud
Use organization or folder policies where available, shared project templates, logs and alerting baselines, and IaC modules so new resources inherit the secure setting.
Operational rollout
- Fix the baseline first at the account, subscription, project, cluster, or tenant scope that owns this control.
- Remediate the currently affected resources in batches, starting with internet-exposed and production assets.
- Re-scan and track approved exceptions with an owner and expiry date.
Query logic
These are the stored checks tied to this control.
"Block Project-wide SSH keys" is enabled for VM instances
Connectors
Covered asset types
Expected check: eq []
vms(where:{hasVMMetadataItem_SOME:{key:"block-project-ssh-keys" value:"false"}}){...AssetFragment}
