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.
Multiple Remediation Paths
Google Cloud
SERVICE-WIDE (RECOMMENDED when many resources are affected): Enforce Organization Policies at org/folder level so new resources inherit secure defaults.
gcloud org-policies set-policy policy.yaml
ASSET-LEVEL: Use the product-specific remediation steps above for only the impacted project/resources.
PREVENTIVE: Use org policy constraints/custom constraints and enforce checks in deployment pipelines.
References for Service-Wide Patterns
- GCP Organization Policy overview: https://cloud.google.com/resource-manager/docs/organization-policy/overview
- GCP Organization policy constraints catalog: https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
- gcloud org-policies: https://cloud.google.com/sdk/gcloud/reference/org-policies
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- Google Cloud: apply organization policy constraints at org/folder scope.
gcloud org-policies set-policy policy.yaml
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
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}
